| *** thorst has joined #openstack-powervm | 01:01 | |
| *** thorst has quit IRC | 01:04 | |
| *** thorst has joined #openstack-powervm | 01:05 | |
| *** thorst has quit IRC | 01:13 | |
| *** thorst has joined #openstack-powervm | 01:26 | |
| *** thorst has quit IRC | 01:26 | |
| *** thorst has joined #openstack-powervm | 01:27 | |
| *** thorst has quit IRC | 01:31 | |
| *** jwcroppe has quit IRC | 01:38 | |
| *** jwcroppe has joined #openstack-powervm | 01:39 | |
| *** thorst has joined #openstack-powervm | 02:30 | |
| *** thorst has quit IRC | 02:30 | |
| *** thorst has joined #openstack-powervm | 02:30 | |
| *** thorst has quit IRC | 02:36 | |
| *** jwcroppe_ has joined #openstack-powervm | 02:41 | |
| *** jwcroppe has quit IRC | 02:44 | |
| *** jwcroppe_ has quit IRC | 03:03 | |
| *** jwcroppe has joined #openstack-powervm | 03:08 | |
| *** jwcroppe has quit IRC | 03:13 | |
| *** thorst has joined #openstack-powervm | 03:34 | |
| *** thorst has quit IRC | 03:41 | |
| *** Cartoon_ has quit IRC | 03:49 | |
| *** Cartoon_ has joined #openstack-powervm | 04:29 | |
| *** thorst has joined #openstack-powervm | 04:39 | |
| *** thorst has quit IRC | 04:46 | |
| *** Cartoon_ is now known as Cartoon | 05:20 | |
| *** thorst has joined #openstack-powervm | 05:43 | |
| *** thorst has quit IRC | 05:51 | |
| *** thorst has joined #openstack-powervm | 06:50 | |
| *** thorst has quit IRC | 06:56 | |
| *** k0da has joined #openstack-powervm | 07:28 | |
| *** Cartoon_ has joined #openstack-powervm | 07:40 | |
| *** Cartoon has quit IRC | 07:43 | |
| *** thorst has joined #openstack-powervm | 07:53 | |
| *** thorst has quit IRC | 08:01 | |
| *** thorst has joined #openstack-powervm | 09:00 | |
| *** thorst has quit IRC | 09:06 | |
| *** thorst has joined #openstack-powervm | 10:04 | |
| *** thorst has quit IRC | 10:11 | |
| *** thorst has joined #openstack-powervm | 11:08 | |
| *** thorst has quit IRC | 11:15 | |
| *** tlian has joined #openstack-powervm | 11:25 | |
| *** thorst has joined #openstack-powervm | 11:33 | |
| *** Cartoon has joined #openstack-powervm | 12:03 | |
| *** Cartoon_ has quit IRC | 12:06 | |
| *** thorst has quit IRC | 12:11 | |
| *** thorst has joined #openstack-powervm | 12:15 | |
| *** jwcroppe has joined #openstack-powervm | 12:16 | |
| *** kriskend has joined #openstack-powervm | 12:32 | |
| thorst | adreznec: Looks like CI is having issues. Something seems up with keystone | 12:32 |
|---|---|---|
| *** kriskend has quit IRC | 12:44 | |
| *** Ashana has joined #openstack-powervm | 12:46 | |
| *** Ashana has quit IRC | 12:49 | |
| *** Ashana has joined #openstack-powervm | 12:50 | |
| *** Ashana has quit IRC | 12:50 | |
| *** Ashana has joined #openstack-powervm | 12:51 | |
| *** burgerk has joined #openstack-powervm | 13:01 | |
| *** tblakeslee has joined #openstack-powervm | 13:06 | |
| *** Cartoon has quit IRC | 13:07 | |
| *** kriskend has joined #openstack-powervm | 13:11 | |
| *** edmondsw has joined #openstack-powervm | 13:15 | |
| *** jwcroppe_ has joined #openstack-powervm | 13:16 | |
| *** mdrabe has joined #openstack-powervm | 13:17 | |
| *** jwcropp__ has joined #openstack-powervm | 13:17 | |
| *** jwcroppe has quit IRC | 13:18 | |
| *** burgerk has quit IRC | 13:19 | |
| *** jwcroppe_ has quit IRC | 13:20 | |
| *** lmtaylor1 has joined #openstack-powervm | 13:27 | |
| *** burgerk has joined #openstack-powervm | 13:30 | |
| thorst | Ashana: adreznec and I are debating the approach to move forward. | 13:34 |
| thorst | we're basically at a cross road because, this can't be something unique to our env. So we're thinking we either missed a configuration step, or...something else. | 13:34 |
| *** esberglu has joined #openstack-powervm | 13:34 | |
| thorst | so the debate now is - do we rebuild the systems from the snapshots or do we investigate on the existing systems | 13:35 |
| adreznec | thorst: Yeah, unless this is a LXC issue specific to Power/16.04 | 13:35 |
| thorst | one of the questions is - how long does it take you to get the environment stood back up if we restore the snapshots? | 13:35 |
| thorst | adreznec: I thought Ashana was also seeing this on the x86 controller node tho? | 13:35 |
| adreznec | Ah right, so this would be a Xenial issue | 13:35 |
| adreznec | If anything | 13:36 |
| thorst | esberglu: side note: Run a quick CI run. Something is up in keystone. Mind debugging? | 13:36 |
| thorst | Ashana: so let us know what the rebuild time is. If high, we'll debug existing environment. | 13:40 |
| adreznec | thorst: Ashana I'm going to do a bit more comparison between our setup and the gate environment just to look for obvious issues. If I don't find anything we should consider trying from the base images to see if we hit this same issue | 13:40 |
| Ashana | Ok great, ill keep looking at my cfg files see if I see anything as well | 13:41 |
| adreznec | Ashana: If we do go down that route, how long would it take to get back to this point again? | 13:41 |
| adreznec | A few hours? Days? | 13:41 |
| Ashana | a few hours, becuase when I had to redo the config the last time, I was finish with it by lunch. And wouldn't the network stuff still be there because we did the capture after I did the network stuff | 13:43 |
| thorst | Ashana: network stuff would be there. Everything up to the point of capture is there. | 13:43 |
| thorst | May need to update the OSA components (in case you had any downloaded pre-capture) | 13:44 |
| Ashana | Alright | 13:45 |
| *** apearson has quit IRC | 13:49 | |
| thorst | adreznec: Let me know if I can help with the debug. Otherwise, I'll wait to see what you come up with and assist with the snapshot restore (if needed) | 13:52 |
| *** efried has joined #openstack-powervm | 13:53 | |
| adreznec | thorst: Will do | 13:54 |
| thorst | efried adreznec: May want to see the discussion here at some point: https://review.openstack.org/#/c/294596/ | 13:56 |
| thorst | esberglu: Lets also get your SSP set up today. | 13:57 |
| thorst | I've got some time to do it now. What is your system? Neo-14? | 13:58 |
| esberglu | @thorst: Yep | 13:58 |
| thorst | and it does look like the failure was on stable/mitaka | 13:58 |
| thorst | I know there are issues around that... | 13:58 |
| esberglu | Yeah. All of the stable/mitaka builds are failing with that same keystone error | 13:58 |
| thorst | OK - you've got that in your debug backlog? | 13:59 |
| esberglu | yep | 13:59 |
| thorst | rockin | 13:59 |
| thorst | esberglu: Looks like you have some old volumes attached to your neo. Can I wipe those out? | 14:04 |
| esberglu | Yeah | 14:04 |
| thorst | cool | 14:05 |
| *** apearson has joined #openstack-powervm | 14:23 | |
| thorst | esberglu: SSP is created (ci_stage_ssp) for the staging env | 14:34 |
| esberglu | thorst: Cool. I’ll reinstall today | 14:35 |
| *** apearson_ has joined #openstack-powervm | 14:40 | |
| *** mdrabe has quit IRC | 14:41 | |
| *** apearson has quit IRC | 14:43 | |
| thorst | adreznec: Any updates? Should I start with the rebuild of the system? | 14:45 |
| *** arnoldje has joined #openstack-powervm | 14:45 | |
| adreznec | thorst: Yeah, though I really am thinking we're going to have to obey the device name limits... looking in the gate job for xenial they actually are following the <16 char length | 14:48 |
| adreznec | e.g. lxc.network.veth.pair = enstack1_eth0 | 14:48 |
| adreznec | So we're going to have to be picky with our device names to keep them at <7 chars | 14:49 |
| adreznec | Unless we can find a way around it... | 14:49 |
| adreznec | We can either try renaming properly or rebuilding and redeploying | 14:50 |
| *** kriskend_ has joined #openstack-powervm | 14:50 | |
| *** tblakeslee has quit IRC | 14:55 | |
| *** apearson_ has quit IRC | 14:57 | |
| *** Ashana has quit IRC | 14:58 | |
| *** mdrabe has joined #openstack-powervm | 14:58 | |
| *** Ashana has joined #openstack-powervm | 15:00 | |
| *** apearson_ has joined #openstack-powervm | 15:00 | |
| thorst | adreznec: which names do we need to update? the br-storage? | 15:05 |
| *** jwcroppe has joined #openstack-powervm | 15:07 | |
| *** jwcropp__ has quit IRC | 15:10 | |
| *** tblakeslee has joined #openstack-powervm | 15:12 | |
| *** jwcroppe_ has joined #openstack-powervm | 15:20 | |
| *** k0da has quit IRC | 15:22 | |
| *** jwcroppe has quit IRC | 15:23 | |
| *** apearson_ has quit IRC | 15:24 | |
| *** apearson_ has joined #openstack-powervm | 15:27 | |
| *** miltonm has joined #openstack-powervm | 15:31 | |
| thorst | adreznec: Do we also need to change the vlan interfaces? | 15:33 |
| thorst | esberglu: http://184.172.12.213/15/328315/1/check/nova-powervm-pvm-dsvm-tempest-full/f8a07d5/powervm_os_ci.html | 15:36 |
| thorst | I think that this needs an actual code change in nova-powervm | 15:36 |
| thorst | the four failures there | 15:37 |
| adreznec | thorst: Yeah, I think we should try and keep all the interfaces name <=7 chars until we figure out if this is the base issue | 15:37 |
| thorst | adreznec: OK - I'll work with Ashana to make this happen | 15:38 |
| esberglu | thorst: Yeah it looks like it’s expecting a different parameter when adding the host | 15:38 |
| thorst | esberglu: Want to propose the change there? | 15:38 |
| thorst | I think its just byte typing | 15:39 |
| *** Ashana has quit IRC | 15:51 | |
| *** Ashana has joined #openstack-powervm | 15:52 | |
| *** Ashana has quit IRC | 15:56 | |
| *** Ashana has joined #openstack-powervm | 16:03 | |
| *** Ashana has quit IRC | 16:07 | |
| esberglu | thorst: Huh? Not that familiar with nova-powervm yet. | 16:08 |
| *** Ashana has joined #openstack-powervm | 16:26 | |
| *** mdrabe has quit IRC | 16:30 | |
| *** mdrabe has joined #openstack-powervm | 16:30 | |
| *** apearson_ has quit IRC | 16:30 | |
| *** Ashana has quit IRC | 16:30 | |
| *** Ashana has joined #openstack-powervm | 16:32 | |
| *** Ashana has quit IRC | 16:36 | |
| *** Ashana has joined #openstack-powervm | 16:38 | |
| *** Ashana has quit IRC | 16:42 | |
| *** tblakeslee has quit IRC | 16:42 | |
| *** Ashana has joined #openstack-powervm | 16:44 | |
| *** apearson_ has joined #openstack-powervm | 16:45 | |
| *** tblakeslee has joined #openstack-powervm | 16:47 | |
| *** Ashana has quit IRC | 16:48 | |
| *** Ashana has joined #openstack-powervm | 16:49 | |
| *** Ashana has quit IRC | 16:52 | |
| *** Ashana has joined #openstack-powervm | 16:52 | |
| thorst | esberglu: I know. Lets get you familiar :-D | 16:54 |
| thorst | I think its a simple change is why I'm recommending | 16:54 |
| *** tblakeslee has quit IRC | 16:57 | |
| *** kriskend has quit IRC | 17:02 | |
| *** kriskend_ has quit IRC | 17:03 | |
| *** Ashana has quit IRC | 17:06 | |
| thorst | adreznec: Ashana and I are trying again from my office...we changed br-storage to br-st and br-vxlan to br-vx | 17:10 |
| thorst | so far...so good... | 17:10 |
| *** Ashana has joined #openstack-powervm | 17:11 | |
| thorst | nevermind... | 17:11 |
| *** k0da has joined #openstack-powervm | 17:32 | |
| adreznec | thorst: Where did it break down this time? | 17:36 |
| thorst | same spot | 17:37 |
| thorst | but I see why - it was the ens0.2230. I had no idea why that one mattered, but it makes sense now | 17:38 |
| thorst | so I swapped those onto vlan 30, 31 and 32...which I think will meet the requirements | 17:39 |
| thorst | I know that was something tried earlier, but the VLANs weren't strung out for 30, 31 and 32...so I just did that | 17:39 |
| *** kriskend has joined #openstack-powervm | 17:54 | |
| *** kriskend_ has joined #openstack-powervm | 17:54 | |
| *** tblakeslee has joined #openstack-powervm | 17:55 | |
| thorst | adreznec: Looks like you have to wipe the original containers out to retry | 17:56 |
| adreznec | thorst: Ah yeah, it doesn't really handle cleanup | 17:57 |
| adreznec | That's why I'd wiped them out by hand before | 17:57 |
| thorst | adreznec: well I hadn't had that tidbit of info ;-) | 18:01 |
| adreznec | thorst: Ah sorry, I thought I mentioned that in Slack earlier | 18:01 |
| *** apearson_ has quit IRC | 18:02 | |
| thorst | adreznec: probably, depends on if I listened | 18:02 |
| *** apearson_ has joined #openstack-powervm | 18:03 | |
| *** k0da has quit IRC | 18:07 | |
| *** apearson_ has quit IRC | 18:34 | |
| *** apearson_ has joined #openstack-powervm | 18:43 | |
| *** tblakeslee has quit IRC | 19:04 | |
| thorst | esberglu: I think the error would be from here: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/host.py#L75 | 19:08 |
| thorst | perhaps in how we're returning the name. | 19:08 |
| *** tblakeslee has joined #openstack-powervm | 19:09 | |
| thorst | arnoldje: Did you see any benefits from the loghandler change? | 19:14 |
| esberglu | thorst: Can you explain how you came to that? | 19:21 |
| thorst | esberglu: Well, mostly I know that this is where we set the host name. And given the 'AggregatesAdminTestJSON' tests failing on something around the host name...that seems likely | 19:25 |
| thorst | now with that said... the error is: "Invalid input for field/attribute host. Value: 8247-22L*212E5DA. u'8247-22L*212E5DA' does not match '^[a-zA-Z0-9-._]*$'" | 19:26 |
| thorst | so it almost looks like the test is bad? | 19:26 |
| thorst | it looks like its a regex that's not being evaluated as a regex? | 19:26 |
| thorst | or maybe its the presence of the * in our name that throws it off... | 19:27 |
| esberglu | I think the regex is expecting an underline in our name | 19:30 |
| thorst | expecting or allowing? | 19:31 |
| thorst | it looked to me like it allows any characters, a-z, A-Z, 0-9, periods and _'s | 19:32 |
| efried | and hyphen | 19:32 |
| efried | But not splat. | 19:32 |
| thorst | right. | 19:32 |
| efried | I thought we sanitized our hostnames. | 19:32 |
| thorst | so the splat in our name I think is throwing it off | 19:32 |
| efried | Agree. | 19:32 |
| thorst | efried: we don't. | 19:32 |
| efried | Then that's a bug on our part. | 19:32 |
| thorst | instance names we do, but not the server host name | 19:32 |
| efried | it would seem. | 19:32 |
| thorst | efried: I don't know that I agree... | 19:33 |
| efried | or a regression in community code | 19:33 |
| thorst | efried: I think this is just a new test | 19:33 |
| *** seroyer has joined #openstack-powervm | 19:33 | |
| efried | svenkat, thorst, erlarese: Would like to brainstorm ideas for nova/networking-powervm implementation for SRIOV. | 19:35 |
| efried | [1] https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking | 19:35 |
| *** svenkat has joined #openstack-powervm | 19:36 | |
| efried | This assumes a couple of things. 1) That the adapter is assigned to the "hypervisor"; 2) the "hypervisor" is a linux partition; 3) You have to carve out the VFs beforehand. | 19:36 |
| efried | I think we can do better than that. | 19:36 |
| efried | But | 19:36 |
| efried | I think we can use the existing pci_passthrough_whitelist to do it. | 19:36 |
| efried | Here's what I'm thinking: | 19:36 |
| efried | pci_passthrough_whitelist is already set up to allow a (list of) dict(s) that map "devname" to "physical_network". | 19:37 |
| efried | Where 'devname' (or 'address') is supposed to represent a "PF". | 19:38 |
| thorst | efried: So I haven't read through all of this. So I apologize if my questions are absurd | 19:38 |
| thorst | NovaLink == a linux partition that 'kinda' represents the hypervisor | 19:38 |
| efried | But the SRIOV adapters aren't attached to the Novalink. | 19:38 |
| thorst | right... | 19:38 |
| efried | They belong to the platform. | 19:38 |
| thorst | so can we just obfusicate that? | 19:38 |
| efried | Swhere I'm going . | 19:38 |
| efried | What we need in order to implement SRIOV - both direct VF-to-VM and vNIC - is a way to map physical ports to physical networks. | 19:39 |
| thorst | agree. | 19:39 |
| efried | In [1], 'devname' is e.g. 'eth0' - the PF as represented in the Linux hypervisor; or 'address' is a PCI domain:bus:slot.function spec. | 19:40 |
| efried | So I'm thinking we piggyback on pci_passthrough_whitelist. The "physical_network" semantic stays as is. We need a way to refer to the physical port within the same dict. | 19:41 |
| efried | So we could a) override "devname", b) override "address", c) introduce a new key | 19:41 |
| efried | And the value would identify the pport via x) its location code, or y) some parseable combo of its adapter ID / phys port ID. | 19:42 |
| thorst | efried: the physical_network is something that maps to neutron. I'd argue devname is probably what we want to override | 19:42 |
| efried | The dict should still use physical_network. | 19:43 |
| thorst | efried: yeah. | 19:43 |
| efried | I thought that part was a given. | 19:43 |
| thorst | yep yep | 19:44 |
| thorst | address seems very specific. So I don't think we do that one... | 19:44 |
| svenkat | I am back. so we will have whiltelist in nova conf ? | 19:44 |
| efried | Arguably use physloc in there. It may also be possible for us to translate our physloc to/from a PCI spec. | 19:44 |
| efried | svenkat, that's the idea. | 19:45 |
| svenkat | ok. | 19:45 |
| svenkat | if i do lspci on novalink, will i be able to list sriov card details on it? | 19:46 |
| erlarese | are administrators required to manually set this up in nova conf or would the code generate the mapping under any circumstances ? | 19:46 |
| efried | svenkat, no, because the cards aren't assigned to the novalink. | 19:46 |
| efried | If you assigned them to the novalink, I imagine you could. | 19:46 |
| thorst | erlarese: I'd assume they set it, now if openstack-ansible were to set it for them...that's another thing | 19:46 |
| efried | erlarese, admins will be required to set up *something*. Current proposal under discussion is to allow them to set it up in a relatively familiar way in a familiar place. | 19:47 |
| *** k0da has joined #openstack-powervm | 19:47 | |
| erlarese | right, so we can't generate the mapping because we have no knowledge of what physical ports are plugged into what physical networks, right ? | 19:47 |
| efried | Correct. They will have to give that to us. And this is what we're discussing how to do via pci_passthrough_whitelist. | 19:47 |
| svenkat | also, we need to discuss about supported_pci_vendor_devs in ml2_conf_sriov.ini once we are done with whitelist. | 19:48 |
| efried | The user will use that to tell us "this physical port maps to that physical network". And we can do the rest. | 19:48 |
| efried | So a) means we're overriding the semantic of "devname" a bit - it's a physical port identifier, not a PF dev name on the hypervisor. | 19:48 |
| efried | b) means we're either overriding the semantic of "address", OR doing what may be a nontrivial amount of work to translate to/from physloc; | 19:48 |
| efried | c) means we're introducing a new key that would be outside the comfort zone of existing admins. | 19:48 |
| efried | There's another option: instead of identifying pports, we identify pport *labels*. | 19:50 |
| efried | Options a) or c) above would still pertain. | 19:50 |
| efried | But | 19:50 |
| *** tblakeslee has quit IRC | 19:50 | |
| efried | A label would actually point to N pports, which need to have been preconfigured with that label. | 19:51 |
| efried | So instead of having one entry per physical port, I would have one entry per label. (Usually one label per phys net, but I suppose it's possible to have multiple labels on the same phys net.) | 19:52 |
| erlarese | so if an OpenStack cloud had an environment where POWER systems w/ SRIOV and x86 systems w/ SRIOV co-existed, we would need some format that accommodates both? Or that wouldn't matter since each host has it's own conf? | 19:53 |
| thorst | efried: I prefer mapping as close to one to one with KVM. Which means a | 19:53 |
| thorst | erlarese: wouldn't "matter" because each has their own | 19:54 |
| efried | thorst, brings up an interesting tangent, though: we may be able to use both drivers at once. | 19:54 |
| thorst | both 'drivers'? | 19:55 |
| thorst | KVM must be able to co-exist with PowerVM (and vice versa) | 19:55 |
| efried | Those would be on separate hosts. | 19:56 |
| efried | I'm talking about pvm_vf and pvm_vnic | 19:56 |
| efried | But before we go there, let's walk through how the whitelist info gets used for each. | 19:56 |
| esberglu | thorst: So how can I sanitize the name to remove the *? Won’t that cause problems elsewhere when trying to use the sanitized value instead of the original one? | 19:56 |
| efried | First, pvm_vf (direct-attach VF to VM): User requests VM connection to a particular physical network by name. pvm_vf driver looks up which devname(s) are associated with that phys net. Driver does PUT LogicalPartition/{uuid}/SRIOVEthernetLogicalPort where payload contains adapter ID + pport ID. Done. | 19:58 |
| thorst | esberglu: I think we should do two things. 1) Ignore those tests for now. 2) Have you propose a change to Tempest that includes the * in valid host names for those tests | 19:59 |
| efried | In this case, I think it's up to the user to decide, by associating 1 or N pports with a phys_net, whether he gets 1 or N VFs created. If N, he's agreeing that the VM is responsible for NIB. And in either case, no mobility with pvm_vf. | 20:01 |
| svenkat | efried: fine. also close on how this VF will be attached to VM. i think what you descrinbed is only creation of VF ? | 20:01 |
| efried | svenkat, above PUT does the create *and* the attach. | 20:01 |
| efried | it's one op. | 20:01 |
| svenkat | efried: ok… so we need to provide VM details during PUT op… | 20:02 |
| svenkat | oh sorry . got it | 20:02 |
| efried | That's the LogicalPartition/{uuid} part. | 20:02 |
| svenkat | yes.. | 20:02 |
| efried | thorst, svenkat: any reaction to the 1/N VFs for direct attach thing? | 20:03 |
| svenkat | nope, setting up NIB on vm wiill be outside of the scope.. | 20:03 |
| efried | Here's where we should maybe look back at the discussion of whether the whitelist entry is for a pport or a label. | 20:06 |
| thorst | efried: I feel one entry per pport, not label (personally) | 20:08 |
| efried | If it's pport, we're stuck with "create VFs for all N pports on this phys net" (or "create the VF on one randomly-selected one", which I don't think we want). I don't think there's another way for the user to specify extra specs for network creation. | 20:08 |
| efried | Whereas if it's label, the user can provide different labels for the same physnet. | 20:08 |
| efried | uhh, cancel. That would be bad. | 20:09 |
| thorst | right... | 20:09 |
| thorst | its not so much that it would be randomly selected... | 20:09 |
| svenkat | labels - they already exist for pports ? who creates them | 20:09 |
| thorst | we'd have to figure out which to assign it to I guess... | 20:09 |
| thorst | I guess a label would allow us to potentially solve the redundancy issue | 20:09 |
| thorst | (where we need two ports) | 20:09 |
| thorst | (but one vnic) | 20:10 |
| efried | thorst, that's for pvm_vnic, which is what I'm getting to next. | 20:10 |
| efried | svenkat, label (and sublabel) are fields available on physical port. | 20:10 |
| svenkat | ok… | 20:10 |
| efried | Originally the thought was that the user would preconfigure them outside of the auspices of the community code. | 20:10 |
| efried | akin to SEA setup | 20:10 |
| efried | but | 20:10 |
| efried | I'm thinking we may not need this. | 20:10 |
| efried | It would be neat if the user could do *only* the nova.conf config of pci_passthrough_whitelist, with no other preconfig - and I think we can accomplish that. | 20:11 |
| efried | viz: | 20:11 |
| efried | For pvm_vnic, the user associates 1..N pports with each phys net via the whitelist. | 20:12 |
| efried | When the user asks to attach a phys net to a VM, we go find all the pports associated with that physnet, and create the vNIC via PUT LogicalPartition/{uuid}/VirtualNICDedicated with a payload of N [VIOS + adapter ID + pport ID]. | 20:13 |
| efried | I think we once again use all available pports in this scenario, creating a dot-product across all available VIOSes, distributing cards across VIOSes as much as possible. | 20:14 |
| efried | Anti-affinity algorithm. Should be relatively straightforward to code. up. | 20:14 |
| efried | So labels: | 20:15 |
| efried | We want to be able to use these for migration | 20:16 |
| thorst | +1 | 20:16 |
| efried | Question is (thorst): Can we count on the phys net having the same name on the dest as the source? | 20:16 |
| thorst | efried: Yes. | 20:16 |
| svenkat | so labels should match between source and destination for migration? (like vswitchnames in SEA today) | 20:16 |
| efried | Perfect. | 20:16 |
| efried | Then the user doesn't even need to be aware of labels. We can consume the whitelist and set the labels automatically to (some derivation of) the phys net name. | 20:17 |
| efried | Or, you know, not. | 20:17 |
| efried | Like, I'm not even sure we *need* to use the labels. | 20:17 |
| efried | Cause the user would have had to associate the destination's phys ports with the phys nets in the same way. | 20:17 |
| efried | svenkat, that's what I'm trying to brainstorm right now. At one time, we thought we were going to need to use the labels kinda like we use WWPN:fabric_name mappings for NPIV. But that may not be necessary in this case - see above. | 20:18 |
| thorst | efried: Yeah, I'm not sure we need them...but I kinda like the idea of setting them based on the OpenStack config | 20:19 |
| thorst | makes operator debug easier | 20:19 |
| efried | thorst, I can dig that idea. | 20:19 |
| efried | So let me go back just one more time to the idea of using labels as the key in the whitelist. | 20:19 |
| efried | Cons: 1) Less like existing impls; 2) Requires user preconfig (user has to set labels outside of the auspices of OpenStack). | 20:20 |
| efried | But | 20:20 |
| efried | The major pro is that the user could then conceivably twiddle around the phys ports on the fly, without having to change the config and restart the drivers. | 20:20 |
| efried | E.g. if I have to replace a card | 20:21 |
| efried | or if I want to change my redundancy profile. | 20:21 |
| erlarese | I'm not sure adding that extra layer of abstraction will be valuable for most users, but perhaps that's just me trying to simplify the implementation | 20:22 |
| efried | erlarese, agree KISS. It wouldn't be out of the question to support both mechanisms at once, but that's also complicated. | 20:23 |
| efried | So stake in the ground: support pport only for now; consider the other for future enhancement if called for. | 20:24 |
| efried | So (thorst) back to how we identify the pport. | 20:24 |
| thorst | efried: good question. | 20:25 |
| thorst | we can't follow the pattern they have in KVM | 20:25 |
| efried | UNLESS we come up with a way to translate to a PCI spec-style "address". | 20:26 |
| efried | ...which we would have to spit out in pvmctl sriov list. | 20:26 |
| efried | ...next to physloc | 20:26 |
| efried | seroyer: is there a way to map physloc to standard PCI-style domain:bus:slot.function ? | 20:27 |
| thorst | efried: damn, you're running through these items in style | 20:27 |
| efried | Almost seems like MTMS-P1-C2-T3 would map to MTMS:1:2.3 | 20:28 |
| efried | ...except we wouldn't use the .3 because that would be the VF. | 20:28 |
| thorst | MT:MS:1:2? | 20:29 |
| efried | thorst, not sure. | 20:33 |
| efried | I thought the MTMS was the enclosure (I/O drawer), P was the I/O planar, and C was the slot thereon (1:1 with the card); so T would be the phys port. | 20:34 |
| efried | So you may be right. seroyer, yt? | 20:35 |
| thorst | efried svenkat: Please document ALL of this in the blueprint as well | 20:36 |
| efried | For sure. | 20:36 |
| thorst | this whole discussion seems important to answering many of my q's in the bp | 20:36 |
| *** tlian2 has joined #openstack-powervm | 20:39 | |
| svenkat | sure.. i will update BP with these information | 20:39 |
| svenkat | efried: anything else on this topic, i will pickup these and consolidate and update nova-powervm bp | 20:41 |
| efried | thorst, svenkat, I believe I talked myself out of being able to use both pvm_vf and pvm_vnic at the same time. I can't see how we would differentiate. | 20:41 |
| thorst | efried: I believe sticking to one or the other is ideal initially | 20:42 |
| thorst | you can always add more later...but for now...I'm OK with just one at a time | 20:42 |
| efried | svenkat, yes, open question still on how we key the physical port in the whitelist entry. Need to find out whether there's a deterministic mapping from physloc to PCI-style address. | 20:42 |
| *** tlian has quit IRC | 20:42 | |
| thorst | as long as we have both options | 20:42 |
| efried | thorst, dig. | 20:42 |
| efried | svenkat, thorst, another open question is whether we should override the existing 'direct' option with this thing we've been calling 'pvm_vf'. | 20:43 |
| thorst | efried: I think so? Cause that is a VF in KVM right? | 20:44 |
| seroyer | efried: Not really, no. | 20:44 |
| efried | thorst, I think so. I'm far from expert here, but I believe that use case maps as close as we're ever going to get. | 20:44 |
| efried | Then we're only adding one driver name, pvm_vnic. | 20:45 |
| efried | seroyer, dangit, no help there? | 20:45 |
| seroyer | You don’t want to do anything with parsing location codes. They are extremely reliable on IBM branded Power systems. They are completely unreliable on OpenPower systems. | 20:45 |
| efried | seroyer, What happens if I assign a whole pport to the novalink partition and say lspci? | 20:46 |
| efried | Not that I necessarily think we should do this, but out of curiosity... | 20:46 |
| seroyer | Whole port or fraction of a port makes no difference. It’s a VF. | 20:47 |
| seroyer | Whole card is different. | 20:47 |
| efried | But presumably lspci would give me something deterministic to work with at that point? | 20:47 |
| *** k0da has quit IRC | 20:47 | |
| seroyer | Yes. But (sorry, not caught up in the history), it is not at all clear to me how that really helps you. | 20:48 |
| efried | By deterministic, I mean that any time I assign the same pport to the NL partition, it would always show up the same in lspci. | 20:48 |
| seroyer | No idea, sorry. | 20:48 |
| efried | seroyer, sure, let me recap/filter so you don't have to wade through the gorp. | 20:48 |
| efried | We want to use the existing pci_passthrough_whitelist specification in the nova.conf file to map SRIOV physical ports to physical network names. | 20:48 |
| efried | We're trying to figure out a good way to identify the physical port. | 20:49 |
| efried | We'd like to do it in a way that's familiar to existing nova users, but also usable for Power people. | 20:49 |
| efried | Using the physloc is one idea, but then we either have to override the semantic of "devname" (which in KVM is the device name of the PF on the hypervisor - e.g. "eth0"); override the semantic of "address" (by using physloc therein); or use "address" as it's defined, with a PCI-style domain:bus:slot.function spec. | 20:50 |
| efried | Or use a brand new key. | 20:51 |
| esberglu | thorst: efried: Either of you know where that regex actually defined? Having trouble finding it | 20:51 |
| efried | The "PCI style" would have been neat from a user point of view because we wouldn't have to redefine existing fields or introduce new ones, but we would be able to spit out that value alongside the physloc in pvmctl sriov list. | 20:51 |
| efried | esberglu, regex for the test case, or regex for an MTMS? | 20:52 |
| esberglu | test case | 20:52 |
| thorst | esberglu: Not off hand. | 20:52 |
| efried | esberglu Lemme see if I can find it. | 20:52 |
| efried | esberglu, what's the name of the test case? | 20:53 |
| thorst | esberglu efried: wait a sec...this may be a nova thing. | 20:53 |
| seroyer | efried, let me think on it and confer with someone. I have an idea that is more reliable than location codes. | 20:53 |
| thorst | nova/api/validation/parameter_types.py - line 204 | 20:53 |
| thorst | I need to run...but will check back later. If that is the case, we may need to change how we name our hosts. | 20:54 |
| seroyer | efried (sneak peek: use DRC index instead) | 20:55 |
| thorst | DRC index's...my favorite... | 20:56 |
| efried | seroyer, that doesn't actually help unless there's a way to map that to the PCI-style address. | 20:56 |
| seroyer | Yep. DRC index has a bus component and a slot component for PCI slots. | 20:56 |
| efried | I don't have a problem using physlocs as an opaque string. I think that would be the most useful thing for Power users. | 20:56 |
| efried | oo, cool. | 20:56 |
| *** thorst has quit IRC | 20:56 | |
| efried | seroyer, if we can nail that down, I'm greatly interested. | 20:57 |
| seroyer | Ok. | 20:57 |
| efried | lmtaylor1, you're doing something with "PCI specs"? | 20:57 |
| *** apearson_ has quit IRC | 21:01 | |
| *** thorst has joined #openstack-powervm | 21:03 | |
| *** apearson_ has joined #openstack-powervm | 21:04 | |
| *** svenkat has quit IRC | 21:05 | |
| *** thorst has quit IRC | 21:07 | |
| *** k0da has joined #openstack-powervm | 21:10 | |
| lmtaylor1 | @efried: not currently, but thorst mentioned something about working on the PCI spec with you | 21:22 |
| *** lmtaylor1 has quit IRC | 21:25 | |
| *** apearson_ has quit IRC | 21:35 | |
| *** thorst has joined #openstack-powervm | 21:35 | |
| *** apearson_ has joined #openstack-powervm | 21:36 | |
| *** thorst_ has joined #openstack-powervm | 21:39 | |
| *** thorst has quit IRC | 21:39 | |
| *** thorst_ has quit IRC | 21:43 | |
| *** seroyer has quit IRC | 21:44 | |
| efried | lmtaylor1, do you have any background on what that means? | 21:49 |
| efried | mm, never mind. | 21:49 |
| *** mdrabe has quit IRC | 21:58 | |
| *** seroyer has joined #openstack-powervm | 22:00 | |
| *** k0da has quit IRC | 22:02 | |
| efried | esberglu, yt? | 22:05 |
| esberglu | Yep | 22:05 |
| efried | It looks to me like nova-powervm itself doesn't rely on cross-referencing the system hostname anywhere. | 22:07 |
| *** edmondsw has quit IRC | 22:07 | |
| efried | If I put up a change set, as things stand right now, it'll get run through the CI with that test enabled, right? | 22:07 |
| esberglu | Yep | 22:09 |
| esberglu | Until that skip test change goes in | 22:10 |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm: WIP: Sanitize Managed System Hostname https://review.openstack.org/329205 | 22:10 |
| efried | thorst, esberglu: ^^ | 22:10 |
| efried | esberglu, once that guy finishes CI, see if it passes that particular test. | 22:11 |
| efried | Also look for any additional failures beyond previous "normal" runs. | 22:11 |
| *** arnoldje has quit IRC | 22:22 | |
| *** seroyer has quit IRC | 22:26 | |
| *** burgerk has quit IRC | 22:30 | |
| *** seroyer has joined #openstack-powervm | 22:35 | |
| *** seroyer has quit IRC | 22:38 | |
| *** k0da has joined #openstack-powervm | 22:55 | |
| *** Ashana has quit IRC | 22:58 | |
| *** Ashana has joined #openstack-powervm | 23:05 | |
| *** Ashana has quit IRC | 23:09 | |
| *** kriskend has quit IRC | 23:09 | |
| *** kriskend_ has quit IRC | 23:10 | |
| *** Ashana has joined #openstack-powervm | 23:10 | |
| *** Ashana has quit IRC | 23:15 | |
| *** k0da has quit IRC | 23:16 | |
| *** Ashana has joined #openstack-powervm | 23:16 | |
| *** tlian2 has quit IRC | 23:20 | |
| *** Ashana has quit IRC | 23:21 | |
| *** Ashana has joined #openstack-powervm | 23:22 | |
| *** Ashana has quit IRC | 23:27 | |
| *** Ashana has joined #openstack-powervm | 23:28 | |
| *** Ashana has quit IRC | 23:33 | |
| *** Ashana has joined #openstack-powervm | 23:34 | |
| *** Ashana has quit IRC | 23:38 | |
| *** Ashana has joined #openstack-powervm | 23:40 | |
| *** Ashana has quit IRC | 23:44 | |
| *** Ashana has joined #openstack-powervm | 23:46 | |
| *** Ashana has quit IRC | 23:51 | |
| *** Ashana has joined #openstack-powervm | 23:51 | |
| *** Ashana has quit IRC | 23:56 | |
| *** Ashana has joined #openstack-powervm | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!