< Meetings | Libvirt
Revision as of 16:04, 20 May 2014 by Daniel Berrange (Created page with "= Libvirt Sub-Team Meeting = == Agenda: 2014/05/20== Please put your full name + IRC nick against any agenda items you add * Introduction to the new team (Daniel Berrange /...")
Libvirt Sub-Team Meeting
Please put your full name + IRC nick against any agenda items you add
- Introduction to the new team (Daniel Berrange / danpb)
- Suitability of meeting time
- Other possibility: Monday 1600 UTC ?
- Alternate with Tuesday 0900 UTC to help China/Japan/India contributors ?
- Libvirt HV driver support requirements
- ie what features must a libvirt driver provide, in order to be useful for Nova
- The future of Libvirt/Xen (Christian Berendt / berendt)
- B1 systems, Citrix and SUSE to investigate CI options
- Consider using 'block' FS type instead of exclusively using bind-mounts (Rick Harris / s1rp)
- Current code is very complex because is uses `virt/disk/mount.py` to make loopback and nbd devices available as bind-mounted fileystems
- We could use Libvirt's native handling of block devices to simplify the code
- Block handling was added in 0.9.6 (current min required version) https://github.com/c4milo/libvirt/commit/77791dc0e162463f3d885ea6481d07bae29d2494
- Can't remember exact details, but there were some bugs in this initial support which had follow on patches, so might need something newer than 0.9.6. We want to bump min Nova libvirt to 0.9.11 anyway
- Side-note: This would allow us Rackspace to drop a patch we're holding for a NoopMounter that we were going to contribute upstream
- Question: What would the migration path be for instances already using bind-mounts for NBD, loopback, etc?
- On restart do they use the new 'block' method?
- Do we deprecate bind-mount (for block backends) in K-release, and remove in L-release?
- Caveat: What to do about global chown across the entire FS to handle UID mapping?
- Do this in Glance on image-import?
- Or can we get the kernel guys to provide a way to set mapping at mount time...
- One first then the other? Yep, we'd need to support today's kernels :)
- The future of LXC in the Libvirt Driver (Rick Harris / s1rp)
- Cleanup image handling code
- Expose UID and GID mapping
- Environment variable handling (requires libvirt work)
- Should init path be exposed as well? (Andrew Melton / apmelton) yes
- Process return/exit code (requires libvirt work)
- I've proposed this https://review.openstack.org/#/c/88062 to handle the lxc disks (including block dev, which currently dosn't work), until we will move to a newer libvirt version.
- Bug triage (Kashyap Chamarthy/ kashyap)
- Monthly bug triage day? Currently 118 bugs tagged as 'libvirt'
- Periodically go through Nova bugs, find libvirt specific bugs, tag them appropriately. Root-cause analysis, general bug triage work flow -- https://wiki.openstack.org/wiki/BugTriage
- LibvirtLXC testing infrastructure (Thomas Maddox / thomasem)
- We met some folks at the summit who seemed pretty interested in helping with the CI infrastructure to bring LXC support up to snuff in terms of testing/gating
- RAX have a person looking at LXC tests for CI
- LXC CI will probably be done as part of the official gate, rather than 3rd party CI