15:01:01 <danpb> #startmeeting libvirt
15:01:02 <openstack> Meeting started Tue May 27 15:01:01 2014 UTC and is due to finish in 60 minutes.  The chair is danpb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:05 <openstack> The meeting name has been set to 'libvirt'
15:01:17 <lparth_> hello
15:01:21 <apmelton> o/
15:01:39 <jgrimm> o/
15:01:53 <danpb> ah, great, some people added some agenda items
15:02:01 <thomasem> o/
15:02:19 <thomasem> Yeah, wouldn't want crickets chirping, now would we?
15:02:23 <sew> o/
15:02:29 <danpb> lets be traditional and begin at the beginning
15:02:43 <danpb> #topic LXC boot from block device
15:02:56 <danpb> vladikr: you added this item ....anything you want to say
15:03:20 <vladikr> danpb, thank you for the help with this
15:03:48 <vladikr> I'm a bit confused with what should actually be done regarding your last comment
15:04:25 <s1rp> o/
15:04:27 <danpb> i think that all we need is a bit more description about some of the supported scenarios
15:04:27 <vladikr> on checking the number of partitions in the volume
15:04:35 <vladikr> and shouldn't we do the same for images, in this case?
15:04:57 <danpb> ie say that the change is only intended to work with the case of an unpartitioned block dev
15:05:29 <danpb> and describe the security considerations inherent in mounting untrusted filesystems
15:05:52 <danpb> vladikr: yes most of the comments there apply just as well to images
15:06:12 <danpb> so you're spec is really just going to be describing the status quo
15:06:17 <vladikr> danpb, ah, I see, it's not about the actual implementation? they don't expect us to mount the device and look into how many partitions are there?
15:06:35 <danpb> no, no, definitely not
15:06:47 <danpb> just document what scenarios you intend to support with your change
15:07:00 <vladikr> danpb, ok :) thanks, I got it.
15:07:13 <danpb> ok cool
15:07:37 <danpb> #topic IPv6 Guest Configuration
15:07:49 <danpb> thomasem: ^^
15:08:16 <thomasem> So, s1rp and myself were messing around with IP configurations in the guest. Pretty much the scenario is the /etc/network/interfaces file is generated for the guest, and then cloud-init uses that.
15:09:18 <thomasem> We found that IPv6 was failing to get configured since, when it used an inet6 static configuration in the interfaces file, the upstart job was trying to change the following value via sysctl: net.ipv6.conf.eth0.autoconf=0
15:09:38 <thomasem> it appeared to be the case outlined in this bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/964882 from a couple years ago
15:09:49 <danpb> hmmm, ok, interesting problem
15:09:56 <thomasem> Libvirt mounts /proc/sys as readonly
15:10:04 <thomasem> So, I'm wondering
15:10:35 <danpb> so the mounting of /proc/sys readonly is mostly considered security-through-obscurity - it only ever really prevented accidental changes
15:10:53 <thomasem> hmm okay
15:11:05 <danpb> real security requried that SELinux/AppArmour prevent the changes, or for user namespaces to be active
15:11:25 <s1rp> right, so we made a change that just made /proc/sys/net RW, but left everything else RO
15:11:29 <thomasem> So, that's what I'm wondering... with the appropriate documentation, could we change that and assume that if you want that security, you'll use namespaces?
15:11:44 <thomasem> based on the documented way to secure containers :)
15:12:16 <thomasem> I found that when I changed the host value, it wasn't reflected in the guest, so the guest seems to have its own set of values, at least in /proc/sys/net.
15:12:20 <danpb> so the problem is that some stuff in /proc/sys/net is host-global while some stuff is namespace-local
15:12:24 <thomasem> oh
15:12:50 <danpb> when user namespaces are active we'd need to figure out how to allow access - presumably we'd have the chown the files we need to grant acess for
15:13:52 <danpb> thomasem: oh, hmm, i thought that only the tunables related to network interfaces were made local, but perhaps the kernel does more than i thought
15:14:23 <danpb> in any case, doing a read-write mount is easy enough in libvirt for the non-userns case
15:14:28 <thomasem> danpb: I didn't test thoroughly, or anything, I just know that the value it was trying to set when configuring IPv6 wasn't the shared between host and guest.
15:14:52 <thomasem> s/the//
15:14:55 <danpb> we'll need to check what we can do in the user-namespace case  - hopefully chown would work
15:15:30 <danpb> this is probably something we should just take to the upstream libvirt mailing list, since i think any fix belongs in the libvirt layer
15:15:38 <thomasem> agreed
15:15:40 <thomasem> I'll do that
15:15:59 <hallyn> and any place where chown does not suffice might require kernel fix (i.e. s/capable/ns_capable in sysctl handler)
15:16:45 <danpb> hallyn: yep, good point
15:17:25 <thomasem> +1
15:17:49 <thomasem> Okay, I'll write up an e-mail when I get a chance with some gists and what-not to help the discussion and fire off to the libvirt upstream ML
15:17:55 <danpb> ok, great
15:18:15 <danpb> #topic Config drive with LXC
15:18:37 <s1rp> yeah, so we want to be able to pass info into the guests, just like the hypervisor case
15:18:56 <danpb> yep, use case totally makes sense
15:18:57 <s1rp> seems like there are two possible approaches, blockstyle and fs-style
15:19:14 <s1rp> i've already done fs-style, using a plain-old directory that gets bind mounted
15:19:28 <s1rp> but for the upstream patch, i'm thinking that block-style would be more 'harmonious' with the other hypervisors
15:19:39 <s1rp> since it doesn't introduce another config-drive backend
15:19:44 <danpb> hmmm, i could see that fs-style is more convenient for containers though
15:19:51 <s1rp> it really is
15:19:58 <s1rp> and it's a very small patch
15:20:01 <danpb> because if your container image is a single app binary that is launched as init
15:20:17 <danpb> then you don't need to worry about having a shell wrapper script to mount the config drive and so forth
15:20:30 <danpb> openstack just takes care of making it immediately accessible to the app
15:21:06 <danpb> FWIW,  a FS style approach is not totally unreasonable for hypervisors too
15:21:19 <danpb> KVM has 9p filesystem passthrough from the host, and vmware has a shared filesystem capability too
15:21:45 <thomasem> s1rp: Maybe we should toss that patch upstream and see where it goes?
15:22:01 <danpb> so I think it is pretty reasonable for openstack to support both FS-style and block-style config drives
15:22:06 <s1rp> danpb: good poiints
15:22:09 <s1rp> thomasem: yeah, can do
15:22:36 <s1rp> i can toss up the patch, wonder if i need to retroactively create a spec
15:22:40 <danpb> i think FS style approach would probably appeal to docker people too
15:22:43 <s1rp> it's so simple, i hope not
15:22:49 <thomasem> It's like 3 lines of code, lol.
15:22:56 <thomasem> pretty awesome, imo.
15:23:02 <danpb> i think you do need to have a spec
15:23:18 <danpb> if only to let us bikeshed about the "best" mount point for the config drive
15:23:42 <thomasem> Haha, well by default cloud-init looks in /var/lib/cloud/seed/config_drive
15:23:55 <danpb> and to allow us to explain why it is conceptually useful for multiple hypervisors, even if we don't intend to implement fs-approach for others
15:24:12 <s1rp> yeah have it hard coded to config-drive's preferred dest, but could make it configurable
15:24:14 <danpb> thomasem: ah, well that's something to say in the spec :-)
15:24:17 <s1rp> with cloud-init the option's default
15:24:23 <thomasem> definitely
15:25:53 <thomasem> cool cool, s1rp, I'll work with you on that
15:26:04 <danpb> good, sounds like a plan
15:26:17 <danpb> #topic Any other business ?
15:26:32 <danpb> ....we're out of agenda items now... so speak up if you've anything else to add
15:26:50 <s1rp> so remove-fakelibvirt turned out to be pretty contraversial
15:27:03 <s1rp> busy at the moment, so holding off for a bit, hope to get to it later in the cycle
15:27:05 <danpb> lol, yeah
15:27:37 <danpb> it isn't really blocking anything on critical path, so no particular rush
15:27:50 <s1rp> yeah exactly, just sort of a nice-to-have
15:28:06 <s1rp> but johannes had a good point about trying to figure out what's expected across hypervisors testing-wise
15:28:21 <s1rp> right not it's very ad hoc, some integration tests, some unit, etc
15:28:41 <thomasem> How're they going to figure that out?
15:28:56 <thomasem> or we, rather... not sure what all's involved there. :)
15:29:02 <danpb> yeah, its kind of fuzzy
15:29:04 <s1rp> guessing we just need a ML thread to hash it out
15:29:08 <thomasem> Gotcha
15:29:11 <danpb> i was always rather under the impression that its primarily unit testing
15:29:26 <s1rp> so i think it's mostly integration tests under the guise of unit-tests
15:29:28 <danpb> but that we need the real libvirt module around, so we can access module constants & the like
15:29:38 <s1rp> i think we have very few true unit-tests
15:29:53 <s1rp> but that's a whole can-of-worms :)
15:30:05 <danpb> s1rp: the stuff in nova/tests/virt/libvirt  isn't actually making changes against the real hypervisors though is it ?
15:30:06 <thomasem> Yeah...
15:30:14 <apmelton> s1rp: true unit tests turn out to have tons of @patch's in nova >_>
15:30:27 <thomasem> Lol! Boy, do they.
15:30:29 <danpb> i mean it might connect to the hypervisor, but its stubbing out the real interesting APIs to avoid hitting the host
15:31:09 <s1rp> danpb: yeah, we're not hitting the real hypervisor, but we're making very high-level calls and then asserting stuff at a very low-level (via fakelibvirt or fakexenapi), so we're testing multiple 'units'
15:31:46 <danpb> ok, right, i see what you mean
15:32:17 <danpb> i guess i was still thinking of that as unit testing but I see why you might call it integration testing
15:32:47 <s1rp> yeah consistent terminology is probably half-the-battle
15:33:03 <s1rp> so many of the discussions about this, we end up talking past each other
15:33:32 <danpb> yeah, i can imagine
15:34:02 <danpb> anyhow, I guess we can end this meeting now
15:34:24 <danpb> thanks to all for coming, see you same time / place next week
15:34:32 <apmelton> o/
15:34:36 <vladikr> thanks
15:34:40 <thomasem> Thanks! o/
15:34:50 <lparth_> thanks
15:34:58 <danpb> #endmeeting