| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-26 | |||
| 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 | |
| 16:26:34 | stephenfin | I need that object for two things | |
| 16:26:42 | mriedem | so you're building business logic into the InstanceNUMANetworkAffinity object | |
| 16:26:59 | mriedem | it seems what you really need is a simple object that contains the physnet name and tunneled value (based on type) | |
| 16:27:07 | mriedem | you get a list of those and put them in the request spec or whatever for scheduling | |
| 16:27:22 | mriedem | if at least 1 is tunneled, then you do your business logic for that later | |
| 16:27:29 | tssurya | mriedem: ack , I will backport it now | |
| 16:27:58 | tssurya | also the spec is updated, I am working on the POC for our final option | |
| 16:28:00 | dansmith | mriedem: I guess I'm not sure why you need the tunneled value .. I thought if physnets is set, it implies !tunneled | |
| 16:28:33 | stephenfin | dansmith: not if my host is connected to multiple networks | |
| 16:28:49 | stephenfin | ditto for my guest | |