14:00:03 #startmeeting powervm_driver_meeting 14:00:03 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:07 The meeting name has been set to 'powervm_driver_meeting' 14:01:13 o/ 14:01:30 :) 14:01:34 adreznec thorst 14:02:10 o/ 14:02:29 #topic Status 14:02:51 Hi all, it's my first time to join this meeting, I'm Yan Xia,wangqw's team member 14:03:04 hey xia! 14:03:07 Welcome. 14:03:18 Hi! 14:03:30 Thanks!Glad to meet you all! 14:03:56 Anyone have status? I'm still a bit out of the loop for where we are on this 14:04:10 I'll do a quick summary of the in-tree driver work. 14:04:18 We have four change sets out there. 14:04:53 https://review.openstack.org/391288 https://review.openstack.org/409401 https://review.openstack.org/409402 https://review.openstack.org/409404 14:04:59 ...in that order. 14:05:09 efried: we still need a vif one to be seeded? 14:05:18 The first one is _almost_ ready to go. I'm working on a few tweaks suggested by thorst. 14:05:50 Yes, I think we could start a vif change set and an SSP change set in parallel. 14:05:52 Hi, I am Nilesh Bante..I am joining this meeting first time 14:05:59 Welcome nbante 14:06:09 nbante will be helping with testing OSA for PowerVM :-) 14:06:20 The vif and SSP change sets could be a good thing for wangqwsh and xia to get started on. 14:06:24 wlc 14:06:36 efried: the vif one needs a little bit of research 14:06:41 wangqwsh and xia, do you have systems to test on? 14:06:49 because we need to understand where 'os-vif' is in core nova. 14:06:53 i have neo4 14:06:59 thorst: start with OVS? 14:07:19 well, yeah, but more importantly, do we do OVS as we have out of tree 14:07:27 or has ocata changed the 'vif' model a bit 14:07:43 I guess initially, lets move in what we have, and I'll do some os-vif research 14:08:35 #action thorst to research the status of os-vif in core nova 14:08:58 wangqwsh, xia - y'all good with starting on OVS and SSP change sets? 14:09:11 sure 14:09:37 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 we're trying to create very small change sets for the nova team to review 14:10:05 but at the same time keep it in sync with our out-of-tree driver 14:10:11 #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 got, 14:10:23 Let me know if you need help/guidance there. 14:10:38 ok 14:10:52 efried: I'm assuming we hold off on the in-tree CI discussion till later part of meeting? 14:10:55 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 thorst: sure, fine with me. 14:11:27 One more note on status: 14:11:45 i will try to read the code first. any issue i will let you know. 14:12:08 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 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 +1 14:13:17 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 seroyer thanks a ton! things got wonky after upgrading rpm to the version that works with yum.. 14:14:08 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 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 Any questions for now? 14:15:28 no 14:15:29 agree with that. No Questions 14:15:47 esberglu: next topic? 14:16:26 What else do you guys want to talk about? 14:16:43 If you don't have anything else queued up, we can get into the dual-CI business. 14:17:01 Okay 14:17:16 #topic CI for in-tree driver 14:17:41 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 We can't stop testing the out-of-tree driver 14:18:07 So we want a second set of tests whitelisted for the in tree 14:18:15 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 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 That env will have to proceed in lock-step with the change sets as they merge. 14:19:45 I want to be clear 14:19:50 It won't be a separate environment 14:19:54 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 it'll be a different VM in the existing CI environment 14:20:08 which runs a different setup/test job 14:20:27 so if nova has a patch, we kick off two jobs. One out of tree, one in tree. 14:20:27 Once that change set merges, we'll need to modify the conf & whitelist to support the second. And so on. 14:21:04 efried: that whitelist needs to be flexible 14:21:13 thorst: what do you mean? 14:21:15 because you'll be working on change set 3, then need to make a rev on change set 1. 14:21:27 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 esberglu: one ready node...two different jobs 14:21:44 Okay good 14:21:46 one "type" of ready node 14:22:06 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 efried: fair enough...we'll see how that goes 14:23:05 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 lets start with easy 14:23:52 move up from there 14:24:12 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 esberglu: priority wise, this second CI is probably right after getting our main CI up and running again 14:24:23 +1 14:25:01 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 Main CI pretty much is up and running, just was failing on those 2 tests added to the skip list 14:25:40 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 So I can start looking into the 2nd CI today 14:25:50 okay, I guess you answered that. 14:26:05 #action esberglu to start work on the split-CI 14:26:34 Anything else on CI for now? 14:26:48 I'd like a status update with the main CI 14:27:00 #topic Main CI status 14:27:54 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 are we passing? 14:28:19 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 A run hasn't finished since the skip list change merged 14:28:43 Are the two tests appropriate to skip, or do they need to be investigated for possible code fixes? 14:28:58 Not supported 14:29:01 appropriate to skip 14:29:02 DVR 14:29:05 beaut 14:29:23 are we working in parallel getting the staging environment up and running? 14:29:27 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 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 So I was going to hit staging with that while I start working on the code for the 2nd CI 14:31:13 esberglu: before you chase that, could you try out that DNS server that adreznec set up? 14:31:21 I'd love to just knock that out. 14:31:46 adreznec: Is that change set ready? I still need to look through it 14:32:49 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 adreznec in/ 14:33:02 But it's ready for review/testing anyway 14:33:08 so ready for staging 14:33:11 Right 14:33:25 There might be some wonkiness in the variables we need to handle 14:33:26 Okay. I will deploy with that as well then 14:33:39 If we're going to share one between staging and prod 14:33:47 esberglu: we're thinking that can dramatically speed up CI runs 14:33:51 maybe another 10-20 min 14:33:52 #action esberglu: Test dns / apt on staging environment 14:33:59 That would be sweet 14:34:02 Though I suppose we could have it such that in staging it just installs those things onto the management nodes 14:34:06 yeah, and make it more stable... 14:34:12 Since the management node isn't getting a lot of volume there 14:36:48 Let's see what happens when I deploy and go from there? 14:37:30 Anything else for CI? 14:37:44 not from my end. 14:37:50 Sure. Was just a heads up that it might not work right out of the box 14:38:06 Other topics? 14:38:20 Btw, the first run with the new skip list just went through and passed 14:38:43 sweet 14:38:46 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 I can look into it 14:39:24 woo 14:39:26 Cool. Low priority, below other stuff above. 14:39:38 #action: esberglu: Find a way to get notified of new tempest tests 14:41:33 efried: thorst: I think you guys wanted further discussion on the in-tree driver? 14:41:49 nope 14:41:53 I think that was the split-CI discussion 14:41:57 Oh okay 14:42:16 Anything final topics before I end the meeting? 14:42:22 just one future facing thing 14:42:34 we're going to need to start looking at supporting that fileio disk/volume connector 14:42:48 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 probably start with cinder. 14:43:03 target will be pike 14:44:38 need a bp? 14:45:35 prob 14:45:51 out of tree bp though 14:48:56 Alright looks like that covers it. Thanks for joining 14:48:57 that's all I had 14:49:00 thanks! 14:49:03 #endmeeting