Blueprint changed by Serge Hallyn: Whiteboard changed: - This blueprint is broken into 3 sections - libcgroup, lxc, and - qemu+libvirt. + [USER STORIES] - ==== Background on libcgroup ==== - libcgroup is a package which provides: - a. Flexible boot-time setup of cgroups - b. Command line tools to configure and use cgroups - c. A deamon to auto-reclassify tasks into cgroups + Abe would like to run untrusted workloads in a container. - There were two important bugs in libcgroup: - 1. Cgroup setup was done too late, after some daemons had - started. This was solvable. However there was an attitude that - it could simply reclassify daemons which had already started. - It couldn't do that right. - 2. Auto-reclassifying tasks into cgroups cannot be done - correctly with current kernel support + Billy would like for his users to be able to use containers without + giving them root access. - Because properly mounted cgroups are crucial to libvirt and lxc, we - temporarily worked around this by introducing cgroup-lite, which - introduces tiny, inflexible upstart jobs to mount cgroups. This was - meant as a temporary step until libcgroup could be improved. + Charlie would like to confine users with flexible cgroups. - In the meantime, a few things have happened - 1. libcgroup functionality is being moved into systemd. - 2. libcgroup has dropped its faulty startup scripts so that it be - installed alongside cgroup-lite - 3. Upstream kernel cgroup maintainer wants userspace to stop dealing - with cgroupfs, and use a new (not yet designed) library instead + Denise is writing an application using containers, and wants to re-use + the tested core lxc API. - In the medium term we wanted to - 1. Write sysvinit scripts to mirror the cgroup-lite upstart jobs, and - provide them together in libcgroup. - 2. Support some flexible boot-time cgroup setup. This is especially - required so that users can be confined by memory cgroup in the face - of unprivileged user namespace cloning. + Erica would like openstack-lxc users to have all the advanced features + of lxc (apparmor protection, nesting, etc). - That way cgroup-lite could then be replaced by libcgroup again. + [ASSUMPTIONS] - We should also begin working with wider communities on designing the - cgroup library interface to be used above cgroupfs. This design should - account for clean nesting in containers, so that the library running in - a container can forward requests (i.e. cgroup creation and - configuration) to the library on the host. + A fix is accepted upstream to allow user namespaces to be used alongside + XFS. - https://lkml.org/lkml/2013/4/5/535 - https://lkml.org/lkml/2013/4/9/651 + [USER ACCEPTANCE] - ==== Background on LXC ==== + Set up a user with subuids and use it to create and run a container. - Over the past several cycles we have been working toward a specific - vision of where we want LXC to be for 14.04 LTS. This has been - laid out in several places, and has also been codified in the form - of a roadmap toward the upcoming 1.0 LXC release. That roadmap can - be seen at + [RELEASE NOTE/BLOG] - https://wiki.ubuntu.com/LXC/1.0-roadmap + User namespaces, apparmor, and seccomp are now leveraged to provide a + secure container environment. - For 13.10, we intend to focus on the harder, more fundamental pieces, - which will be scarier during an LTS cycle. This includes the core - of the remaining user namespace, completing the most-wanted features - in the API, and monitor and control socket work. + Containers can now be created and used by unprivileged users. - Specific pieces which would best be completed in 13.10 include - unprivileged use of user namespaces - full user namespace support in kernel - attach, clone, and console support in API - userns patches merged into upstream shadow package - ability to use lxc-fuse in ubuntu package - libvirt driver based on lxc api - lxc.hook.clone (and lxc-create/destroy hooks) - lxc-snapshot in the api - stable lxc trees? (v0.7.5, v0.8.0, v0.9.0, etc) - - ==== Background on qemu and libvirt ==== - - Libvirt is doing quite well. Libvirt-lxc offers a challenge for us - it - has recently been better supported than in the past, with support for - qemu-nbd devices being added. However, it does not currently have a good - apparmor profile, and uses a completely different code base from upstream - lxc. We might have to choose between filling in missing features in - the libvirt-lxc, and implementing a new driver using the upstream lxc - api. We may do both and let users choose, however beside additional - development work it also provides duplication for testing and bug - control. - - The edk2 package which provides a bios capable of UEFI secure boot - currently works, but has no way to save/restore nvvars across qemu - runs (vm reboot is ok). If that feature were added, it should be - useful for ubuntu image tests. - - * edk2: - - debug builds (carried over) - - ability to save/restore NvVars - . not in ovmf yet - . proposed through qemu flash support - * openbios-sparc: fix 64-bit bios - * better qemu-user arm support (Help fixing some of the current bugs) - - * libvirt lxc driver based on the lxc api - - * target qemu 1.5, libvirt 1.0.6, xen 4.3 ? - - notes from smb on xen: - * Switch from xm to xl as default. That will have some effect on libvirt - integration (Openstack still rather favours XCP?). I think libvirt has - the basic pieces but right now the libxen-dev does not contain the necessary - headers/libs to make libvirt try to compile that. - * Switch from qemu-dm to qemu upstream. I need to check the roadmap/ask people - how feature complete upstream qemu now is. Ideally I would wish there only - be one upstream qemu binary that supports Xen and KVM. So we could only - depend on qemu instead of compiling something as part of the Xen build. - Not sure this is what upstream thinks. - * EFI Xen. I believe there is a bootloader but likely needs to be specifically - requested in the build. Also this rises the question on how to integrate that - into our boot story. Can grub.efi chain into another xxx.efi? - * Upstartify the init scripts. I got something that works to a certain degree - but had some issues on the way down. Nice to have but not highly important. - * How to handle that the hypervisor drops support for 32bit. + There is built-in support for boot-time configuration of control + groups.
-- Virtualization Stack Work for Saucy https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-virtstack -- Ubuntu-server-bugs mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
