Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-26
14:40:42 mriedem stephenfin: i guess geneve must be newish? https://docs.openstack.org/neutron/pike/admin/intro-overlay-protocols.html
14:40:52 mriedem not listed there for tunneled ^
14:41:14 stephenfin mriedem: Yeah. I found it referenced in other docs but haven't had a chance to update those
14:41:25 stephenfin Seems to be some kind of uber protocol
14:42:03 mriedem https://bugs.launchpad.net/neutron/+bug/1778741
14:42:05 openstack Launchpad bug 1778741 in neutron "Overlay (tunnel) protocols in Neutron - missing geneve" [Undecided,New]
14:42:32 kashyap dnf search reno
14:42:38 kashyap Oops
14:42:53 stephenfin https://github.com/openstack/neutron/blob/master/doc/source/feature_classification/provider_network_support_matrix.ini#L65
14:43:27 mriedem stephenfin: yeah i saw that but it doesn't mention tunneling
14:44:05 stephenfin mriedem: How about...this one? https://github.com/openstack/neutron/blob/master/doc/source/contributor/internals/openvswitch_agent.rst#geneve-tunnels
14:44:11 stephenfin #DocStruggles
14:48:52 mriedem ack
14:48:54 mriedem linked into the bug
14:49:05 mriedem stephenfin: a few things in https://review.openstack.org/#/c/564445/
14:49:13 stephenfin ack
14:56:19 openstackgerrit Merged openstack/nova master: Ironic update_provider_tree: restore traits override https://review.openstack.org/576877
14:56:25 openstackgerrit Merged openstack/nova stable/queens: ironic: stop lying to the RT when ironic is down https://review.openstack.org/575628
15:03:07 openstackgerrit Matt Riedemann proposed openstack/nova master: Skip ServerShowV247Test.test_update_rebuild_list_server in nova-cells-v1 job https://review.openstack.org/578125
15:03:51 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Add test demonstrating bug 1778743 https://review.openstack.org/578126
15:03:51 openstack bug 1778743 in OpenStack Compute (nova) "When POSTing to /allocations with multiple consumers it is possible violate inventory capacity constraints" [Medium,Triaged] https://launchpad.net/bugs/1778743
15:04:32 stephenfin mriedem: Right back at ya (just a small question) https://review.openstack.org/#/c/546256/4/nova/api/openstack/compute/servers.py
15:06:25 mriedem oh boy that's an old one
15:07:56 gibi stephenfin: if there is a field in an ovo that has a default value but obj_set_defaults is not called then that field is considered invalid as per http://git.openstack.org/cgit/openstack/oslo.versionedobjects/tree/oslo_versionedobjects/base.py#n679 ?
15:08:27 mriedem stephenfin: replied
15:08:44 stephenfin gibi: Would need dansmith to double confirm but that's my understanding, yeah
15:09:01 gibi stephenfin: thanks
15:09:02 dansmith gibi: unset you mean?
15:09:10 dansmith gibi: s/invalid/unset/
15:09:10 mriedem right obj_attr_is_set and 'in' are commonly used to determine if the field is even set
15:09:29 mriedem to avoid things like lazy-loads that might explode
15:09:43 stephenfin the latter of which works quite well if your default is also None, I guess
15:10:01 dansmith the default= thing was added for some really stupid specific nova-related converting-to-objects cases, which we really shouldn't have kept over when we moved to oslo,
15:10:04 dansmith which is why it's weird
15:10:22 stephenfin dansmith: Can we deprecate it?
15:10:40 dansmith if it's something that need not be lazy-loaded, my recommendation is to add a lazy-load handler that sets the default on a missing field if it's referenced and not set
15:10:57 dansmith stephenfin: I dunno who else uses it and I suspect that dance is not worth the trouble
15:10:58 gibi dansmith: OK, so it is just unset but not invalid. I just tried in a small object and obj_attr_is_set doesn't raise AttributeError
15:11:21 dansmith gibi: default doesn't have anything to do with obj_attr_is_set
15:11:48 gibi dansmith: but obj_set_default call affect the result of obj_attr_is_set as far as I understand
15:12:09 dansmith gibi: obj_set_defaults can _set_ fields, so.. yes, of course it can affect the is_set result :)
15:12:16 gibi dansmith: OK :)
15:13:18 stephenfin dansmith: If I _were_ to look at deprecating it, the lazy-load handler is the recommended alternative, yeah?
15:15:32 gibi stephenfin: if somebody want to assign default values to ovo fields she can do it in __init__ any time
15:16:10 jaypipes melwitt, mriedem, dansmith: would https://blueprints.launchpad.net/nova/+spec/vrouter-os-vif-conversion need a spec in order to be approved?
15:18:38 stephenfin gibi: Ima rename NUMANetworkInfo to NUMANetworkAffinity here. Make sense to you? https://review.openstack.org/#/c/564439/7/nova/objects/numa.py
15:19:51 gibi stephenfin: works for me
15:23:32 mriedem jaypipes: looking at the copious comments in the spec itself https://review.openstack.org/#/c/567148 it seems like it's non-trivial
15:23:53 mriedem that is also a spec for https://blueprints.launchpad.net/nova/+spec/vrouter-hw-offloads
15:26:31 mriedem stephenfin: should this also be renamed then? https://review.openstack.org/#/c/564444/10/nova/objects/instance_numa_topology.py
15:26:48 jaypipes mriedem: the migrate to os-vif part (Stage 1 in the spec) isn't really a big deal and jangutter would like to get it into Rocky.
15:27:18 mriedem vrouter is already supported in nova using os-vif and their plugin
15:27:22 mriedem since pike i think
15:27:32 stephenfin mriedem: Yup, just reworking that. I'll have it pushed before it can get into the gate
15:27:40 jangutter mriedem: only the vhostuser plugging path, the kernel path is still old vif.
15:29:15 mriedem so target is https://review.openstack.org/#/c/571325/
15:29:21 mriedem not the hw offload stuff that's in the spec
15:29:33 jangutter mriedem: for that blueprint yeah.
15:29:59 jangutter mriedem: and also, whacking the dual-vhostuser method -> basically a straight 1:1 conversion.
15:30:19 openstackgerrit Chris Dent proposed openstack/nova master: WIP: [placement] Fix capacity tracking in POST /allocations https://review.openstack.org/578133
15:30:53 jangutter mriedem: the dual-vhostuser path was "speculatively" added by me to address migration to a different VIF type. (Hopefully in Rocky)
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 openstackgerrit Chris Dent proposed openstack/nova master: [placement] demonstrate part of bug 1778591 with a gabbi test https://review.openstack.org/578139
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
16:08:56 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Add test demonstrating bug 1778743 https://review.openstack.org/578126
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: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

Earlier   Later