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