13:01:41 <esberglu> #startmeeting powervm_driver_meeting
13:01:42 <openstack> Meeting started Tue Apr 25 13:01:41 2017 UTC and is due to finish in 60 minutes.  The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:46 <openstack> The meeting name has been set to 'powervm_driver_meeting'
13:01:58 <edmondsw> o/
13:02:16 <thorst> o/
13:02:19 <thorst> efried: yep, understood
13:02:27 <efried> o/
13:02:59 <esberglu> #topic In-tree Driver
13:03:20 <edmondsw> sdague just +2'd #3 and #4
13:04:02 <jay1_> efried: It is not allowing with --nic none
13:04:05 <jay1_> neo@neo34:/opt/stack/powervm-ci/tempest$ openstack server create VM1 --image  Ubuntu2g --flavor CI_flv_1 --nic none
13:04:05 <jay1_> nics must be a list
13:04:22 <efried> jay1_ You need to set the API microversion.
13:04:27 <efried> Let's do this after the meeting.
13:04:31 <jay1_> sure..
13:05:20 <esberglu> Nice that we're continuing to make progress there
13:05:36 <thorst> very
13:05:39 <thorst> good work efried
13:05:44 <efried> :)
13:06:04 <efried> Soon's I see mriedem I'll pester him for +W.
13:06:09 <esberglu> Any actions we need to take in-tree atm?
13:06:24 <thorst> I'm reviewing for +1, though I think its mostly just for my own sanity
13:06:42 <esberglu> Yeah I have a couple that need a +1 still too
13:06:53 <thorst> and as we discussed, we'll need to get a little rigor around making sure we backport some of these changes to OOT
13:07:01 <efried> esberglu You have in-tree change sets up for review?
13:07:07 <thorst> that's an easy one to just forget to do
13:07:10 <esberglu> No I meant reviewing them
13:07:13 <efried> oh, okay.
13:07:42 <efried> So yeah, esberglu I don't know if you have a way for carrying forward action items to bring up in subsequent meetings, but...
13:07:48 <thorst> esberglu: if you have bandwidth, you could maybe help bring those IT patches back to OOT.  But I'm not sure what your BW looks like
13:08:19 <efried> Yeah, one would be that, or at least queueing up a recurring reminder that we need to do that at some point.
13:08:20 <thorst> ex. Things like this: https://review.openstack.org/#/c/438729/11..18/nova/virt/powervm/tasks/base.py
13:08:20 <esberglu> thorst: efried: Yeah I was already planning on doing that this sprint
13:08:36 <thorst> awesome.
13:09:01 <efried> Sweet.  That one specifically has an associated bug, esberglu - remind me to give it to you if you tackle that one.
13:10:04 <efried> esberglu https://bugs.launchpad.net/nova-powervm/+bug/1680947
13:10:05 <openstack> Launchpad bug 1680947 in nova-powervm "Use PrintingDurationListener, get rid of PowerVMTask" [Wishlist,New]
13:10:35 <esberglu> #action esberglu: Port IT changes OOT
13:11:09 <esberglu> #topic OOT Driver
13:11:13 <efried> Another item to queue up - not critical now, but hopefully will be in a week or two - do/should we re-owner wangqwsh's change set?
13:11:49 <thorst> efried: I'm not sure how to do that...but its not critical IMO
13:12:10 <thorst> I know he's not working on it anymore, but it wouldn't be awful for him to get some credit on it?  Though I admit he did not do the lion's share of the work.
13:12:11 <efried> thorst My only concern is that there may be some things we're not allowed to do to it if we don't own it.
13:12:22 <thorst> o, then yes
13:12:26 <thorst> that makes more sense then
13:12:27 <efried> Yeah, I'm less concerned about the credit.
13:12:36 <efried> But maybe we don't worry about it until/unless it becomes a problem.
13:12:46 <efried> At that point, I imagine the cores would be able to fix it for us.
13:12:54 <efried> Though for procedure's sake, the cores may want us to re-owner it anyway.
13:12:59 <thorst> its the OVS one?
13:13:08 <thorst> I think the rest had me as owner
13:13:17 <thorst> well the rest of the ones that aren't YOU
13:13:21 <efried> yeah - https://review.openstack.org/422512
13:13:23 <thorst> (even though they are you)
13:13:49 <efried> Right, cfg drive and local disk (and console) are under thorst
13:14:03 <thorst> I suspect the OVS one will be the trickiest.
13:14:08 <efried> There's some kind of co-authored-by tag.  Not sure if it's meaningful or what.
13:14:21 <thorst> probably only meaningful for credit (discount to PTG or something)
13:14:29 <thorst> highly doubt meaningful to gerrit
13:14:31 <efried> #action efried to ask nova cores what to do about new ownership / co-authorship of in-tree changes.
13:15:22 <efried> Today is launchpad cleanup day, so prolly not a lot of other stuff going to get done there.
13:16:05 <edmondsw> gerrit records both author and committer, with author being the most recent person to upload a changeset
13:16:12 <edmondsw> I think both get credit
13:16:19 <edmondsw> for PTG, etc.
13:16:22 <edmondsw> but I could be wrong there
13:16:34 <thorst> edmondsw: right, but not sure that a co-authored tag in the commit message get counted
13:16:39 <edmondsw> I have seen the coauthored tag... I think that's just to get credit in the commit message
13:16:42 <thorst> and if it does maybe just for PTG
13:16:57 <thorst> but, not super important for us to figure out in the mtg
13:16:58 <edmondsw> I would add the coauthored tag just to cover all bases
13:17:05 <thorst> +1
13:17:06 <edmondsw> yep
13:17:18 <efried> Other than backports, I don't have anything OOT until jay1_ gets back to testing with it.  There was that bizarre neutron problem that we never nailed down, but it may have been a one-off, env-specific.
13:18:27 <edmondsw> what about that localdisk one, and the 2 I see as WIP (config drive and ovs vif)?
13:19:07 <efried> edmondsw Yeah, those are the ones we're talking about, and the console one.
13:19:30 <efried> cfg drv, localdisk, and ovs vif all need to be rebased/finished.
13:19:37 <efried> ovs vif may or may not need a new owner.
13:19:41 <thorst> ovs vif will be the hard one...
13:19:42 <edmondsw> efried, but I mean more than just changing ownership, are we working on finishing them?
13:19:43 <efried> And all four may or may not need co-authorship.
13:19:48 <thorst> as it has CI changes.
13:19:52 <thorst> but I suspect we'll get to that later.
13:20:01 <efried> edmondsw Waiting until we get the first set merged (or closer to merged)
13:20:07 <edmondsw> k
13:20:16 <efried> There's four that should be ready for +W at this point.
13:20:27 <efried> I'll bug mriedem about those tomorrow, since today is bug day.
13:20:30 <thorst> are we at the OOT section of the meeting?
13:20:34 <thorst> I have a minor thing there...
13:20:34 <esberglu> Yeah
13:20:42 <thorst> Ok...I missed.
13:21:02 <thorst> basically, I'm pursuing some router fixes in neutron that don't really affect PowerVM, but rather all hypervisors
13:21:07 <thorst> we're just impacted because its wrong
13:21:16 <thorst> so that's what I'm doing 'OOT' wise...
13:21:49 <esberglu> Okay nice
13:21:50 <thorst> focus area is really just backports (which we have owner on) and then those blue prints we reviewed earlier
13:21:55 <thorst> making sure that we follow up on those items
13:22:08 <thorst> edmondsw: did you have a chance to talk to the PVC folks that were impacted?
13:22:10 <thorst> I haven't yet
13:22:37 <edmondsw> no
13:22:48 <edmondsw> I'll try to do that today
13:22:54 <thorst> #action edmondsw and thorst to discuss BP with PVC folks
13:23:17 <thorst> I think that's all I had.  Still want to investigate PCI pass thru, but lower priority
13:23:42 <esberglu> #topic PowerVM CI
13:24:12 <esberglu> Last afternoon a couple tests started failing consistently. I thought it was just a tempest conf thing, but apparently not
13:24:15 <efried> esberglu Saw another handful of "merge failures" this morning.
13:24:38 <esberglu> efried: That's pretty regular
13:24:38 <thorst> heh, yeah the CI appeared to go full crazy last night
13:24:49 <esberglu> I haven't had a chance to look yet today
13:25:09 <esberglu> But anyhow I was gonna disable those 2 tests while I investigate the cause
13:25:14 <esberglu> What do you mean full crazy?
13:25:28 <thorst> my inbox was full of failures
13:25:32 <thorst> which isn't crazy
13:25:40 <thorst> figured a test went rogue
13:25:48 <thorst> these were existing tests?
13:26:07 <esberglu> Yeah. 1 new unsupported test. 2 existing tests now failing
13:26:25 <esberglu> Will be putting up a changeset right after the meeting for those
13:26:30 <thorst> k
13:27:37 <esberglu> Other than that I have a handful of neo-os-ci patches up
13:27:44 <esberglu> Mostly small stuff, nothing critical
13:27:52 <esberglu> But also should be easy reviews
13:28:30 <esberglu> Planning to look into OVS support in CI this sprint
13:28:52 <thorst> lets find some time to talk through OVS
13:28:56 <thorst> we're going to have to use vxlans there
13:29:03 <thorst> which is going to be weird.
13:29:30 <thorst> efried: we'll also probably need some IT conf options for it too
13:29:49 <thorst> something to tell us the PHYP vSwitch to use (and each CI job will use a different one I think)
13:30:36 <efried> thorst Cool, I'll probably need a ground-up OVS primer anyway, if I'm going to have anything to do with that change set.
13:32:08 <thorst> efried: yep...it is super weird
13:32:15 <thorst> and contorting the CI to work with it will be...interesting
13:32:22 <esberglu> You guys want to do a call or just discuss it here later?
13:32:29 <thorst> probably a call
13:32:34 <thorst> but I need to do some research first
13:32:48 <thorst> lets get something teed up though, else I'll just keep deferring it to later
13:32:51 <edmondsw> thorst I'd be interested to attend that
13:32:57 <thorst> edmondsw: ack
13:33:03 <edmondsw> ?
13:33:12 <thorst> acknowledged
13:33:28 <thorst> #action thorst to set up OVS meeting
13:33:29 <edmondsw> ah... I was thinking "ack" as in "ugh" ;)
13:34:46 <esberglu> I think that covers everything CI
13:35:01 <jay1_> esberglu: WSGI_MODE issue is still there ?
13:35:30 <esberglu> Yeah still investigating a permanent solution. But using the deprecated option works for now
13:36:05 <jay1_> Ok..
13:36:25 <esberglu> #topic Driver Testing
13:36:40 <esberglu> jay1_: Sounds like you got through your stacking issues yesterday?
13:37:04 <efried> esberglu Yeah, couple things we ought to keep an eye on there.
13:37:15 <jay1_> Yes but primer lpar spawn is failing.. working with efried..
13:37:31 <esberglu> CI was having bad network performance yesterday, so I'm assuming your network issues were probably the same thing
13:37:32 <efried> 1) I had to hack functions-common to use --allow-unauthenticated for apt-get.
13:37:51 <efried> 2) git:// protocol was busted, had to change stackrc to use https
13:38:01 <efried> And yeah, 3) the WSGI thing.
13:39:01 <esberglu> Just adding that conf option for WSGI_MODE worked for you too correct?
13:40:09 <efried> yes
13:40:56 <efried> And post-stack, 4) API microversion; 5) stupid cells setup
13:41:34 <thorst> #easy #devops
13:42:05 <efried> For CI.
13:42:13 <efried> The rest of us poor schlubs have to do it by hand every time.
13:43:09 <jay1_> efried: the next SSP patch set will have most of the above mentioned fixes ?? Just wanted to understand the plan..
13:43:24 <efried> jay1_ Those have nothing to do with code.
13:43:25 <thorst> I think 1-5 are permanent
13:43:30 <thorst> semi permanent
13:43:38 <thorst> they're just part of the cost of using devstack presently
13:43:40 <thorst> and bleeding edge code
13:43:42 <efried> They're all operational garbage that has to be done when you stack.
13:43:44 <thorst> have nothing to do with PowerVM
13:43:46 <efried> right
13:44:32 <jay1_> ah.. okay..
13:44:53 <jay1_> but earlier these were not encountered just wondering..
13:45:57 <thorst> jay1_: so basically when you're dealing with bleeding edge community code
13:45:59 <thorst> things just break
13:46:04 <thorst> and you have to work around them
13:46:11 <efried> jay1_ Some are (hopefully transient) issues, like the git:// protocol thing.  Some are (hopefully transient) bugs, like the --allow-unauthenticated thing.  Some are permanent changes made by the community that we just need to start accomodating, like the WSGI thing.
13:46:11 <thorst> even if they're unrelated to your testing
13:46:17 <thorst> its a constant state of turmoil
13:46:25 <esberglu> Yep
13:46:31 <thorst> and its how the community moves forward...kinda a no fear approach
13:46:57 <thorst> it settles down as we get closer to release freeze
13:47:12 <jay1_> Ok
13:48:40 <jay1_> efried: These are specific to IT only ? latest OOT doesn't need all these work arounds?
13:48:55 <efried> jay1_ Some of them.
13:49:25 <jay1_> of course WSGI is common one.
13:49:27 <efried> The microversion thing should only be necessary in-tree before we have network support, because as far as I've seen, --nic none is the only thing we need that isn't supported at the default microversion.
13:50:03 <esberglu> The rest are both
13:50:05 <efried> But #1-3 and #5 are going to be necessary IT and OOT.
13:50:06 <efried> yup.
13:50:28 <jay1_> sure.
13:51:07 <esberglu> #topic Open Discussion
13:51:18 <esberglu> Anything else today?
13:51:42 <thorst> How's everyone doing?
13:51:47 <thorst> :-p  kidding
13:51:49 <thorst> I've got nothing
13:52:12 <jay1_> thorst: for this iscsi, it is enough to do either with Devstack or OSA right ?
13:52:28 <thorst> we need a live migration done with either devstack or OSA
13:52:40 <efried> Guess you'll need two hosts.  Do you have another one?
13:52:45 <thorst> I'm now leaning towards devstack because OSA set up on the cinder side has proved to be challenging
13:52:49 <thorst> efried: I can source another.
13:53:04 <thorst> I just want an iscsi attach proven first to the existing system
13:53:07 <thorst> then we can get the other ready
13:55:22 <efried> Anyone know how to code oslo_config to load up a conf file?
13:55:56 <esberglu> Nope
13:57:13 <efried> Well, then nothing else from my end.
13:57:23 <jay1_> thorst: I have got another host from PVC FVT pool, for OOT + ISCSI
13:57:52 <jay1_> I think we may need two
13:58:44 <thorst> jay1_: I will get you another after we get the attach going
14:00:01 <jay1_> as my current host is having IT now, Shall we wait until it is done ? I was just wondering to make another system ready to have simultaneous tracking..
14:00:39 <thorst> jay1_: testing on your current host should be wrapped up today in my opinion
14:00:41 <efried> jay1_ I'd like to validate SSP and console IT before you blow away your current stack.
14:00:52 <efried> thorst Yeah, unless neutron is still giving us the finger.
14:00:53 <thorst> then we can just restack for OOT
14:01:01 <thorst> efried: sure, but you're setting that to --none
14:01:01 <thorst> :-)
14:01:07 <thorst> so neutron's cut out
14:01:22 <efried> So by the way, if you stack OOT, you can run IT on same stack.
14:01:44 <efried> That might be the way to go, so we don't have to keep restacking all the time.
14:02:39 <thorst> that's a nice idea
14:03:02 <efried> thorst Are you doubting, Mr. Doubty McDoubterpants?
14:03:26 <efried> I've done this.  Just have to change the compute_driver in nova.conf and restart n-cpu.
14:03:48 <thorst> no
14:03:58 <thorst> no doubt...just seems logical and obvious in retrospect
14:04:02 <thorst> just never something I considered
14:05:30 <efried> I haven't done it a lot; and I suppose it's possible we may run into issues with the custom networking agents running when we're IT, but I wouldn't think so.
14:06:35 <esberglu> Alright we're over time so I'm calling it
14:06:39 <esberglu> #endmeeting