| *** jwcroppe has joined #openstack-powervm | 00:13 | |
| *** jwcroppe_ has quit IRC | 00:15 | |
| *** thorst has joined #openstack-powervm | 00:52 | |
| *** edmondsw has joined #openstack-powervm | 00:54 | |
| *** thorst_ has joined #openstack-powervm | 01:24 | |
| *** thorst has quit IRC | 01:27 | |
| *** thorst_ has quit IRC | 02:04 | |
| *** efried has quit IRC | 02:07 | |
| *** esberglu has joined #openstack-powervm | 03:12 | |
| *** esberglu has quit IRC | 03:19 | |
| *** kotra03 has joined #openstack-powervm | 03:54 | |
| *** seroyer has joined #openstack-powervm | 04:09 | |
| *** seroyer has quit IRC | 04:32 | |
| *** tjakobs has joined #openstack-powervm | 04:36 | |
| *** tjakobs has quit IRC | 04:44 | |
| *** tjakobs has joined #openstack-powervm | 05:18 | |
| *** tsjakobs has joined #openstack-powervm | 05:19 | |
| *** tjakobs has quit IRC | 05:19 | |
| *** tsjakobs has quit IRC | 06:03 | |
| openstackgerrit | ymadhavi@in.ibm.com proposed openstack/nova-powervm: [WIP] Plug updated VIFs https://review.openstack.org/350768 | 06:28 |
|---|---|---|
| openstackgerrit | Ravi Kumar Kota proposed openstack/nova-powervm: WIP: PowerVM: Implement get_instance_diagnostics https://review.openstack.org/350525 | 07:04 |
| openstackgerrit | Ravi Kumar Kota proposed openstack/nova-powervm: WIP: PowerVM: Implement get_instance_diagnostics https://review.openstack.org/350525 | 07:36 |
| *** kairo has joined #openstack-powervm | 07:36 | |
| openstackgerrit | Ravi Kumar Kota proposed openstack/nova-powervm: WIP: PowerVM: Implement get_instance_diagnostics https://review.openstack.org/350525 | 08:10 |
| *** k0da has joined #openstack-powervm | 08:15 | |
| -openstackstatus- NOTICE: Gerrit is going to be restarted | 08:39 | |
| openstackgerrit | ymadhavi@in.ibm.com proposed openstack/nova-powervm: WIP: Pre-allocate trunk adapter on target host https://review.openstack.org/350231 | 09:29 |
| *** smatzek has joined #openstack-powervm | 11:29 | |
| *** thorst has joined #openstack-powervm | 11:47 | |
| *** thorst has quit IRC | 11:47 | |
| *** thorst has joined #openstack-powervm | 11:48 | |
| *** madhaviy has joined #openstack-powervm | 12:12 | |
| *** seroyer has joined #openstack-powervm | 12:42 | |
| *** seroyer has quit IRC | 12:48 | |
| *** seroyer has joined #openstack-powervm | 12:50 | |
| *** kotra03 has quit IRC | 13:00 | |
| *** efried has joined #openstack-powervm | 13:03 | |
| *** mdrabe has joined #openstack-powervm | 13:09 | |
| thorst | efried: Trying to catch up with reviews - 3566...is that in limbo? | 13:17 |
| efried | thorst, 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 |
| thorst | ok | 13:18 |
| efried | thorst, do we need to discuss 3633? | 13:19 |
| thorst | efried: yeah. I don't like your current stance of 'adding a mapping is rare, so I may not handle that case ever' | 13:20 |
| thorst | adding to an existing mapping that is | 13:20 |
| thorst | freaks me out. | 13:20 |
| efried | Rephrase: current change set doesn't account for it; but can be added later if the demand arises. | 13:21 |
| thorst | efried: I guess what surprised me is that you think that demand doesn't exist for it now? | 13:21 |
| thorst | all our common flows just expect that function to be there | 13:21 |
| *** smatzek has quit IRC | 13:21 | |
| efried | Oh, the use case is certainly there. | 13:21 |
| thorst | the 'tasks' don't know if I'm adding a disk to existing or making new | 13:22 |
| thorst | the tasks don't know if they're spawn or add disk | 13:22 |
| thorst | by design they don't have that context...they're just 'add a disk' | 13:22 |
| efried | But 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 |
| efried | Yes - I intend to alter the spawn flow to use this new VSCSIBusBuilder. | 13:22 |
| thorst | right, but in order to invoke the new way...it seems like we're going to have to alter all the tasks and add a lot more contextual stuff into the tasks | 13:22 |
| thorst | but then retain the old flows | 13:22 |
| thorst | seems like a push up of complexity to the user of the API | 13:23 |
| thorst | benefit, sure. But at a cost. | 13:23 |
| *** seroyer has quit IRC | 13:23 | |
| efried | "user" being the community code? | 13:23 |
| thorst | in this instance | 13:23 |
| thorst | the nova-powervm code | 13:23 |
| efried | I don't disagree that it adds complexity. | 13:24 |
| efried | There are two ways to avoid that complexity. | 13:24 |
| efried | (besides not changing anything) | 13:24 |
| thorst | efried: 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 pypowervm | 13:24 |
| efried | One 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 |
| efried | The other way is to have VSCSIBus-equivalent function for everything, and completely replace stg_ftsk with a BusBuilderTask thingy. | 13:26 |
| efried | Unfortunately, we don't have VFCBus, and I'm not sure that's likely to happen. | 13:26 |
| thorst | efried: wouldn't said BusBuilderTask thingy also need to read existing context? | 13:26 |
| efried | In the general case, yes. | 13:27 |
| thorst | I'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 realistically | 13:27 |
| thorst | its the puts, and the 412's | 13:27 |
| *** lmtaylor1 has joined #openstack-powervm | 13:27 | |
| thorst | it 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/change | 13:27 |
| efried | Only if we maintain the context through the spawn flow. Which is the added complexity you're shying away from. | 13:28 |
| thorst | hmmm...I don't fully follow. | 13:28 |
| efried | Same thing we have to do today passing stg_ftsk around. | 13:28 |
| thorst | efried: o yeah...that still has to be passed around. Sure | 13:29 |
| efried | We have to maintain stg_ftsk because we don't have VFCBus. So we still need the VIOS feed for the VFC mappings. | 13:29 |
| thorst | efried: well, we have to maintain stg_ftsk for multiple reasons | 13:29 |
| *** erlarese has joined #openstack-powervm | 13:30 | |
| thorst | ex. older nova-powervm code | 13:30 |
| thorst | but yeah, strategically for vfc as well | 13:30 |
| efried | Regardless, we need to keep it. | 13:30 |
| efried | To take advantage of VSCSIBus, we would need a similar object to pass around to accumulate the VSCSI mappings. | 13:30 |
| thorst | I was also just thinking that we could use stg_tsk with the VSCSIBus | 13:30 |
| thorst | but I need to look more into this | 13:30 |
| thorst | this is no trivial change...so I want to make sure I fully investigate | 13:31 |
| thorst | which is why that review is lagging | 13:31 |
| efried | I was thinking along those lines, but I suspect it would end up being pretty hackish and ugly. | 13:31 |
| thorst | possibly. But that's why I need to dig into that | 13:31 |
| thorst | so I can convince myself its a bad idea...cause I'll just disagree with you otherwise | 13:31 |
| thorst | :-D | 13:31 |
| efried | I had intended to make a Task/VSCSIBus mixin subclass to add to the main flow. | 13:32 |
| efried | Conceivably, 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 |
| efried | I.e. peel it out of the stg_ftsk. | 13:33 |
| efried | If found, use VSCSIBus logic. Else use legacy VIOS/VSCSIMapping logic. | 13:33 |
| thorst | yeah...I'll dig in a bit. | 13:33 |
| thorst | we definitely need 'fusing'. That's a hard req for the OSes | 13:34 |
| thorst | which..I don't think KVM does the fusing like we do. I think they do a new scsi bus for each 'thing' | 13:35 |
| thorst | but I don't think IBMi or AIX (or honestly Linux) 'like' that. I know that they don't...got very strong guidance that way | 13:35 |
| *** esberglu has joined #openstack-powervm | 13:36 | |
| thorst | adreznec: wonder how bad delta will be tomorrow given their issues today... | 13:38 |
| efried | thorst, please see response on 3691, make sure it makes sense. | 13:38 |
| thorst | efried: yeah, that's a less controversial one at least | 13:39 |
| thorst | looking | 13:39 |
| efried | Messy, though. | 13:39 |
| efried | I loathe these dual- (or triple-) field values. | 13:39 |
| thorst | efried: it feels like a just because we can. | 13:39 |
| thorst | I don't actually see a strong use case for it | 13:40 |
| thorst | but also don't see a big reason to avoid it | 13:40 |
| efried | It was explained to me at length by kriskend. | 13:40 |
| thorst | other than 'ugly' | 13:40 |
| thorst | well, I get the use case kriskend is describing. I just don't know of anything that needs to do that. | 13:40 |
| efried | Basically '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 |
| efried | You're questioning whether anyone ever actually overrides the MAC? | 13:42 |
| thorst | efried: 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 |
| thorst | seems ... quite rare | 13:42 |
| efried | Wouldn'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 |
| efried | Don't some major database impls rely on MACs? | 13:43 |
| *** arunman has joined #openstack-powervm | 13:43 | |
| thorst | efried: but vNIC keeps that consistency? | 13:43 |
| efried | Wouldn't think so. | 13:43 |
| efried | Oh, you mean keeping the same MAC on LPM? | 13:43 |
| thorst | huh...I was under impression that was one of the reasons we used vNIC | 13:43 |
| efried | Hm, I guess that would make sense, but I don't know for sure. | 13:43 |
| efried | Certainly the MAC is the same for any of the VFs in the vNIC, so if failover happens, the mac doesn't change. | 13:44 |
| thorst | vNIC - keep mac and enable redundancy for VFs (so we keep performance high) | 13:44 |
| efried | And 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-powervm | 13:44 | |
| *** smatzek has joined #openstack-powervm | 13:45 | |
| openstackgerrit | Sridhar Venkat proposed openstack/nova-powervm: Blueprint for nova-powervm SR-IOV VIFs https://review.openstack.org/322203 | 13:46 |
| *** kriskend has joined #openstack-powervm | 13:47 | |
| *** kriskend_ has joined #openstack-powervm | 13:47 | |
| *** thorst has quit IRC | 13:48 | |
| *** dwayne has joined #openstack-powervm | 13:55 | |
| *** kairo has quit IRC | 13:56 | |
| *** seroyer has joined #openstack-powervm | 13:56 | |
| *** erlarese has quit IRC | 14:06 | |
| *** erlarese has joined #openstack-powervm | 14:11 | |
| *** tsjakobs has joined #openstack-powervm | 14:15 | |
| *** kotra03 has joined #openstack-powervm | 14:20 | |
| *** erlarese has quit IRC | 14:21 | |
| arunman | thorst_: Could you take a look at the latest changes for https://review.openstack.org/#/c/351270 ? I've fixed your comments and updated the patch set | 14:31 |
| thorst_ | arunman: yep | 14:34 |
| thorst_ | arunman: will that be going back to mitaka? | 14:35 |
| arunman | thorst_: Yeah | 14:35 |
| thorst_ | arunman: are you planning to finish that TODO? | 14:35 |
| arunman | I plan to have a bug written. But, I don't think I can hold this off till I merge that and come back here | 14:36 |
| thorst_ | so can you add reference to bug you opened? | 14:38 |
| thorst_ | have a -1 on it, but looks pretty good | 14:39 |
| arunman | sure, let me do that right away... and update another patch set with the bug id | 14:39 |
| thorst_ | arunman: OK - had an issue with test too | 14:40 |
| *** thorst has joined #openstack-powervm | 14:45 | |
| *** mdrabe has quit IRC | 14:46 | |
| *** thorst_ has quit IRC | 14:47 | |
| *** burgerk has joined #openstack-powervm | 14:50 | |
| *** efried has quit IRC | 14:53 | |
| *** mdrabe has joined #openstack-powervm | 14:54 | |
| *** efried has joined #openstack-powervm | 14:55 | |
| *** dwayne has quit IRC | 14:58 | |
| *** efried has quit IRC | 15:14 | |
| *** efried has joined #openstack-powervm | 15:16 | |
| *** kylek3h has joined #openstack-powervm | 15:21 | |
| *** dwayne has joined #openstack-powervm | 15:26 | |
| *** k0da has quit IRC | 15:26 | |
| thorst | esberglu: how's CI looking? | 15:30 |
| thorst | that last run is scary | 15:31 |
| *** jwcroppe_ has joined #openstack-powervm | 15:32 | |
| adreznec | Eek yeah | 15:32 |
| adreznec | 4h 37m is back where we started | 15:32 |
| thorst | was that an outlier of the change set though...or the CI itself? | 15:33 |
| thorst | adreznec: ^^ | 15:33 |
| *** jwcroppe has quit IRC | 15:34 | |
| adreznec | Good question | 15:34 |
| thorst | https://review.openstack.org/#/c/350525/ | 15:35 |
| thorst | I don't think it was the patch set.... | 15:35 |
| adreznec | yeah | 15:35 |
| adreznec | Was just looking | 15:35 |
| adreznec | Sounds like a CI issue | 15:36 |
| esberglu | thorst: 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 good | 15:37 |
| esberglu | Still spending a bunch of time in plug_vifs and crt_disk_from_img | 15:37 |
| adreznec | Ran out of disk? | 15:37 |
| adreznec | From what? logs? | 15:38 |
| esberglu | Yeah. It had like 100G of logs almost. I’m going to add something to the playbooks to clean them periodically | 15:39 |
| adreznec | I thought we already added something to do that | 15:40 |
| adreznec | A nightly cron job | 15:40 |
| thorst | lol...looks like we need more | 15:41 |
| thorst | and maybe lower log levels | 15:41 |
| adreznec | Yeah | 15:41 |
| thorst | esberglu: once we get that sorted...maybe see if clbush wants to take a look | 15:41 |
| thorst | otherwise, I think we're ready to go to clusters of 4 hosts for the SSPs | 15:41 |
| adreznec | 3010 in neo-os-ci was supposed to handle log compression/rotation | 15:42 |
| adreznec | Unless you're saying this was on the nodepool/jenkins server | 15:42 |
| adreznec | and not the openstack controller | 15:42 |
| esberglu | Nope it was on the controller | 15:43 |
| esberglu | I wonder if it is running that properly | 15:43 |
| *** thorst is now known as thorst_afk | 15:44 | |
| adreznec | Yeah, must not be | 15:44 |
| *** edmondsw has quit IRC | 15:50 | |
| *** apearson has joined #openstack-powervm | 16:07 | |
| efried | thorst_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 IRC | 16:21 | |
| *** apearson has joined #openstack-powervm | 16:21 | |
| *** catintheroof has joined #openstack-powervm | 16:28 | |
| *** thorst_a_ has joined #openstack-powervm | 16:40 | |
| *** thorst_afk has quit IRC | 16:41 | |
| *** apearson has quit IRC | 16:56 | |
| *** madhaviy has quit IRC | 17:14 | |
| *** dwayne has quit IRC | 17:14 | |
| thorst_a_ | efried: seems reasonable | 17:27 |
| *** thorst_a_ is now known as thorst | 17:27 | |
| *** edmondsw has joined #openstack-powervm | 17:28 | |
| *** thorst_ has joined #openstack-powervm | 17:30 | |
| *** thorst has quit IRC | 17:32 | |
| *** jwcroppe_ has quit IRC | 17:37 | |
| *** thorst_ has quit IRC | 17:38 | |
| *** jwcroppe has joined #openstack-powervm | 17:39 | |
| *** thorst has joined #openstack-powervm | 17:39 | |
| adreznec | esberglu: Did you see Ramy's email requesting third-party CIs pin their setups to JJB 1.6.1? | 17:40 |
| adreznec | I think that addresses the change you merged to working around the project config tox now failing if jenkins is down | 17:41 |
| esberglu | adreznec: Yeah I saw that. Need to pin zuul too. | 17:49 |
| adreznec | Ok | 17:49 |
| adreznec | We'll probably want to do that and revert the other patch | 17:49 |
| *** dwayne has joined #openstack-powervm | 17:55 | |
| openstackgerrit | Drew Thorstensen proposed openstack/networking-powervm: Add VLAN to vif binding details https://review.openstack.org/351909 | 18:04 |
| *** arunman has quit IRC | 18:17 | |
| *** kotra03 has quit IRC | 18:30 | |
| *** dwayne has quit IRC | 18:53 | |
| openstackgerrit | Eric Fried proposed openstack/networking-powervm: WIP: Mechanism driver & agent for powervm SR-IOV https://review.openstack.org/343423 | 19:03 |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm: WIP: VIF driver implementation for SR-IOV https://review.openstack.org/343419 | 19:04 |
| efried | thorst, is VLAN ID 0 valid? | 19:08 |
| efried | what does it mean? | 19:08 |
| thorst | efried: totally not valid | 19:12 |
| thorst | I think svenkat was using that as a way to represent a FLAT (VLAN-less) network | 19:12 |
| efried | Okaaaay, what does *that* mean? | 19:12 |
| efried | Right now, VLAN ID is a required param to build a vNIC. | 19:13 |
| efried | Can we pass a zero in? | 19:13 |
| *** dwayne has joined #openstack-powervm | 19:16 | |
| thorst | efried: I think we need kriskend | 19:17 |
| thorst | I would assume that we would NOT pass in a VLAN ID | 19:17 |
| efried | or possibly kriskend_ | 19:17 |
| thorst | I don't like the idea of passing in VLAN 0 and just knowing that means really no VLAN | 19:17 |
| thorst | that feels more like it should be an optional parameter and default to None | 19:17 |
| efried | Lemme see if the schema claims that field is actually required. | 19:18 |
| *** mdrabe has quit IRC | 19:18 | |
| *** mdrabe_ has joined #openstack-powervm | 19:18 | |
| efried | Not that that means anything - will ask cszhang to check too. | 19:18 |
| kriskend | valid vlans start at 2 | 19:19 |
| kriskend | 0 and 1 are special | 19:19 |
| kriskend | Not sure which the HMC defaults to if you don't set one | 19:20 |
| kriskend | pretty sure Emulex uses 1 if the is no vlan | 19:20 |
| thorst | kriskend: we don't really need to know what VLAN to set it to depending on the adapter type...right? | 19:21 |
| kriskend | no I think there is a standard that means.. no vlan | 19:21 |
| kriskend | but I am not positive if it is 0 or 1 | 19:21 |
| kriskend | @seroyer ^ | 19:22 |
| kriskend | ugh | 19:22 |
| kriskend | seroyer ^ | 19:22 |
| efried | According to cszhang, it's zero if not specified. | 19:22 |
| efried | But right now we have it as a required param. | 19:22 |
| *** k0da has joined #openstack-powervm | 19:23 | |
| efried | So we either need to fix that, or we're dictating that we're not allowing a VLAN-less vNIC. | 19:23 |
| thorst | efried: So lets change the pypowervm API | 19:23 |
| seroyer | VLAN 1 is not a valid IEEE802.1q VLAN ID. Some implementations imply that VLAN 1 means untagged. | 19:23 |
| thorst | to allow for VLAN-less | 19:23 |
| seroyer | Others use 0. | 19:23 |
| seroyer | I don’t think it is defined (industry wide) | 19:23 |
| efried | thorst, ack. Coming up. | 19:24 |
| seroyer | PowerVM does not allow zero, and one does not imply untagged. I’m not sure what you are trying to accomplish. | 19:24 |
| efried | seroyer, 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 |
| seroyer | efried, I’ll look at the spec to confirm what zero means for vNIC PVID. | 19:28 |
| seroyer | (hypervisor interface spec, not rest) | 19:28 |
| efried | What 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 |
| seroyer | There is a concept of no VLAN (untagged) | 19:28 |
| seroyer | For vNIC | 19:28 |
| seroyer | Not for vEth. | 19:29 |
| seroyer | At least, not exactly the same | 19:29 |
| *** mdrabe_ is now known as mdrabe | 19:29 | |
| efried | If 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 |
| efried | However, 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 |
| seroyer | Verified that zero IS valid for vNIC client PVID, and is defined to mean “untagged” | 19:30 |
| efried | seroyer, 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 |
| thorst | I prefer former, with a method called vlan_id that returns None if 'flat' | 19:33 |
| thorst | method ==> property | 19:33 |
| efried | thorst, so I should translate 0 to None?? | 19:37 |
| efried | That would be without precedent; but I can do it. | 19:37 |
| thorst | I think it fits the behavior properly | 19:38 |
| efried | (btw, this is all about pvid, not generic vlan_id) | 19:38 |
| thorst | they can still go to the payload if they really wanna | 19:38 |
| efried | thorst, ack. | 19:38 |
| efried | And we call this thing "VLAN-less"? "Flat"? "Untagged"? | 19:38 |
| thorst | Untagged | 19:41 |
| *** edmondsw has quit IRC | 19:42 | |
| efried | thorst, ¿así? | 19:43 |
| efried | :param pvid: Port VLAN ID for this vNIC. If not specified, the vNIC's | 19:43 |
| efried | traffic is untagged. | 19:43 |
| thorst | sure | 19:44 |
| efried | k | 19:44 |
| efried | kriskend/kriskend_, FYI, merged pypowervm change set exposing mac/cur_mac on SRIOV logical port. | 19:50 |
| efried | thorst, 3721 | 19:51 |
| kriskend_ | thanks eric ... | 19:53 |
| thorst | efried: responded...see what you think about my nit | 20:07 |
| efried | thorst, lousy. | 20:08 |
| efried | (parasite joke) | 20:10 |
| efried | responded. | 20:11 |
| thorst | efried: I responded here: https://review.openstack.org/#/c/351909/1 | 20:12 |
| efried | We should propose to neutron to make that guy public. | 20:12 |
| thorst | I thought some users liked making child class methods start with _ | 20:13 |
| thorst | and fully private is __ | 20:13 |
| thorst | efried: also, perhaps I need to change my try_to_bind_segment_for_agent | 20:16 |
| *** apearson has joined #openstack-powervm | 20:16 | |
| efried | That's what I thought. | 20:16 |
| efried | But take a look at my latest iteration of the SR-IOV change set. | 20:17 |
| efried | I think I'm incorporating your change. | 20:17 |
| efried | Though I renamed the method, not realizing it was an override - I'll fix that in the next iteration. | 20:17 |
| thorst | yooook. | 20:17 |
| thorst | so I DO think you want it named that....but I'm validating. | 20:17 |
| openstackgerrit | Merged openstack/networking-powervm: Simplify host_uuid and gets https://review.openstack.org/344399 | 20:17 |
| efried | I agree, now that I've seen that it's an override. | 20:18 |
| thorst | a rare agreement has occurred. | 20:18 |
| thorst | <a hush comes over the crowd> | 20:18 |
| efried | We 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 |
| efried | Through thick and thin, thorst, just know that you're ALWAYS entitled to my opinion. | 20:21 |
| thorst | :-) | 20:22 |
| openstackgerrit | Eric Fried proposed openstack/networking-powervm: WIP: Mechanism driver & agent for powervm SR-IOV https://review.openstack.org/343423 | 20:34 |
| *** edmondsw has joined #openstack-powervm | 20:51 | |
| thorst | efried: put comments on patch set 12 here: https://review.openstack.org/#/c/343423/12 | 20:54 |
| thorst | you beat me with a new rev | 20:54 |
| efried | thorst, ack, thanks. | 20:54 |
| efried | About to start live testing. Still need to figure out ex-monkey-patch hacks. | 20:54 |
| *** thorst has quit IRC | 21:03 | |
| efried | thorst, 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 |
| efried | if port.get('binding:host_id') != cfg.CONF.host: | 21:03 |
| efried | continue | 21: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-powervm | 21:03 | |
| efried | thorst, 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 |
| efried | if port.get('binding:host_id') != cfg.CONF.host: | 21:04 |
| efried | continue | 21: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 |
| efried | I'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-powervm | 21:07 | |
| *** thorst has quit IRC | 21:07 | |
| *** thorst_ has quit IRC | 21:11 | |
| *** smatzek has quit IRC | 21:25 | |
| *** lmtaylor1 has quit IRC | 21:27 | |
| *** burgerk has quit IRC | 21:38 | |
| *** smatzek has joined #openstack-powervm | 21:42 | |
| *** catintheroof has quit IRC | 21:43 | |
| *** thorst has joined #openstack-powervm | 21:44 | |
| *** thorst has quit IRC | 21:49 | |
| *** smatzek has quit IRC | 21:51 | |
| *** kylek3h has quit IRC | 21:53 | |
| openstackgerrit | Eric Fried proposed openstack/networking-powervm: WIP: Mechanism driver & agent for powervm SR-IOV https://review.openstack.org/343423 | 21:53 |
| *** dwayne has quit IRC | 21:58 | |
| *** jwcroppe has quit IRC | 21:58 | |
| *** esberglu has quit IRC | 22:09 | |
| *** mdrabe has quit IRC | 22:10 | |
| *** jwcroppe has joined #openstack-powervm | 22:14 | |
| *** jwcroppe has quit IRC | 22:19 | |
| *** thorst has joined #openstack-powervm | 22:22 | |
| *** thorst has quit IRC | 22:23 | |
| *** tsjakobs has quit IRC | 22:27 | |
| *** seroyer has quit IRC | 22:36 | |
| *** k0da has quit IRC | 22:59 | |
| *** esberglu has joined #openstack-powervm | 23:07 | |
| *** apearson has quit IRC | 23:12 | |
| *** apearson has joined #openstack-powervm | 23:13 | |
| *** jwcroppe has joined #openstack-powervm | 23:15 | |
| *** esberglu has quit IRC | 23:18 | |
| *** thorst has joined #openstack-powervm | 23:24 | |
| *** apearson has quit IRC | 23:48 | |
| *** jwcroppe has quit IRC | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!