13:02:57 <esberglu> #startmeeting powervm_driver_meeting 13:02:58 <openstack> Meeting started Tue Jun 6 13:02:57 2017 UTC and is due to finish in 60 minutes. The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:03 <openstack> The meeting name has been set to 'powervm_driver_meeting' 13:03:06 <thorst> o/ 13:03:38 <esberglu> #topic In Tree Driver 13:03:42 <esberglu> #link https://etherpad.openstack.org/p/powervm-in-tree-todos 13:04:03 <efried> o/ 13:04:20 <edmondsw> o/ 13:04:33 <efried> "Fixing" the get_info business led alll the way down the rabbit hole. 13:04:47 <efried> https://review.openstack.org/471146 13:05:12 <efried> In the end, mriedem said we should just remove all the unused fields from InstanceInfo, everywhere. 13:06:09 <efried> This will impact the OOT driver if/when it merges. 13:06:48 <edmondsw> k 13:07:35 <edmondsw> that's for instances... were we also talking about host stats the other day? Are there unused fields to remove there as well? 13:07:50 <thorst> efried: you should probably run that by mdrabe. 13:07:53 <efried> We weren't talking about host stats. 13:07:59 <edmondsw> k 13:08:07 <thorst> I suspect pvc would be impacted (and I bet other OS products) 13:08:31 <efried> thorst Yeah, I was thinking it will probably be a good idea to blast the dev ML on this one. 13:08:53 <thorst> yep. But just ping mdrabe on the side too. I'm not sure how much they view the ML 13:08:58 <thorst> I know I can't (don't) keep up 13:09:05 <edmondsw> +1 13:09:19 <efried> esberglu Depending how mriedem's comment plays out, this might impact your support matrix change. 13:09:30 <efried> https://review.openstack.org/#/c/471146/2/doc/source/support-matrix.ini@249 13:09:38 <efried> Not sure if he's gonna ask to remove that whole section. 13:09:43 <esberglu> efried: ack 13:10:15 <efried> I think that's it for me in tree. 13:10:26 <edmondsw> I wanted to ask an IT question 13:10:56 <efried> floor is yours 13:10:58 <edmondsw> so when we were looking at the support matrix it clicked for me that our SSP support that merged IT is only ephemeral 13:11:30 <edmondsw> when we've talked about 2H17 priorities we've talked about network, config_drive, and vSCSI 13:11:51 <edmondsw> is vSCSI there ephemeral or data or both? 13:12:02 <edmondsw> and is vSCSI the top priority for data disk attach/detach, not SSP? 13:12:05 <efried> I don't remember a vSCSI discussion. iSCSI maybe? 13:12:31 <thorst> cinder 13:12:31 <edmondsw> thorst had said vSCSI 13:12:37 <mdrabe> Do we want vSCSI IT? 13:12:39 <thorst> thorst said cinder (via vSCSI) 13:12:45 <mdrabe> (o/ btw) 13:12:56 <thorst> vSCSI is simply a way to connect storage to a VM 13:12:59 <edmondsw> mdrabe read up, there was something for you above 13:13:00 <efried> Gotcha. So the VSCSIVolumeAdapter. 13:13:07 <thorst> when we talk about it in terms of Cinder, we typically mean FC volumes to a VM 13:13:10 <mdrabe> ack 13:13:15 <thorst> in fact in PVC, we simplified vSCSI to just mean that 13:13:24 <thorst> but vSCSI is used for SSP, iSCSI, FC PV, etc... 13:13:45 <thorst> so I probably used the wrong language there 13:13:53 <thorst> I meant cinder support via vSCSI 13:14:05 <efried> Really, for FC? I thought we had a fibre channel mapping that was different from a VSCSI mapping. 13:14:16 <thorst> FC also has this fancy NPIV support 13:14:16 <efried> Anyway, separate discussion. 13:14:38 <thorst> which is like a SR-IOV like thing for FC...though, yeah, separate discussion 13:14:47 <efried> Point is, we're looking to support the VSCSIVolumeAdapter in tree. 13:14:53 <thorst> +1 13:15:07 <edmondsw> thorst, in terms of the support matrix, what should we be trying to flip to partial/complete among the storage.block items? 13:15:08 <edmondsw> https://github.com/openstack/nova/blob/master/doc/source/support-matrix.ini#L945 13:15:15 <edmondsw> https://github.com/openstack/nova/blob/master/doc/source/support-matrix.ini#L972 13:15:23 <edmondsw> https://github.com/openstack/nova/blob/master/doc/source/support-matrix.ini#L993 13:15:25 <edmondsw> etc. 13:16:18 <thorst> 945 - partial, 972 - complete (though we can add NPIV later), 993 - missing (for now? If we can tuck in awesome) 13:16:21 <edmondsw> I think you're saying L972 via cinder vSCSI 13:16:30 <edmondsw> k 13:16:38 <thorst> reality is that today, everyone is FC. So that's the hole we should fill first for IT. 13:16:55 <edmondsw> what about cinder via SSP? 13:17:04 <thorst> no cinder driver for SSP 13:17:11 <edmondsw> oh, really 13:17:13 <mdrabe> everyone is FC? you mean Power folks? 13:17:14 <thorst> we talked about making one...but it never came to fruition 13:17:20 <efried> https://review.openstack.org/#/c/372254/ 13:17:21 <thorst> PowerVM - everyone is FC 13:17:23 <efried> Still open ;-) 13:17:25 <thorst> rest of world...not so much 13:17:35 <efried> Last action in January 13:17:40 <thorst> efried: yeah... 13:17:52 <thorst> we were hoping that would then allow us to make a cinder driver 13:17:57 <thorst> I think people got pulled in other directions 13:18:08 <thorst> like iSCSI...and my other crazy volume connectors 13:18:21 <edmondsw> thorst so when PowerVC uses SSP for data volumes... how is it doing that without a cinder driver? 13:18:40 <thorst> edmondsw: they have a cinder driver, but it isn't upstreamed yet 13:18:46 <edmondsw> ah 13:19:34 <esberglu> Anything else IT? 13:19:37 <mdrabe> I've a question 13:19:42 <efried> Real quick, back to the get_info discussion, this also came out of it: https://review.openstack.org/#/c/471106/ 13:19:46 <efried> trivial 13:19:49 <mdrabe> Where does os-brick come in to play with volume connectors? 13:20:23 <thorst> mdrabe: good q...shyama was looking into that. Its a way to replace (I think?) the connection_info object (bdm) 13:20:28 <thorst> not super sure 13:20:32 <edmondsw> I've been working on deactivating the compute service when we can't get a pvm session or there are no VIOS ready, but not ready to put up for review quite yet 13:21:11 <mdrabe> Ok yea can discuss later 13:22:21 <esberglu> Alright moving on 13:22:29 <esberglu> #topic Out Of Tree Driver 13:22:59 <efried> Perf improvement change (https://review.openstack.org/469982) - I owe another patch set. 13:23:17 <efried> But the testing came back good on that, so once those fixups are in, I think we're good to go there. 13:23:35 <efried> Then I plan to look into the "don't need a whole instance for the NVRAM manager" thing. 13:23:48 <efried> which could also yield perf improvements... maybe. 13:24:08 <efried> Gotta do that quick before arnoldja moves on to bluer pastures. 13:24:15 <thorst> efried: I don't disagree with what you did 13:24:20 <thorst> I just feel dirty about it 13:24:24 <efried> heh 13:24:28 <thorst> 'lets just wait 15 seconds for everything' 13:24:34 <thorst> 'because this API vomits up events' 13:24:36 <efried> Well, anything PartitionState 13:24:58 <thorst> so I don't disagree...I just think its bleh 13:25:04 <efried> It's always that way with perf improvements. 13:25:11 <thorst> yep yep yep 13:25:13 <efried> Most of the time they make the code uglier. 13:25:20 <thorst> just letting my voice be heard. :-p 13:25:36 <esberglu> This week is the pike 2 milestone (thursday), so I will be tagging the repos accordingly. 13:26:09 <mdrabe> efried is there a LP bug for that? 13:26:23 <efried> for the perf thing? 13:26:33 <mdrabe> yea... I guess it's not technically a bug 13:26:36 <efried> https://launchpad.net/bugs/1694784 13:26:37 <openstack> Launchpad bug 1694784 in nova-powervm "Reduce overhead for redundant PartitionState events" [Undecided,New] 13:27:04 <mdrabe> Ah neat thx 13:29:02 <efried> This might have been said last week, but the get_inventory thing is on hold pending further baking of the infrastructure. 13:29:12 <thorst> yep 13:29:12 <efried> https://review.openstack.org/468560 13:29:28 <efried> They've hit a snag with the design of shared resource providers. 13:29:53 <efried> It's going around the ML at the moment. Not sure how that's gonna shake out. An elegant solution is not yet forthcoming. 13:30:17 <efried> Subject line, in case you want to follow along at home: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources 13:30:25 <efried> I guess that's an IT/OOT thing. 13:31:08 <efried> Oh, I wanted to bring up t9n 13:31:50 <efried> I saw an email a couple days ago that may affect our stance on how aggressive we become about removing translations from various places. 13:32:26 <thorst> t9n? 13:32:30 <thorst> what does that stand for? 13:32:39 <efried> translation 13:32:51 <edmondsw> what was the email? 13:32:54 <efried> Right now the policy we're following in nova-powervm is just not translating any new log messages, and removing from anything we happen to touch while doing mods. 13:33:05 <thorst> so the 9 stands for len('ranslatio') 13:33:11 <efried> networking-powervm is subject to a hacking rule that disallows *any* translation. 13:33:21 <efried> (thorst, yeah, like i18n, etc.) 13:33:26 <efried> and k8s ;-) 13:33:37 <thorst> (got it - finally understand i18n too) 13:33:55 <efried> ...and I'm not sure whether we've even talked about a policy for pypowervm. 13:33:58 * thorst feels dumb 13:34:31 <thorst> efried: well, pypowervm is consumed by more ways than OpenStack...we've got two or three other direct users. 13:34:38 <thorst> I think any change there would need to be run by them 13:35:04 <thorst> we'd probably want to ask clbush from a CLI perspective too. 13:35:20 <edmondsw> I assumed efried was going to talk about nova-powervm, not pypowervm 13:35:39 <edmondsw> oh, missed a linee 13:35:56 * edmondsw feels dumb, joining thorst 13:36:15 <efried> So okay, agree that discussion outside this group is needed for pypowervm. 13:36:20 <efried> What about nova-powervm? 13:36:36 <thorst> I dunno, I'm dragging my feet on that 13:36:48 <thorst> and I'll admit, its really because I know pvc likes those messages translated. 13:36:48 <efried> It's probably not worth going all out and removing everything. 13:37:04 <edmondsw> thorst that's not true... PowerVC doesn't want log message translated 13:37:13 <efried> thorst That's the email I was referring to, yeah. 13:37:18 <thorst> o, huh 13:37:31 <thorst> well, then yeah. I'm fine with either being proactive or lazy about it then 13:37:33 <edmondsw> thorst PowerVC wants consistency, it just doesn't want to spend the resources to scrub the translations it already has in place 13:37:43 <thorst> got it. 13:37:47 <edmondsw> but a note was sent just a couple days ago abount starting to scrub things if/when you can 13:37:53 <thorst> neat 13:38:07 <thorst> well, then ... same goes for ceiometer-powervm too 13:38:24 <thorst> that one is probably easier to do (and probably could benefit from a patch set done against it) 13:38:42 <edmondsw> I'd probably prioritize ceilometer-powervm above nova-powervm 13:38:43 <efried> Okay, upshot for nova-powervm and ceilometer-powervm is: no need to hold back if you feel like scrubbing out all the log t9n from those guys. 13:38:51 <efried> But it's not a high priority. 13:39:00 <thorst> yep 13:39:10 <edmondsw> +1 13:39:38 <efried> I added it to the etherpad https://etherpad.openstack.org/p/powervm-in-tree-todos line 69 13:40:01 <edmondsw> that it for OOT? 13:40:46 <efried> nothing else from me. 13:41:11 <esberglu> #topic PowerVM CI 13:41:21 <esberglu> https://etherpad.openstack.org/p/powervm_ci_todos 13:41:42 <efried> esberglu Okay, so you moved the CI to-dos out to another etherpad. 13:42:01 <esberglu> efried: Yeah I linked it in the other one 13:42:15 <esberglu> I can move it back if that's what people prefer 13:42:33 <esberglu> But I wanted to track tempest failures there and it was becoming a lot of info 13:42:58 <efried> esberglu I'm fine with it as long as everything's cross-linked. I added a backpointer from the CI one to the original. 13:43:10 <esberglu> efried: Good call. 13:43:20 <efried> What's the difference between WORKING and CURRENT? 13:43:38 <esberglu> Stuff that I'm actually doing (in staging) vs stuff that's just on the list 13:44:12 <esberglu> We still need to figure out a way to get the VNC tests working 13:44:28 <esberglu> And check what tests (if any) can be enabled with SSP merged 13:44:38 <edmondsw> esberglu change "CURRENT" to "NEXT"? 13:44:44 <edmondsw> efried that clearer? 13:45:35 <efried> Yeah, that would be fine. Not a big thang. 13:46:11 <esberglu> CI has been looking really good since the last couple fixes last week 13:46:29 <esberglu> Which should open up some time to start knocking this list out 13:46:50 <esberglu> I'm gonna go through and prioritize the list today 13:47:28 <esberglu> Been seeing way less of the timeout errors since I upped the time limit. Which to me points to slow over hanging. 13:47:43 <edmondsw> esberglu can you make looking at the tempest failures part of that prioritized list? 13:47:50 <esberglu> edmondsw: Yeah 13:48:11 <edmondsw> esberglu so you did merge that timeout bump? 13:48:53 <esberglu> edmondsw: I thought we were just putting it in temporarily for investigation purposes. But I can 13:49:00 <efried> Hope not. We need to have a lively discussion first. 13:49:15 <edmondsw> no, I just asked because you're seeing "way less" 13:49:27 <esberglu> edmondsw: I just live patched the jenkins jobs 13:49:34 <edmondsw> if it didn't merge, wouldn't it only be in effect on a one-by-one basis? 13:49:35 <edmondsw> oh 13:50:55 <efried> Basically, my stance on this is that our CI isn't just testing "does it work.... eventually?" It's also there to alert us to what I'll call "performance problems" for lack of a better term. 13:51:23 <efried> So if stuff is taking a long time, we need to figure out why it's taking a long time, not just increase the timeout. 13:51:56 <edmondsw> efried yep, I think we all agree there 13:51:57 <efried> I would even go so far as to say, if we had the space for it, we should be *decreasing* timeouts to highlight things that are taking longer than they ought. 13:52:22 <edmondsw> I'll even agree with that... once we get these current timeouts figured out / addressed 13:52:28 <efried> yup. 13:53:29 <esberglu> Should I remove the timeout increase now? It will be easier to find failing runs to investigate that way 13:53:48 <efried> esberglu When you've got the space to really start digging into them, yes. 13:54:04 <efried> Not necessary if it's just going to result in more failures but no action. 13:54:21 <edmondsw> +1 or when one of us pings you that we have that time 13:54:35 <esberglu> efried: Ok. I want to do a couple other things first (like get the neo logged) which should help for debugging 13:54:44 <efried> fo sho. 13:55:15 <edmondsw> esberglu I'm not seeing getting the neo logged on your list 13:55:18 <efried> let me know if you need help figuring out how to do that; I have a couple of ideas. 13:55:24 <esberglu> edmondsw: Yeah that list is a WIP 13:55:41 <esberglu> That's all I had for CI 13:55:56 <esberglu> #topic Driver Testing 13:56:02 <esberglu> Any progress here? 13:56:30 <efried> We don't have testers on. But thorst_afk added https://etherpad.openstack.org/p/powervm-in-tree-todos starting line 92 13:56:46 <efried> ...pursuant to our call the other day. 13:56:49 <thorst_afk> efried: we're lining up the test resources still. I don't think any tangible change, just formulating plan 13:57:50 <esberglu> Any discussion needed here? Otherwise I'll move on, running close to time 13:58:10 <thorst_afk> don't think so 13:58:14 <esberglu> #topic Open Discussion 13:58:21 <esberglu> Any final thoughts before I call it? 13:58:43 <efried> It's really confusing in my HexChat interface that esberglu and edmondsw both start with 'e' and have the same number of letters. 13:58:56 <efried> My old IRC client had different colors for each user. Haven't figured out how to do that in HexChat. 13:59:03 <thorst_afk> efried: bringing the real problems to light 13:59:08 <edmondsw> :) 13:59:09 <efried> You can count on me. 13:59:26 <thorst_afk> I'd make a quip...but yeah, we do count on you 13:59:59 <mdrabe> I got a q actually 14:00:09 <thorst_afk> alright, I need to bail. Need to go spread the gospel of open vswitch 14:00:20 <mdrabe> For test, what's the desired deployment route, devstack or OSA? 14:00:34 <thorst_afk> mdrabe: for now, devstack due to simplicity of setup 14:00:45 <thorst_afk> which is not all that simple, until you compare to OSA. 14:01:02 <efried> Hah, ironic considering OSA is supposed to be the thing that makes it simple. 14:01:17 <thorst_afk> efried: OSA is the thing to make OpenStack production grade 14:01:17 <mdrabe> Would this be an opportunity to iron out the OSA path then? 14:01:22 <efried> Yeah 14:01:34 <efried> Sorry, thorst_afk Yeah. mdrabe No. 14:01:38 <thorst_afk> mdrabe: kinda. Lets chat more when I'm off the phone 14:02:10 <mdrabe> I'd say wainot, but sounds like it's complicated 14:05:10 <efried> esberglu Think we're done here. 14:05:31 <esberglu> #endmeeting