14:00:03 <esberglu> #startmeeting powervm_driver_meeting
14:00:03 <openstack> Meeting started Tue Jan 17 14:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:07 <openstack> The meeting name has been set to 'powervm_driver_meeting'
14:01:13 <efried> o/
14:01:30 <wangqwsh> :)
14:01:34 <efried> adreznec thorst
14:02:10 <thorst> o/
14:02:29 <esberglu> #topic Status
14:02:51 <xia> Hi all, it's my first time to join this meeting, I'm Yan Xia,wangqw's team member
14:03:04 <thorst> hey xia!
14:03:07 <efried> Welcome.
14:03:18 <esberglu> Hi!
14:03:30 <xia> Thanks!Glad to meet you all!
14:03:56 <esberglu> Anyone have status? I'm still a bit out of the loop for where we are on this
14:04:10 <efried> I'll do a quick summary of the in-tree driver work.
14:04:18 <efried> We have four change sets out there.
14:04:53 <efried> https://review.openstack.org/391288  https://review.openstack.org/409401  https://review.openstack.org/409402  https://review.openstack.org/409404
14:04:59 <efried> ...in that order.
14:05:09 <thorst> efried: we still need a vif one to be seeded?
14:05:18 <efried> The first one is _almost_ ready to go.  I'm working on a few tweaks suggested by thorst.
14:05:50 <efried> Yes, I think we could start a vif change set and an SSP change set in parallel.
14:05:52 <nbante> Hi, I am Nilesh Bante..I am joining this meeting first time
14:05:59 <efried> Welcome nbante
14:06:09 <thorst> nbante will be helping with testing OSA for PowerVM  :-)
14:06:20 <efried> The vif and SSP change sets could be a good thing for wangqwsh and xia to get started on.
14:06:24 <wangqwsh> wlc
14:06:36 <thorst> efried: the vif one needs a little bit of research
14:06:41 <efried> wangqwsh and xia, do you have systems to test on?
14:06:49 <thorst> because we need to understand where 'os-vif' is in core nova.
14:06:53 <wangqwsh> i have neo4
14:06:59 <efried> thorst: start with OVS?
14:07:19 <thorst> well, yeah, but more importantly, do we do OVS as we have out of tree
14:07:27 <thorst> or has ocata changed the 'vif' model a bit
14:07:43 <thorst> I guess initially, lets move in what we have, and I'll do some os-vif research
14:08:35 <efried> #action thorst to research the status of os-vif in core nova
14:08:58 <efried> wangqwsh, xia - y'all good with starting on OVS and SSP change sets?
14:09:11 <wangqwsh> sure
14:09:37 <thorst> to clarify, two separate change sets.  To copy/paste in the code for the vif/ssp logic from the out of tree into the in-tree driver.  But only port over the stuff we need specific to those
14:09:56 <thorst> we're trying to create very small change sets for the nova team to review
14:10:05 <thorst> but at the same time keep it in sync with our out-of-tree driver
14:10:11 <efried> #action wangqwsh and xia to seed next two change sets: 1) PlugVifs and supporting code for OVS only; 2) SSP disk driver and supporting code.
14:10:20 <wangqwsh> got,
14:10:23 <efried> Let me know if you need help/guidance there.
14:10:38 <wangqwsh> ok
14:10:52 <thorst> efried: I'm assuming we hold off on the in-tree CI discussion till later part of meeting?
14:10:55 <efried> I wrote the SSP driver, so I'm pretty familiar with it; thorst did the OVS work, so he's the SME.
14:11:06 <efried> thorst: sure, fine with me.
14:11:27 <efried> One more note on status:
14:11:45 <wangqwsh> i will try to read the code first. any issue i will let you know.
14:12:08 <efried> As we get code reviews on the ported code, some changes/fixes/improvements need to be flushed back to nova-powervm.  That's what I've been working on while fixing up the first in-tree change set.
14:12:46 <efried> One of the things we're trying to avoid in the in-tree driver is unit tests that dig too deeply into pypowervm.
14:12:59 <thorst> +1
14:13:17 <efried> Among other things, this means that wherever we're using pypowervm's test data files, we need to convert over to using plain ol' mocks instead.
14:13:24 <BorD__> seroyer thanks a ton!  things got wonky after upgrading rpm to the version that works with yum..
14:14:08 <efried> Also be on the lookout for places where we're validating pypowervm lib functions - those should be replaced with mock.patches of the pypowervtm lib methods instead.
14:14:57 <efried> Sometimes we can let the pypowervm methods run, but only if we don't have to do a bunch of extra mocking and coercion in the UT to make them "work".
14:15:08 <efried> Any questions for now?
14:15:28 <wangqwsh> no
14:15:29 <thorst> agree with that.  No Questions
14:15:47 <efried> esberglu: next topic?
14:16:26 <esberglu> What else do you guys want to talk about?
14:16:43 <efried> If you don't have anything else queued up, we can get into the dual-CI business.
14:17:01 <esberglu> Okay
14:17:16 <efried> #topic CI for in-tree driver
14:17:41 <efried> So the challenge here is that the in-tree driver has a tiny subset of the functionality we're testing in our existing CI.
14:17:49 <efried> We can't stop testing the out-of-tree driver
14:18:07 <esberglu> So we want a second set of tests whitelisted for the in tree
14:18:15 <efried> but we need to be able to show a passing CI for the in-tree driver before we can expect to merge it  (per nova core direction, and common sense)
14:19:07 <efried> Yes, we'll need a separate environment to test in-tree.  It'll involve both a whitelist for the tests around the functionality we have, and a separate conf setup to load up and configure the in-tree driver properly.
14:19:29 <efried> That env will have to proceed in lock-step with the change sets as they merge.
14:19:45 <thorst> I want to be clear
14:19:50 <thorst> It won't be a separate environment
14:19:54 <efried> So right now, it needs to be set up to target just the first (spawn/delete) change set (https://review.openstack.org/391288)
14:19:56 <thorst> it'll be a different VM in the existing CI environment
14:20:08 <thorst> which runs a different setup/test job
14:20:27 <thorst> so if nova has a patch, we kick off two jobs.  One out of tree, one in tree.
14:20:27 <efried> Once that change set merges, we'll need to modify the conf & whitelist to support the second.  And so on.
14:21:04 <thorst> efried: that whitelist needs to be flexible
14:21:13 <efried> thorst: what do you mean?
14:21:15 <thorst> because you'll be working on change set 3, then need to make a rev on change set 1.
14:21:27 <esberglu> Are you saying we want 2 types of ready nodes? Or just one type of ready node with diff. config and setup after
14:21:37 <thorst> esberglu: one ready node...two different jobs
14:21:44 <esberglu> Okay good
14:21:46 <thorst> one "type" of ready node
14:22:06 <efried> Sure, the whitelist will need to keep up with change set 1 - but I don't see us trying to maintain whitelists for multiple in-flight change sets at once.
14:22:22 <thorst> efried: fair enough...we'll see how that goes
14:23:05 <efried> I mean, we _could_ try to do that - but the CI infra would have to keep a mapping of change sets to conf/whitelists.  That would be complicated, and probably not worth the trouble.
14:23:46 <thorst> lets start with easy
14:23:52 <thorst> move up from there
14:24:12 <efried> At any given point, the setup should still pass for all in-flight change sets.  But we can't add new tests until a change set merges.
14:24:13 <thorst> esberglu: priority wise, this second CI is probably right after getting our main CI up and running again
14:24:23 <efried> +1
14:25:01 <efried> That and core reviews are the last inhibitor to getting the first change set merged (once I've put up the last patch set with thorst's suggested changes).
14:25:38 <esberglu> Main CI pretty much is up and running, just was failing on those 2 tests added to the skip list
14:25:40 <efried> Now, is it going to be easier to fix the CI as-is, and then do the split, or do both at once?
14:25:46 <esberglu> So I can start looking into the 2nd CI today
14:25:50 <efried> okay, I guess you answered that.
14:26:05 <efried> #action esberglu to start work on the split-CI
14:26:34 <efried> Anything else on CI for now?
14:26:48 <thorst> I'd like a status update with the main CI
14:27:00 <efried> #topic Main CI status
14:27:54 <esberglu> It seems to be working pretty well. I upgraded to zuul 2.5.1 yesterday, 2.5.0 was missing a change and was causing issues
14:28:16 <efried> are we passing?
14:28:19 <esberglu> There were 2 tests that were failing and got added to the skip list. Pretty much every failure I saw yesterday was just those 2
14:28:31 <esberglu> A run hasn't finished since the skip list change merged
14:28:43 <efried> Are the two tests appropriate to skip, or do they need to be investigated for possible code fixes?
14:28:58 <esberglu> Not supported
14:29:01 <thorst> appropriate to skip
14:29:02 <thorst> DVR
14:29:05 <efried> beaut
14:29:23 <thorst> are we working in parallel getting the staging environment up and running?
14:29:27 <efried> Do we have some way of knowing when new tests are added so we can maybe be proactive about skipping unsupported stuff?
14:30:27 <esberglu> thorst: I was going to deploy staging this morning. I really want to get us back on the latest devstack master, the longer we wait on that the more difficult its going to be
14:30:48 <esberglu> So I was going to hit staging with that while I start working on the code for the 2nd CI
14:31:13 <thorst> esberglu: before you chase that, could you try out that DNS server that adreznec set up?
14:31:21 <thorst> I'd love to just knock that out.
14:31:46 <esberglu> adreznec: Is that change set ready? I still need to look through it
14:32:49 <adreznec> esberglu: Yeah, like I said the client-side changes to actually set clients to use the DNS mirror/apt cache aren't tested
14:32:49 <thorst> adreznec in/
14:33:02 <adreznec> But it's ready for review/testing anyway
14:33:08 <thorst> so ready for staging
14:33:11 <adreznec> Right
14:33:25 <adreznec> There might be some wonkiness in the variables we need to handle
14:33:26 <esberglu> Okay. I will deploy with that as well then
14:33:39 <adreznec> If we're going to share one between staging and prod
14:33:47 <thorst> esberglu: we're thinking that can dramatically speed up CI runs
14:33:51 <thorst> maybe another 10-20 min
14:33:52 <esberglu> #action esberglu: Test dns / apt on staging environment
14:33:59 <esberglu> That would be sweet
14:34:02 <adreznec> Though I suppose we could have it such that in staging it just installs those things onto the management nodes
14:34:06 <thorst> yeah, and make it more stable...
14:34:12 <adreznec> Since the management node isn't getting a lot of volume there
14:36:48 <esberglu> Let's see what happens when I deploy and go from there?
14:37:30 <esberglu> Anything else for CI?
14:37:44 <thorst> not from my end.
14:37:50 <adreznec> Sure. Was just a heads up that it might not work right out of the box
14:38:06 <esberglu> Other topics?
14:38:20 <esberglu> Btw, the first run with the new skip list just went through and passed
14:38:43 <efried> sweet
14:38:46 <efried> Do we have some way of knowing when new tests are added so we can maybe be proactive about skipping unsupported stuff?
14:39:11 <esberglu> I can look into it
14:39:24 <thorst> woo
14:39:26 <efried> Cool.  Low priority, below other stuff above.
14:39:38 <esberglu> #action: esberglu: Find a way to get notified of new tempest tests
14:41:33 <esberglu> efried: thorst: I think you guys wanted further discussion on the in-tree driver?
14:41:49 <thorst> nope
14:41:53 <efried> I think that was the split-CI discussion
14:41:57 <esberglu> Oh okay
14:42:16 <esberglu> Anything final topics before I end the meeting?
14:42:22 <thorst> just one future facing thing
14:42:34 <thorst> we're going to need to start looking at supporting that fileio disk/volume connector
14:42:48 <thorst> I'm trying to figure out who/how we do that...but I don't think it'll be too tough TBH
14:42:56 <thorst> probably start with cinder.
14:43:03 <thorst> target will be pike
14:44:38 <efried> need a bp?
14:45:35 <thorst> prob
14:45:51 <thorst> out of tree bp though
14:48:56 <esberglu> Alright looks like that covers it. Thanks for joining
14:48:57 <thorst> that's all I had
14:49:00 <thorst> thanks!
14:49:03 <esberglu> #endmeeting