[Devel] Re: containers development plans
Cedric Le Goater
clg at fr.ibm.com
Thu Jul 5 08:53:37 PDT 2007
Hello,
some more comments on what we talked about at OLS and what we are
working on.
Serge E. Hallyn wrote:
> We are trying to create a roadmap for the next year of
> 'container' development, to be reported to the upcoming kernel
> summit. Containers here is a bit of an ambiguous term, so we are
> taking it to mean all of:
>
> 1. namespaces
> 2. process containers
> 3. checkpoint/restart
>
> Naturally we can't actually predict what will and won't be worked on,
> let alone what will be going upstream. But the following is a list
> of features which it seems reasonable to think might be worked on
> next year:
>
> 1. completion of ongoing namespace
the ipc namespace would need a "set identifier" feature if we were
to use it for C/R. this is not available right now. a patchset was
sent introducing a new IPC_SETID but it didn't get much attention.
> pid namespace
At OLS, we agreed that suka's hierarchical pidns patchset should be
fine if we can make sure perfs are OK when the namespace is not
used. right ?
I get < 1% today, so it should be okay :)
There are still some issues around /proc that we are working on.
Hopefully, we should be able to merge most of the helpers patch
real soon.
we need a clone_with_pid() kind of syscall for C/R. I had planned
to work on a :
clone64(struct clone64_arg_struct *arg)
to extend the clone flags which will soon overflow. we could
easily add a pid attribute to implement the clone_with_pid()
the kthread cleanup is not completed yet. some patch are pending
but i would say that the most important ones are around NFS and
i'm not sure anyone worked on these.
af unix credentials still hold some pid_t's. they need a clean up.
> net namespace
see previous email
> ro bind mounts
work in progress. dave ?
what about mounting /proc and /sys multiple times ?
> 2. continuation with new namespaces
> devpts, console, and ttydrivers
> user
merged experimental. we still need to work on the (user,userns) checks.
however, openvz and linux-vserver should already be able to use it.
> time
> namespace management tools
> namespace entering
there are a few patchsets on the topic :
* bind_ns() syscall
* container subsystem identifying a nsproxy object
but they didn't get much review :(
> 3. any additional work needed for virtual servers?
> i.e. in-kernel keyring usage for cross-usernamespace permissions, etc
> 4. task containers functionality
> base features
> specific containers
> poll to see who has plans
> 5. checkpoint/restart
we really need to leverage the freezer and suspend to disk for that.
there are some talks about it right now but it seems a bit early to
have clear directions yet.
generalizing the refrigerator to all arch seems a good idea to freeze
a container. then how do we initiate checkpoint ? syscall ? signal ?
etc.
These topics were addressed at the BOF and people are now aware of
different solutions. we hope that the email storm on what directions
to take for mainline will start soon.
C.
> memory c/r
> (there are a few designs and prototypes)
> (though this may be ironed out by then)
> per-container swapfile?
> overall checkpoint strategy
> in-kernel vs userspace-driven
hybrid ?
> overall restart strategy
>
> What more needs to be added to this list?
>
> A list of the people we are currently aware of who are showing interest
> in these features follows. What I'd like to know is, from this list, do
> some people know what general or specific areas they plan to or want to
> work on over the next year?
>
> Stakeholders:
> Eric Biederman
> google
> ibm
> kerlabs
> openvz
> osdl (Masahiko Takahashi?)
> vserver
>
> Who is missing from the list?
>
> thanks,
> -serge
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
>
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list