14:08:45 <adreznec> #startmeeting powervm_driver_meeting
14:08:46 <openstack> Meeting started Tue Jan  3 14:08:45 2017 UTC and is due to finish in 60 minutes.  The chair is adreznec. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:08:49 <openstack> The meeting name has been set to 'powervm_driver_meeting'
14:09:07 <adreznec> Super formal now
14:09:25 <thorst> so namespace change?
14:09:50 <adreznec> #topic In-tree driver status
14:10:28 <adreznec> So where did we leave off there? I know the three of us each had discussions before the holidays
14:10:30 <efried> #link https://review.openstack.org/413736
14:10:35 <adreznec> And efried sent out a note on things
14:10:46 <thorst> I think we all agreed we need a namespace change
14:10:58 <thorst> need being flexible...  It's the least evil
14:11:21 <adreznec> Yeah, no good way around it
14:11:40 <thorst> efried's got that link...we have nova_powervm, but in the e-mail he suggested powervm_ext
14:11:46 <thorst> I kinda like powervm_ext better...
14:12:06 <adreznec> yeah, I know you and I had discussed something similar
14:12:25 <adreznec> I'm in agreement as well - makes things clear to users that this is the external driver
14:12:29 <thorst> what did the hyper-v guys do though/
14:12:38 <adreznec> they just called it compute-hyperv
14:12:40 <thorst> I know you had looked that up earlier.
14:12:45 <adreznec> Same as the project name
14:12:47 <thorst> ahh, I think powervm-ext is better?
14:12:52 <thorst> at least for our needs...
14:13:23 <efried> I'm fine with that.  Any other opinions?
14:13:52 <efried> #action efried to change namespace from nova_powervm to powervm_ext
14:13:53 <adreznec> their full oot namespace is nova.virt.compute_hyperv
14:14:01 <adreznec> I don't think there's any real standard though
14:14:10 <adreznec> So lets go with powervm_ext
14:14:13 <thorst> rip it
14:14:24 <efried> And
14:14:37 <efried> #action wangqwsh to confirm this fixes whatever issues he was seeing.
14:15:01 <efried> But before we merge, we need to resolve the other stuff I brought up.  Lemme reread...
14:15:29 <adreznec> Yeah, was just bringing up that email
14:15:40 <thorst> your bullet-point 3...do we need networking-powervm changes as well to support this
14:16:02 <thorst> basically, one solution would be the networking-powervm agent listens to powervm or powervm-ext...
14:16:17 <adreznec> Yep
14:16:19 <thorst> though, I'm not sure that is really the case...
14:16:39 <adreznec> I guess that depends
14:16:44 <thorst> I think both agent types know how to deal with pvm_sea, much like KVM, hyper-v and PowerVM all know how to deal with a type of 'ovs'
14:16:45 <adreznec> Are we supporting SEA with the in-tree driver today?
14:16:54 <thorst> no, but eventually we will...
14:17:18 <efried> What kind of network does the current in-tree driver support?
14:17:21 <adreznec> So I guess the question is do we just change it to powervm_ext until we do
14:17:28 <efried> We're not going to pass squat in CI without a network.
14:17:31 <adreznec> or do we allow both for now
14:17:44 <adreznec> I think LBr/OvS for simplicity?
14:18:07 <efried> Is the code for those guys in place in the first change set?
14:18:41 <efried> Cause there once again we're inflating that change set, which we're really wanting to avoid.
14:19:02 <thorst> so networking isn't going to come in yet.  That was going to be WIP6
14:19:05 <thorst> I didn't get to that one yet
14:19:25 <thorst> in our BP we said that we'd use OVS, but that has CI changes that we need to work through
14:19:40 <thorst> and yeah...we're not going to get far on Tempest with these initial change sets.  That's chicken/egg...known problem
14:20:39 <efried> Meaning we're going to accept failing CI initially?  Is the community going to go for that?  I've been getting the impression they wouldn't.
14:21:00 <thorst> I think it depends.
14:21:17 <efried> Or back to the discussion on paring down CI for in-tree-only
14:21:21 <thorst> having the passing powervm_ext CI will help
14:21:27 <adreznec> Right
14:21:32 <thorst> no, we have to have two CI's.
14:21:37 <thorst> one in tree, one out of tree
14:21:46 <thorst> and its really 'one CI', just running two different jobs.
14:22:12 <thorst> different tests for the in-tree (while we get support in - though I suspect change set 1 won't pass much of anything)
14:22:14 <efried> Well, wanted to punt that to the other #topic, but briefly: we're going to have a volume problem if we literally run two CIs on every change set.
14:22:31 <thorst> efried: I'm not sure about that...we're sitting OK volume wise atm
14:22:39 <thorst> like to the point we could run much more.
14:22:50 <thorst> we solved a big bottleneck mid Dec.
14:23:15 <efried> Okay, good deal.
14:23:27 <efried> So back to VIRT_DRIVER.
14:23:32 <thorst> and if we are bad on capacity, we'll figure it out
14:24:03 <efried> I still contend we need to understand more about what that thing means before we start mucking with it.
14:24:04 <adreznec> efried: we'll also theoretically be getting more systems... details are still being worked there
14:24:49 <adreznec> In devstack, VIRT_DRIVER is what enables the plugins for a nova driver
14:25:16 <adreznec> So for example, if you set VIRT_DRIVER= libvirt, it'll run https://github.com/openstack-dev/devstack/blob/d0df7c88f2c4d8e929c635beca55e6efc69be2f5/lib/nova_plugins/hypervisor-libvirt
14:26:06 <thorst> adreznec: that brings up a good point...do we need a devstack change for powervm as it goes in tree (maybe that's a discussion for later, once we're further along)
14:26:10 <adreznec> There are a couple of other misc places it pops up as well, checks for setting specific variables in things like OVS config if a specific VIRT_DRIVER is specified
14:26:14 <adreznec> Yes
14:26:25 <adreznec> We need lib/nova_plugins/hypervisor-powervm
14:26:27 <efried> That's what wangqwsh was going to work on, per email thread, yes?
14:27:57 <adreznec> I thought so
14:28:07 <wangqwsh> yes, hypervisor-powervm is used to fix the VIRT_DRIVER type in devstack
14:29:50 <efried> Perhaps the question is whether it's actually appropriate for networking-powervm to be using VIRT_DRIVER to decide which network plugins it loads.
14:30:14 <efried> Versus, perhaps, a conf setting.
14:30:15 <thorst> efried: I contend it doesn't...where are you seeing that it does?
14:31:04 <efried> #link https://github.com/openstack/networking-powervm/blob/master/devstack/settings#L6
14:31:29 <thorst> ahhh, OK.
14:31:44 <thorst> networking-powervm's *devstack* (which I guess I was missing) assumes that.
14:32:02 <adreznec> Yeah
14:32:13 <adreznec> I mean we could definitely find something else to key off
14:32:14 <thorst> ok...I was off in kansas then.
14:32:28 <thorst> well, I think that's a good default.
14:32:37 <adreznec> Just seemed like a fair thing to do at the time as there was no case to ever load the driver without having VIRT_DRIVER=powervm
14:32:49 <thorst> right...and at the time it was the only one that worked.
14:32:51 <thorst> now we have OVS
14:32:52 <adreznec> I think we have three options at this point
14:33:08 <thorst> but I think if using powervm_ext, I think it is appropriate to default to enabling the sea-agt and sriov-agt
14:33:21 <thorst> I'd assert it's always OK (if PowerVM anything) to start the sriov-agt
14:33:25 <efried> So the code is smart enough not to blow up if VIRT_DRIVER=foo and there's no hypervisor-foo - else our oot driver would have blown up.
14:33:53 <adreznec> 1) Make it an explicit conf setting. 2) Change it to just powervm_ext and add powervm back later. 3) Support both
14:34:03 <efried> I vote for #1.
14:34:11 <adreznec> And yeah efried, devstack will ignore things if hypervisor-foo doesn't exist
14:34:12 <efried> OOT isn't using it for anything else at the moment.
14:37:27 <efried> Today we have [ml2] with mechanism_drivers={comma-separated list, e.g. pvm_sea,pvm_sriov}
14:37:32 <efried> in ml2_conf.ini
14:37:58 <efried> Now, I still don't really get what's a plugin and what's ML2 and what's a driver and what's a ... whatever.
14:38:15 <thorst> efried: yeah, its weird...
14:38:30 <efried> So if it's not appropriate for us just to key off of the above, we could make a similar conf option that tells us what to load up.
14:38:35 <thorst> I think I'm OK with option 1...but we should call that out in nova_powervm's change set that you now need to explicitly set the neutron plugin
14:38:38 <adreznec> I'd be okay with either, we just need to be explicit on the decision
14:38:46 <thorst> actually, I think that devstack defaults to ovs now
14:38:51 <thorst> so we should probably default to that
14:38:59 <thorst> but if they explicitly set sea, we should disable OVS...
14:39:08 <efried> Is this a devstack thing, or a runtime thing?
14:39:13 <thorst> (we've gone down a hell of a rabbit hole)
14:39:15 <thorst> devstack thing
14:39:24 <efried> Okay, so local.conf, not nova/neutron.conf
14:39:30 <thorst> right.
14:39:42 <thorst> nova will figure out what to do based off the vif binding
14:40:02 <efried> Ah, and blow up if there's no appropriate driver/plugin/widget/thingy.
14:40:06 <thorst> key is...only one L2-ish plugin can run at once (with the exception of macvtap and sr-iov, which can run in parallel)
14:40:22 <thorst> if running sea, can't run ovs.  And vice versa
14:41:00 <efried> Okay, so we need #action somebody to propose this to networking-powervm.
14:41:11 <efried> volunteer?
14:41:35 <efried> #crickets
14:41:43 <adreznec> I can throw something together
14:41:51 <thorst> lol - as I was typing he saved me
14:41:51 <efried> Thanks.
14:41:51 <thorst> phew
14:42:14 <efried> #action adreznec to propose networking-powervm change to move from VIRT_DRIVER to local.conf option to decide which networking thingies to install.
14:42:38 <adreznec> Huzzah
14:44:22 <efried> What's next?
14:44:38 <efried> We may be able to get some mileage out of the dual-CI discussion without esberglu here.
14:44:54 <efried> And load him up with corresponding #actions for when he gets back ;-)
14:45:48 <efried> wanna?
14:45:53 <thorst> heh, lets just take a moment to congratulate him (without him here) on how well the CI has been running
14:46:53 * efried bows head for introspective moment of silence.
14:47:27 <thorst> so, what's the discussion CI wise.
14:47:51 <thorst> single CI - run two jobs for each nova patch.  One in tree, one out of tree.  Different config files.  Configs changing rapidly for in tree as function gets added.
14:48:08 <adreznec> Yeah
14:48:17 <adreznec> Different configs and different test lists
14:48:32 <thorst> we want to use OVS...which will be a deeper discussion
14:48:42 <thorst> but one we've been having (lightly) for the OSA discussion
14:48:51 <thorst> so this will help our OSA CI as well
14:49:15 <efried> Anybody remember where we are wrt converting test names to idempotent IDs?
14:49:39 <thorst> he has a patch set up for that
14:49:45 <thorst> not sure if merged.
14:49:47 <efried> link?
14:50:02 <thorst> its on morpheus...let me look up
14:50:24 <efried> got it
14:50:30 <efried> 4650
14:50:51 <efried> ah, good, he's got the test names in comments next to the IDs.
14:50:54 <efried> That's what I wanted to make sure of.
14:50:59 <efried> Else maintainability nightmare.
14:51:56 <thorst> efried: agree.
14:51:58 <efried> I gave that change set +2
14:52:23 <thorst> its been a month  :-)
14:52:25 <efried> We'll let esberglu merge it, cause I want him to make sure it really works (i.e. getting parsed properly)
14:53:39 <efried> added comment to that effect.
14:53:45 <efried> What else?
14:54:12 <efried> (is there a way to queue this dual-CI agenda item up for next time when esberglu is here?)
14:55:07 <thorst> efried: make an action for him to lead that discussion?
14:57:07 <efried> #action esberglu to drive discussion: two CI runs per change set: in- and out-of-tree.  In-tree much smaller, with plan to grow in lockstep with in-tree driver merges.
14:57:27 <efried> (where "smaller" really means "larger skip list")
14:58:07 <efried> We done for now?
14:58:51 <thorst> yeah, lets call it
14:59:02 <thorst> glad to have you back efried  :-D
14:59:13 <efried> Glad to be here.
14:59:16 <efried> adreznec, gavel?
14:59:51 <efried> (he's waiting for precisely top of the hour)
15:00:37 <efried> (or getting coffee)
15:02:00 <adreznec> #endmeeting