[Blueprint servercloud-s-virtstack] Virtualization Stack Work for Saucy

[Serge Hallyn]

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