| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-26 | |||
| 15:32:03 | mriedem | to answer jaypipes' question, i don't think converting legacy vif type support to os-vif requires a spec; the hw offload stuff likely does (and already has one); i've updated the blueprints so the hw offload blueprint depends on the vrouter os-vif conversion blueprint | |
| 15:32:44 | jangutter | mriedem: ah, there's such thing as blueprint dependencies!?? (spot the newb) | |
| 15:32:53 | mriedem | whether or not we should make an exception for the os-vif conversion blueprint in rocky, is a question for (1) the weekly nova team meeting open discussion section for specless blueprints and (2) likely a yay/nay from melwitt | |
| 15:33:25 | mriedem | https://review.openstack.org/#/c/571325/ doesn't look trivial to me given the dependencies on external repos and such | |
| 15:34:14 | mriedem | this also sounds like a migration headache, given if i'm using vhostuser now with this, i'm using contrail_vrouter right? but with this change i'd be using vif_type=vrouter | |
| 15:34:15 | mriedem | yes? | |
| 15:34:16 | jangutter | mriedem: you mean given dependency on an external os-vif plugin? | |
| 15:35:10 | jangutter | mriedem: with the straight conversion there's going to be no difference in migration dependencies. | |
| 15:35:44 | jangutter | mriedem: i.e. it's not going to improve or make it worse: from neutron's perspective nothing's going to change. | |
| 15:35:50 | mriedem | i only see vif type contrail_vrouter defined here https://github.com/Juniper/contrail-nova-vif-driver/blob/master/setup.py#L27 | |
| 15:36:01 | mriedem | and there is no vrouter vif type defined in https://review.opencontrail.org/#/c/43399 | |
| 15:36:50 | jangutter | mriedem: correct, that's the third patch in a series: https://review.opencontrail.org/#/c/43359/ | |
| 15:37:23 | jangutter | the first two tries to keep the contrail_vrouter plugin intact. | |
| 15:38:03 | jangutter | if those patches need to land before the blueprint is approved, I can coordinate with the Juniper/Tungsten Fabric people. | |
| 15:39:45 | mriedem | stephenfin: https://review.openstack.org/#/c/564444/10/nova/objects/instance_numa_topology.py is in the gate right now | |
| 15:39:57 | mriedem | so if you're going to rename that object, you'd better update the commit message or something quick to kick it out | |
| 15:43:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Always retrieve network information if available https://review.openstack.org/564444 | |
| 15:43:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Retrieve tunneled status in '_get_physnet_info' https://review.openstack.org/564445 | |
| 15:43:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add NUMACell.network_affinity https://review.openstack.org/564439 | |
| 15:43:51 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add NUMATopologyLimits.networks https://review.openstack.org/575486 | |
| 15:43:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Start accounting for networks in NUMA placement https://review.openstack.org/564448 | |
| 15:43:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add RequestSpec.numa_networks https://review.openstack.org/564442 | |
| 15:43:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing RequestSpec.numa_networks https://review.openstack.org/564452 | |
| 15:43:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440 | |
| 15:43:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_info field https://review.openstack.org/564441 | |
| 15:43:58 | mriedem | whew | |
| 15:51:40 | mriedem | tssurya: are you going to backport this? https://review.openstack.org/#/c/575734/ | |
| 15:57:19 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: conf: libvirt: Make `/dev/urandom` the default for 'rng_dev_path' https://review.openstack.org/577385 | |
| 15:58:48 | openstack | bug 1778591 in OpenStack Compute (nova) "GET /allocations/{uuid} on a consumer with no allocations provides no generation" [Medium,Triaged] https://launchpad.net/bugs/1778591 | |
| 15:58:48 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] demonstrate part of bug 1778591 with a gabbi test https://review.openstack.org/578139 | |
| 16:08:56 | openstack | bug 1778743 in OpenStack Compute (nova) "When POSTing to /allocations with multiple consumers it is possible violate inventory capacity constraints" [Medium,In progress] https://launchpad.net/bugs/1778743 - Assigned to Chris Dent (cdent) | |
| 16:08:56 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Add test demonstrating bug 1778743 https://review.openstack.org/578126 | |
| 16:08:57 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: [placement] Fix capacity tracking in POST /allocations https://review.openstack.org/578133 | |
| 16:13:06 | dansmith | stephenfin: so I don't want to get into a naming war, but your recent rename made me think.. | |
| 16:13:11 | dansmith | stephenfin: this is not really instance-related: https://review.openstack.org/#/c/564444/11/nova/objects/instance_numa_topology.py | |
| 16:13:26 | dansmith | so calling it InstanceNUMAAnything seems like unnecessary long-name-ification | |
| 16:13:35 | dansmith | and I'm not sure it really has anything to do with affinity | |
| 16:13:56 | dansmith | "info" seemed more accurate to me, or "details" | |
| 16:14:09 | dansmith | actually, it doesn't really seem to have much to do with NUMA either | |
| 16:14:18 | stephenfin | dansmith: :) | |
| 16:14:19 | dansmith | so maybe the affinity is because of the physnet link, but.. | |
| 16:14:22 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Use instance project/user when creating RequestSpec during resize reschedule https://review.openstack.org/577929 | |
| 16:14:24 | stephenfin | agrred on the first at least | |
| 16:14:39 | stephenfin | I actually have an objects that's identical later in the series https://review.openstack.org/#/c/564439/10/nova/objects/numa.py@157 | |
| 16:14:45 | stephenfin | Like, down to the hash | |
| 16:14:52 | dansmith | um | |
| 16:14:54 | dansmith | that's no good | |
| 16:14:55 | openstackgerrit | Merged openstack/nova master: xenapi: drop deprecated vif_driver config option https://review.openstack.org/567877 | |
| 16:15:17 | stephenfin | But I didn't want to reuse that in case I wanted to add specific properties or the likes in the future | |
| 16:15:51 | mriedem | InstanceNUMANetworkAffinity is meant to be the requested thing right? | |
| 16:15:57 | mriedem | NUMANetworkAffinity is the inventory on the host | |
| 16:16:03 | mriedem | s/host/NUMACell/ | |
| 16:16:07 | stephenfin | Yup | |
| 16:16:10 | dansmith | I don't think so | |
| 16:16:17 | mriedem | that was my understanding from the spec | |
| 16:16:17 | stephenfin | well | |
| 16:16:27 | stephenfin | first one is metadata about the requested thing (networks) | |
| 16:16:28 | dansmith | we're populating the InstanceNUMAOne from the details of the network you asked for right? | |
| 16:16:30 | dansmith | right | |
| 16:16:41 | dansmith | it's all metadata about the network, regardless of why we're looking for it | |
| 16:17:04 | dansmith | seriously, why not call this NetworkDetails ? | |
| 16:17:34 | stephenfin | No reason not to, other than it sounding mighty generic | |
| 16:17:46 | dansmith | right, but none of this really has anything to do with NUMA itself, | |
| 16:17:57 | dansmith | we're just adding it whilst doing some NUMA stuff, which doesn't make it NUMA-related | |
| 16:18:06 | mriedem | if only we had a nova.objects.Network object... | |
| 16:18:19 | mriedem | i kid | |
| 16:18:25 | stephenfin | dansmith - a man after jaypipes' own heart | |
| 16:18:39 | stephenfin | a'ight, NetworkDetails it is | |
| 16:18:53 | dansmith | stephenfin: and only one please :) | |
| 16:19:03 | stephenfin | all those patches are going to fail anyway. I half-assed the rebase to get it out of the gate | |
| 16:19:19 | dansmith | stephenfin: does tunneled apply to non-physnet-related networks? | |
| 16:19:30 | mriedem | is that thing going to be defined in nova/objects/network.py? because right now you have those other objects in numa-specific modules | |
| 16:19:30 | dansmith | NetworkPhysicalDetails if tunneled is physnet-specific | |
| 16:19:57 | stephenfin | yes. A network is either L2 (physnet) or L3 (tunnelled) | |
| 16:20:08 | dansmith | um | |
| 16:20:31 | dansmith | so why are physnets and tunneled on the same object? | |
| 16:20:43 | dansmith | could you ever have tunneled=True with something non-empty in physnets/ | |
| 16:21:07 | stephenfin | sean-k-mooney[m] tells me yes, I can | |
| 16:21:11 | jaypipes | dansmith: I asked the exact same question of stephenfin :) | |
| 16:21:17 | stephenfin | but in general, you'd have one or the other set | |
| 16:21:24 | dansmith | stephenfin: so why do we need both? | |
| 16:21:30 | dansmith | if physnets is empty, it's tunneled? | |
| 16:22:21 | stephenfin | We don't create one of these objects for ever requested network - we combine them for multiple networks | |
| 16:22:30 | stephenfin | So I could request networks a to d | |
| 16:22:34 | mriedem | that raises a concern / question i had in the patch that sets tunneled during the api request processing | |
| 16:22:45 | stephenfin | c could be a VXLAN network | |
| 16:22:53 | stephenfin | a and b could use physnet foo | |
| 16:22:59 | stephenfin | and d could use physnet c | |
| 16:23:00 | dansmith | stephenfin: I'm super confused now | |
| 16:23:01 | stephenfin | *d | |
| 16:23:09 | mriedem | https://review.openstack.org/#/c/564445/10/nova/network/neutronv2/api.py@1660 | |
| 16:23:27 | stephenfin | OK, from the top | |
| 16:23:27 | mriedem | according to ^ if any requested network is tunneled, they are all going to be marked as tunneled | |
| 16:23:30 | dansmith | (note that this is why I like to avoid merging objects until we see how they're used) | |
| 16:23:35 | mriedem | even if one is vlan | |
| 16:24:58 | stephenfin | A L2 network can be mapped to one of many physical networks | |
| 16:25:11 | stephenfin | *A neutron L2 networks | |
| 16:25:28 | stephenfin | but neutron only supports a single tunnel endpoint | |
| 16:26:11 | openstackgerrit | Merged openstack/nova master: network: Rename '_get_phynet_info' https://review.openstack.org/577233 | |
| 16:26:16 | openstackgerrit | Merged openstack/nova master: network: Rename 'create_pci_requests_for_sriov_ports' https://review.openstack.org/575488 | |