Monday, 2016-08-08

*** jwcroppe has joined #openstack-powervm00:13
*** jwcroppe_ has quit IRC00:15
*** thorst has joined #openstack-powervm00:52
*** edmondsw has joined #openstack-powervm00:54
*** thorst_ has joined #openstack-powervm01:24
*** thorst has quit IRC01:27
*** thorst_ has quit IRC02:04
*** efried has quit IRC02:07
*** esberglu has joined #openstack-powervm03:12
*** esberglu has quit IRC03:19
*** kotra03 has joined #openstack-powervm03:54
*** seroyer has joined #openstack-powervm04:09
*** seroyer has quit IRC04:32
*** tjakobs has joined #openstack-powervm04:36
*** tjakobs has quit IRC04:44
*** tjakobs has joined #openstack-powervm05:18
*** tsjakobs has joined #openstack-powervm05:19
*** tjakobs has quit IRC05:19
*** tsjakobs has quit IRC06:03 proposed openstack/nova-powervm: [WIP] Plug updated VIFs
openstackgerritRavi Kumar Kota proposed openstack/nova-powervm: WIP: PowerVM: Implement get_instance_diagnostics
openstackgerritRavi Kumar Kota proposed openstack/nova-powervm: WIP: PowerVM: Implement get_instance_diagnostics
*** kairo has joined #openstack-powervm07:36
openstackgerritRavi Kumar Kota proposed openstack/nova-powervm: WIP: PowerVM: Implement get_instance_diagnostics
*** k0da has joined #openstack-powervm08:15
-openstackstatus- NOTICE: Gerrit is going to be restarted08:39 proposed openstack/nova-powervm: WIP: Pre-allocate trunk adapter on target host
*** smatzek has joined #openstack-powervm11:29
*** thorst has joined #openstack-powervm11:47
*** thorst has quit IRC11:47
*** thorst has joined #openstack-powervm11:48
*** madhaviy has joined #openstack-powervm12:12
*** seroyer has joined #openstack-powervm12:42
*** seroyer has quit IRC12:48
*** seroyer has joined #openstack-powervm12:50
*** kotra03 has quit IRC13:00
*** efried has joined #openstack-powervm13:03
*** mdrabe has joined #openstack-powervm13:09
thorstefried: Trying to catch up with reviews - that in limbo?13:17
efriedthorst, that one's going to be abandoned.  Chongshi should be finishing up the schema/REST changes I petitioned for, whereupon I'll put up a new change set for those attributes.13:18
efriedthorst, do we need to discuss 3633?13:19
thorstefried: yeah.  I don't like your current stance of 'adding a mapping is rare, so I may not handle that case ever'13:20
thorstadding to an existing mapping that is13:20
thorstfreaks me out.13:20
efriedRephrase: current change set doesn't account for it; but can be added later if the demand arises.13:21
thorstefried: I guess what surprised me is that you think that demand doesn't exist for it now?13:21
thorstall our common flows just expect that function to be there13:21
*** smatzek has quit IRC13:21
efriedOh, the use case is certainly there.13:21
thorstthe 'tasks' don't know if I'm adding a disk to existing or making new13:22
thorstthe tasks don't know if they're spawn or add disk13:22
thorstby design they don't have that context...they're just 'add a disk'13:22
efriedBut we now have two ways of mucking with VSCSI mappings.  The old way still works just fine.  The new way exists so we can avoid 412s.13:22
efriedYes - I intend to alter the spawn flow to use this new VSCSIBusBuilder.13:22
thorstright, but in order to invoke the new seems like we're going to have to alter all the tasks and add a lot more contextual stuff into the tasks13:22
thorstbut then retain the old flows13:22
thorstseems like a push up of complexity to the user of the API13:23
thorstbenefit, sure.  But at a cost.13:23
*** seroyer has quit IRC13:23
efried"user" being the community code?13:23
thorstin this instance13:23
thorstthe nova-powervm code13:23
efriedI don't disagree that it adds complexity.13:24
efriedThere are two ways to avoid that complexity.13:24
efried(besides not changing anything)13:24
thorstefried: yep...either up in nova-powervm.  Deal with added complexity.  Or mostly down in pypowervm.  I lean towards that.  Its harder...but we like to keep the weird crap down in pypowervm13:24
efriedOne way is to make the lowest-level ops in pypowervm use VSCSIBus.  That would be a) hackish (at the pypowervm level), and b) slower in the general case, because we would be doing N separate PUT/POST calls rather than a single one to the VIOS.13:25
efriedThe other way is to have VSCSIBus-equivalent function for everything, and completely replace stg_ftsk with a BusBuilderTask thingy.13:26
efriedUnfortunately, we don't have VFCBus, and I'm not sure that's likely to happen.13:26
thorstefried: wouldn't said BusBuilderTask thingy also need to read existing context?13:26
efriedIn the general case, yes.13:27
thorstI'm not too worried about the performance to be honest.  We have decent performance on the gets...and we make sure we only do one get realistically13:27
thorstits the puts, and the 412's13:27
*** lmtaylor1 has joined #openstack-powervm13:27
thorstit seems like we can get the context once, and then just do the specific puts...and get a lot of the benefit without tremendous complexity/change13:27
efriedOnly if we maintain the context through the spawn flow.  Which is the added complexity you're shying away from.13:28
thorsthmmm...I don't fully follow.13:28
efriedSame thing we have to do today passing stg_ftsk around.13:28
thorstefried: o yeah...that still has to be passed around.  Sure13:29
efriedWe have to maintain stg_ftsk because we don't have VFCBus.  So we still need the VIOS feed for the VFC mappings.13:29
thorstefried: well, we have to maintain stg_ftsk for multiple reasons13:29
*** erlarese has joined #openstack-powervm13:30
thorstex. older nova-powervm code13:30
thorstbut yeah, strategically for vfc as well13:30
efriedRegardless, we need to keep it.13:30
efriedTo take advantage of VSCSIBus, we would need a similar object to pass around to accumulate the VSCSI mappings.13:30
thorstI was also just thinking that we could use stg_tsk with the VSCSIBus13:30
thorstbut I need to look more into this13:30
thorstthis is no trivial I want to make sure I fully investigate13:31
thorstwhich is why that review is lagging13:31
efriedI was thinking along those lines, but I suspect it would end up being pretty hackish and ugly.13:31
thorstpossibly.  But that's why I need to dig into that13:31
thorstso I can convince myself its a bad idea...cause I'll just disagree with you otherwise13:31
efriedI had intended to make a Task/VSCSIBus mixin subclass to add to the main flow.13:32
efriedConceivably, I could add that as a post-execute to the stg_ftsk, and then the low-level VSCSI connection tasks could add their mappings to that guy.13:32
efriedI.e. peel it out of the stg_ftsk.13:33
efriedIf found, use VSCSIBus logic.  Else use legacy VIOS/VSCSIMapping logic.13:33
thorstyeah...I'll dig in a bit.13:33
thorstwe definitely need 'fusing'.  That's a hard req for the OSes13:34
thorstwhich..I don't think KVM does the fusing like we do.  I think they do a new scsi bus for each 'thing'13:35
thorstbut I don't think IBMi or AIX (or honestly Linux) 'like' that.  I know that they don' very strong guidance that way13:35
*** esberglu has joined #openstack-powervm13:36
thorstadreznec: wonder how bad delta will be tomorrow given their issues today...13:38
efriedthorst, please see response on 3691, make sure it makes sense.13:38
thorstefried: yeah, that's a less controversial one at least13:39
efriedMessy, though.13:39
efriedI loathe these dual- (or triple-) field values.13:39
thorstefried: it feels like a just because we can.13:39
thorstI don't actually see  a strong use case for it13:40
thorstbut also don't see a big reason to avoid it13:40
efriedIt was explained to me at length by kriskend.13:40
thorstother than 'ugly'13:40
thorstwell, I get the use case kriskend is describing.  I just don't know of anything that needs to do that.13:40
efriedBasically 'mac' is the value that we "burn into" the VF when we "create" it - think of it as if we're building a new piece of hardware.  But apparently the operating system of the VM is allowed to assign a MAC address to such "hardware".  In that case, the "burned-in" value doesn't change - and that's the value that gets assigned on boot if not overridden on boot - but the active value may be different.13:41
efriedYou're questioning whether anyone ever actually overrides the MAC?13:42
thorstefried: well, yeah.  I know that rare cases they do.  But, the very specific use case she described where they override the mac AND we need to correlate it...13:42
thorstseems ... quite rare13:42
efriedWouldn't surprise me.  Thinking of a VM that's anticipating getting moved around, but needs to preserve the MAC so it doesn't freak out its workload's perception of the network?13:42
efriedDon't some major database impls rely on MACs?13:43
*** arunman has joined #openstack-powervm13:43
thorstefried: but vNIC keeps that consistency?13:43
efriedWouldn't think so.13:43
efriedOh, you mean keeping the same MAC on LPM?13:43
thorsthuh...I was under impression that was one of the reasons we used vNIC13:43
efriedHm, I guess that would make sense, but I don't know for sure.13:43
efriedCertainly the MAC is the same for any of the VFs in the vNIC, so if failover happens, the mac doesn't change.13:44
thorstvNIC - keep mac and enable redundancy for VFs (so we keep performance high)13:44
efriedAnd the preserve-on-LPM use case makes sense, just don't know if that's the way it is.  I'll ask...13:44
*** thorst_ has joined #openstack-powervm13:44
*** smatzek has joined #openstack-powervm13:45
openstackgerritSridhar Venkat proposed openstack/nova-powervm: Blueprint for nova-powervm SR-IOV VIFs
*** kriskend has joined #openstack-powervm13:47
*** kriskend_ has joined #openstack-powervm13:47
*** thorst has quit IRC13:48
*** dwayne has joined #openstack-powervm13:55
*** kairo has quit IRC13:56
*** seroyer has joined #openstack-powervm13:56
*** erlarese has quit IRC14:06
*** erlarese has joined #openstack-powervm14:11
*** tsjakobs has joined #openstack-powervm14:15
*** kotra03 has joined #openstack-powervm14:20
*** erlarese has quit IRC14:21
arunmanthorst_: Could you take a look at the latest changes for ? I've fixed your comments and updated the patch set14:31
thorst_arunman: yep14:34
thorst_arunman: will that be going back to mitaka?14:35
arunmanthorst_: Yeah14:35
thorst_arunman: are you planning to finish that TODO?14:35
arunmanI plan to have a bug written. But, I don't think I can hold this off till I merge that and come back here14:36
thorst_so can you add reference to bug you opened?14:38
thorst_have a -1 on it, but looks pretty good14:39
arunmansure, let me do that right away... and update another patch set with the bug id14:39
thorst_arunman: OK - had an issue with test too14:40
*** thorst has joined #openstack-powervm14:45
*** mdrabe has quit IRC14:46
*** thorst_ has quit IRC14:47
*** burgerk has joined #openstack-powervm14:50
*** efried has quit IRC14:53
*** mdrabe has joined #openstack-powervm14:54
*** efried has joined #openstack-powervm14:55
*** dwayne has quit IRC14:58
*** efried has quit IRC15:14
*** efried has joined #openstack-powervm15:16
*** kylek3h has joined #openstack-powervm15:21
*** dwayne has joined #openstack-powervm15:26
*** k0da has quit IRC15:26
thorstesberglu: how's CI looking?15:30
thorstthat last run is scary15:31
*** jwcroppe_ has joined #openstack-powervm15:32
adreznecEek yeah15:32
adreznec4h 37m is back where we started15:32
thorstwas that an outlier of the change set though...or the CI itself?15:33
thorstadreznec: ^^15:33
*** jwcroppe has quit IRC15:34
adreznecGood question15:34
thorstI don't think it was the patch set....15:35
adreznecWas just looking15:35
adreznecSounds like a CI issue15:36
esbergluthorst: Yeah it looks like we opened up a little early. The conrol node ran out of disk over the weekend so today is the first time it’s really getting full capacity. 40 - 45 runs concurrent but the times don’t look good15:37
esbergluStill spending a bunch of time in plug_vifs and crt_disk_from_img15:37
adreznecRan out of disk?15:37
adreznecFrom what? logs?15:38
esbergluYeah. It had like 100G of logs almost. I’m going to add something to the playbooks to clean them periodically15:39
adreznecI thought we already added something to do that15:40
adreznecA nightly cron job15:40
thorstlol...looks like we need more15:41
thorstand maybe lower log levels15:41
thorstesberglu: once we get that sorted...maybe see if clbush wants to take a look15:41
thorstotherwise, I think we're ready to go to clusters of 4 hosts for the SSPs15:41
adreznec3010 in neo-os-ci was supposed to handle log compression/rotation15:42
adreznecUnless you're saying this was on the nodepool/jenkins server15:42
adreznecand not the openstack controller15:42
esbergluNope it was on the controller15:43
esbergluI wonder if it is running that properly15:43
*** thorst is now known as thorst_afk15:44
adreznecYeah, must not be15:44
*** edmondsw has quit IRC15:50
*** apearson has joined #openstack-powervm16:07
efriedthorst_afk: would like to consider creating a PVMMechanismDriverBase into which we can put basic functionality like _get_vif_details and context.set_binding within try_to_bind_segment_for_agent.  Thoughts?16:16
*** apearson has quit IRC16:21
*** apearson has joined #openstack-powervm16:21
*** catintheroof has joined #openstack-powervm16:28
*** thorst_a_ has joined #openstack-powervm16:40
*** thorst_afk has quit IRC16:41
*** apearson has quit IRC16:56
*** madhaviy has quit IRC17:14
*** dwayne has quit IRC17:14
thorst_a_efried: seems reasonable17:27
*** thorst_a_ is now known as thorst17:27
*** edmondsw has joined #openstack-powervm17:28
*** thorst_ has joined #openstack-powervm17:30
*** thorst has quit IRC17:32
*** jwcroppe_ has quit IRC17:37
*** thorst_ has quit IRC17:38
*** jwcroppe has joined #openstack-powervm17:39
*** thorst has joined #openstack-powervm17:39
adreznecesberglu: Did you see Ramy's email requesting third-party CIs pin their setups to JJB 1.6.1?17:40
adreznecI think that addresses the change you merged to working around the project config tox now failing if jenkins is down17:41
esbergluadreznec: Yeah I saw that. Need to pin zuul too.17:49
adreznecWe'll probably want to do that and revert the other patch17:49
*** dwayne has joined #openstack-powervm17:55
openstackgerritDrew Thorstensen proposed openstack/networking-powervm: Add VLAN to vif binding details
*** arunman has quit IRC18:17
*** kotra03 has quit IRC18:30
*** dwayne has quit IRC18:53
openstackgerritEric Fried proposed openstack/networking-powervm: WIP: Mechanism driver & agent for powervm SR-IOV
openstackgerritEric Fried proposed openstack/nova-powervm: WIP: VIF driver implementation for SR-IOV
efriedthorst, is VLAN ID 0 valid?19:08
efriedwhat does it mean?19:08
thorstefried: totally not valid19:12
thorstI think svenkat was using that as a way to represent a FLAT (VLAN-less) network19:12
efriedOkaaaay, what does *that* mean?19:12
efriedRight now, VLAN ID is a required param to build a vNIC.19:13
efriedCan we pass a zero in?19:13
*** dwayne has joined #openstack-powervm19:16
thorstefried: I think we need kriskend19:17
thorstI would assume that we would NOT pass in a VLAN ID19:17
efriedor possibly kriskend_19:17
thorstI don't like the idea of passing in VLAN 0 and just knowing that means really no VLAN19:17
thorstthat feels more like it should be an optional parameter and default to None19:17
efriedLemme see if the schema claims that field is actually required.19:18
*** mdrabe has quit IRC19:18
*** mdrabe_ has joined #openstack-powervm19:18
efriedNot that that means anything - will ask cszhang to check too.19:18
kriskendvalid vlans start at 219:19
kriskend0 and 1 are special19:19
kriskendNot sure which the HMC defaults to if you don't set one19:20
kriskendpretty sure Emulex uses 1 if the is no vlan19:20
thorstkriskend: we don't really need to know what VLAN to set it to depending on the adapter type...right?19:21
kriskendno I think there is a standard that means.. no vlan19:21
kriskendbut I am not positive if it is 0 or 119:21
kriskend@seroyer ^19:22
kriskendseroyer ^19:22
efriedAccording to cszhang, it's zero if not specified.19:22
efriedBut right now we have it as a required param.19:22
*** k0da has joined #openstack-powervm19:23
efriedSo we either need to fix that, or we're dictating that we're not allowing a VLAN-less vNIC.19:23
thorstefried: So lets change the pypowervm API19:23
seroyerVLAN 1 is not a valid IEEE802.1q VLAN ID.  Some implementations imply that VLAN 1 means untagged.19:23
thorstto allow for VLAN-less19:23
seroyerOthers use 0.19:23
seroyerI don’t think it is defined (industry wide)19:23
efriedthorst, ack.  Coming up.19:24
seroyerPowerVM does not allow zero, and one does not imply untagged.  I’m not sure what you are trying to accomplish.19:24
efriedseroyer, the schema claims vNIC.PVID is a "defaulting" value, meaning if we omit it from the XML payload on PUT, it gets a default value.  Chongshi claims it defaults to zero in that case.  That may just be a REST statement - it may mean the core sees it as "no VLAN" - whatever that means.19:26
seroyerefried, I’ll look at the spec to confirm what zero means for vNIC PVID.19:28
seroyer(hypervisor interface spec, not rest)19:28
efriedWhat we're trying to accomplish is simply correctness through the stack with respect to this value.  Is it a valid use case in OpenStack to have "no VLAN"?  Apparently this equates to a "flat" network.  (Again, I'm regurgitating words I've seen; I don't really understand what I'm saying.)19:28
seroyerThere is a concept of no VLAN (untagged)19:28
seroyerFor vNIC19:28
seroyerNot for vEth.19:29
seroyerAt least, not exactly the same19:29
*** mdrabe_ is now known as mdrabe19:29
efriedIf this is supported by the platform, it must be represented *somehow* in REST.  I would be fine if it was represented as "that property is omitted from the XML payload".  That would imply an "optional" (as opposed to "defaulting") schema attribute; but this wouldn't be the first case where those attributes didn't match the real behavior.19:29
efriedHowever, if it defaults to zero, then either a) that's a bug, or b) that gets translated somehow at the PHYP level to mean "no VLAN".19:30
seroyerVerified that zero IS valid for vNIC client PVID, and is defined to mean “untagged”19:30
efriedseroyer, thanks.  Then I'll make it optional in pypowervm.  thorst, should I default it to None, thereby letting the platform default it to zero?  Or should I default it to zero, thereby exposing this quirk?  (Advantage to the latter is consistency - presumably if unspecified, it comes back filled in with an actual value of zero.  Advantage to the former is it more strongly implies "no VLAN".)19:32
thorstI prefer former, with a method called vlan_id that returns None if 'flat'19:33
thorstmethod ==> property19:33
efriedthorst, so I should translate 0 to None??19:37
efriedThat would be without precedent; but I can do it.19:37
thorstI think it fits the behavior properly19:38
efried(btw, this is all about pvid, not generic vlan_id)19:38
thorstthey can still go to the payload if they really wanna19:38
efriedthorst, ack.19:38
efriedAnd we call this thing "VLAN-less"?  "Flat"?  "Untagged"?19:38
*** edmondsw has quit IRC19:42
efriedthorst, ¿así?19:43
efried:param pvid: Port VLAN ID for this vNIC.  If not specified, the vNIC's19:43
efried             traffic is untagged.19:43
efriedkriskend/kriskend_, FYI, merged pypowervm change set exposing mac/cur_mac on SRIOV logical port.19:50
efriedthorst, 372119:51
kriskend_thanks eric ...19:53
thorstefried: responded...see what you think about my nit20:07
efriedthorst, lousy.20:08
efried(parasite joke)20:10
thorstefried: I responded here:
efriedWe should propose to neutron to make that guy public.20:12
thorstI thought some users liked making child class methods start with _20:13
thorstand fully private is __20:13
thorstefried: also, perhaps I need to change my try_to_bind_segment_for_agent20:16
*** apearson has joined #openstack-powervm20:16
efriedThat's what I thought.20:16
efriedBut take a look at my latest iteration of the SR-IOV change set.20:17
efriedI think I'm incorporating your change.20:17
efriedThough I renamed the method, not realizing it was an override - I'll fix that in the next iteration.20:17
thorstso I DO think you want it named that....but I'm validating.20:17
openstackgerritMerged openstack/networking-powervm: Simplify host_uuid and gets
efriedI agree, now that I've seen that it's an override.20:18
thorsta rare agreement has occurred.20:18
thorst<a hush comes over the crowd>20:18
efriedWe agree more often than we disagree.  Just sometimes one of us has to be persuaded to change his viewpoint to make it so.20:20
efriedThrough thick and thin, thorst, just know that you're ALWAYS entitled to my opinion.20:21
openstackgerritEric Fried proposed openstack/networking-powervm: WIP: Mechanism driver & agent for powervm SR-IOV
*** edmondsw has joined #openstack-powervm20:51
thorstefried: put comments on patch set 12 here:
thorstyou beat me with a new rev20:54
efriedthorst, ack, thanks.20:54
efriedAbout to start live testing.  Still need to figure out ex-monkey-patch hacks.20:54
*** thorst has quit IRC21:03
efriedthorst, help me understand this:21:03
efried# Make sure the binding host matches this agent.21:03
efried# Otherwise it is meant to provision on another agent.21:03
efriedif port.get('binding:host_id') !=
efried    continue21:03
efried"Do you REALLY want to do this?  The other SR-IOV agent does this because it doesn't support live migration.  But we will?"21:03
*** thorst has joined #openstack-powervm21:03
efriedthorst, help me understand this:21:03
efried# Make sure the binding host matches this agent.21:03
efried# Otherwise it is meant to provision on another agent.21:04
efriedif port.get('binding:host_id') !=
efried    continue21:04
efried"Do you REALLY want to do this?  The other SR-IOV agent does this because it doesn't support live migration.  But we will?"21:04
efriedI'm not understanding how this is related to migration.  Is it not saying the port is literally being created on a different host, so we should ignore it on this one?21:05
*** thorst_ has joined #openstack-powervm21:07
*** thorst has quit IRC21:07
*** thorst_ has quit IRC21:11
*** smatzek has quit IRC21:25
*** lmtaylor1 has quit IRC21:27
*** burgerk has quit IRC21:38
*** smatzek has joined #openstack-powervm21:42
*** catintheroof has quit IRC21:43
*** thorst has joined #openstack-powervm21:44
*** thorst has quit IRC21:49
*** smatzek has quit IRC21:51
*** kylek3h has quit IRC21:53
openstackgerritEric Fried proposed openstack/networking-powervm: WIP: Mechanism driver & agent for powervm SR-IOV
*** dwayne has quit IRC21:58
*** jwcroppe has quit IRC21:58
*** esberglu has quit IRC22:09
*** mdrabe has quit IRC22:10
*** jwcroppe has joined #openstack-powervm22:14
*** jwcroppe has quit IRC22:19
*** thorst has joined #openstack-powervm22:22
*** thorst has quit IRC22:23
*** tsjakobs has quit IRC22:27
*** seroyer has quit IRC22:36
*** k0da has quit IRC22:59
*** esberglu has joined #openstack-powervm23:07
*** apearson has quit IRC23:12
*** apearson has joined #openstack-powervm23:13
*** jwcroppe has joined #openstack-powervm23:15
*** esberglu has quit IRC23:18
*** thorst has joined #openstack-powervm23:24
*** apearson has quit IRC23:48
*** jwcroppe has quit IRC23:51

Generated by 2.14.0 by Marius Gedminas - find it at!