Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-26
14:20:22 gibi mriedem: did you find any specific issue with oslo.versioned object?
14:20:34 mriedem nope, i didn't figure it out
14:20:44 gibi mriedem: OK thanks. then I dig forward
14:20:54 mriedem i had to go a different direction anyway on https://review.openstack.org/#/c/515423/ for the fix i was investigating
14:21:14 gibi mriedem: I see
14:24:57 stephenfin Anyone fancy looking at the two of these? Closes out kashyap's "bump libvirt" series https://review.openstack.org/#/q/topic:bump_min_libvirt_and_qemu+status:open
14:25:23 kashyap stephenfin: Oh, reminds me to finish off this too: https://review.openstack.org/#/c/567258/
14:25:33 kashyap (Was buried in something else)
14:26:10 kashyap stephenfin: Zuul is -1 on the VHOSTUSER_MQ: https://review.openstack.org/#/c/565472/
14:26:33 stephenfin kashyap: zuul lies
14:26:39 kashyap :-)
14:26:48 stephenfin But I'll recheck to be safe
14:26:51 kashyap Oh yeah
14:27:04 kashyap It's the IBM zKVM that seems to fail
14:27:22 stephenfin mriedem, gibi: surely not the same thing, but I had issues with 'field_name in an_ovs_object' vs. 'an_obv_obj.obj_attr_is_set(field_name)' https://review.openstack.org/#/c/564439/9/nova/objects/numa.py
14:27:49 stephenfin the former worked while the latter complained repeatedly about undefined attributes or something
14:28:43 kashyap stephenfin: Do you want to address Takashi's nit?
14:28:49 gibi stephenfin: interesting, thanks
14:29:21 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_VHOSTUSER_MQ https://review.openstack.org/565472
14:29:26 stephenfin kashyap: Sure, done
14:29:35 kashyap Thx!
14:29:36 gibi stephenfin: I'm suspecting something wrong with 'in' in my case
14:29:51 stephenfin gibi: Ah, other way round. Of course :)
14:29:59 mriedem stephenfin: that's because obj_attr_is_set looks for obj_fields
14:30:21 mriedem http://git.openstack.org/cgit/openstack/oslo.versionedobjects/tree/oslo_versionedobjects/base.py#n681
14:31:01 mriedem the 'in' implementation is a bit cleaner http://git.openstack.org/cgit/openstack/oslo.versionedobjects/tree/oslo_versionedobjects/base.py#n321
14:31:05 mriedem but it hides that AttributeError
14:31:22 gibi mriedem: thanks, this could be something that helps my investigation
14:31:43 gibi I thought 'in' and obj_attr_is_set is equivalent :/
14:31:52 stephenfin mriedem: Oh, good to know. I should probably call that out in the commit message
14:31:55 stephenfin gibi: As did I
14:32:23 mriedem if the field is defined on the object, they should be
14:33:38 stephenfin mriedem: I think it's because I didn't update every unit test to set 'network_info' to something
14:33:40 gibi in my case the field is defined in the fields attribute of the ovo class so for my case it should behave in the same way
14:33:46 stephenfin and didn't call the magic "set defaults" option
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

Earlier   Later