The concept is relatively simple, it's a daemon exporting an authenticated REST API both locally over a unix socket and over the network using https. There are then two clients for this daemon, one is an openstack plugin, the other a standalone command line tool. ''
The main features and I'm sure I'll be forgetting some are:
- Secure by default (unprivileged containers, apparmor, seccomp, ...)
- Image based workflow (no more locally built rootfs)
- Support for online snapshotting, including running state (with CRIU)
- Support for live migration
- A simpler command line experience
This work will be done in Go, using the great go-lxc binding from S.Çağlar.
- Code to this project will be contributed under an Apache2 license, no CLA is required but we will require contributors to Sign-off on their commits as always (DCO).
- Discussions about lxd will happen on lxc-devel and lxc-users.
- Contributions to github.com/lxc/lxd will happen through github pull requests only and reviews will happen on github too.
This is kept separate from the main tree because at least initially, I believe it best to have a separate release schedule for both of those and because it tends to be easier for Go-only projects to live in theirown branch.
...
In order to be a good hypervisor, we also need to make containers feel like they are their own system and so we'll be spending quite a bit of time figuring out how to improve the situation. Some of the work presented at Linux Plumbers is going to contribute to that, like cgmanagerfs to provide a reasonable view of /proc and a fake cgroupfs, Seth's unprivileged FUSE mounts and all the cool things mentioned in Serge's earlier post about
Now as for the next steps. We will be creating the repository on github over the next few hours with Serge and I as the initial maintainers. Once the project is properly started and active, we will promote some of the most active contributors to commiters.
The first few commits in there will be text versions of the
specifications we came up with until now. This should also serve as a good todo list for people who want to get involved.
Over the next few days/weeks, the existing code which was used for the demo at the OpenStack summit in Paris will be submitted through pull requests, reviewed and merge.
Thank you; that's very helpful. And the tl;dr is that this whole announcement is describing something that doesn't really exist yet -- it's open source vaporware.
Can you try to get the juno repo up? It's pretty bad that the add-apt-repository command at http://www.ubuntu.com/cloud/tools/lxd don't even work on Ubuntu 14.04...
----------
'"
...
The concept is relatively simple, it's a daemon exporting an authenticated REST API both locally over a unix socket and over the network using https. There are then two clients for this daemon, one is an openstack plugin, the other a standalone command line tool. ''
The main features and I'm sure I'll be forgetting some are:
- Secure by default (unprivileged containers, apparmor, seccomp, ...)
- Image based workflow (no more locally built rootfs)
- Support for online snapshotting, including running state (with CRIU)
- Support for live migration
- A simpler command line experience
This work will be done in Go, using the great go-lxc binding from S.Çağlar.
Now as to what this means for LXC upstream:
- A new project will be setup at https://github.com/lxc/lxd .
- Code to this project will be contributed under an Apache2 license, no CLA is required but we will require contributors to Sign-off on their commits as always (DCO).
- Discussions about lxd will happen on lxc-devel and lxc-users.
- Contributions to github.com/lxc/lxd will happen through github pull requests only and reviews will happen on github too.
This is kept separate from the main tree because at least initially, I believe it best to have a separate release schedule for both of those and because it tends to be easier for Go-only projects to live in theirown branch.
...
In order to be a good hypervisor, we also need to make containers feel like they are their own system and so we'll be spending quite a bit of time figuring out how to improve the situation. Some of the work presented at Linux Plumbers is going to contribute to that, like cgmanagerfs to provide a reasonable view of /proc and a fake cgroupfs, Seth's unprivileged FUSE mounts and all the cool things mentioned in Serge's earlier post about
Now as for the next steps. We will be creating the repository on github over the next few hours with Serge and I as the initial maintainers. Once the project is properly started and active, we will promote some of the most active contributors to commiters.
The first few commits in there will be text versions of the specifications we came up with until now. This should also serve as a good todo list for people who want to get involved.
Over the next few days/weeks, the existing code which was used for the demo at the OpenStack summit in Paris will be submitted through pull requests, reviewed and merge.
...
"
see more: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N...
and check the thread here :
[lxc-users]: https://lists.linuxcontainers.org/pipermail/lxc-users/2014-N...
[lxc-devel]: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N...