Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-05
15:02:31 dansmith really?
15:02:48 stephenfin and we didn't see this blow up in our gate, which I guess is using ml2-ovs or ml2-lb
15:02:52 ralonsoh stephenfin, yes, this is failing in OVN
15:03:27 ralonsoh but this could happen in other situations, luckily we found it in the CI
15:03:37 stephenfin ralonsoh: am I correct in thinking that's because networking-ovn needs to add support for this extension?
15:03:52 ralonsoh stephenfin, it can... but this is not a requirement
15:03:53 stephenfin well, what was networking-ovn and is now in the core
15:04:12 stephenfin right, and ml2-ovs _does_ have it?
15:04:15 ralonsoh yes
15:04:19 stephenfin dansmith: ^
15:04:33 dansmith yikes :/
15:05:09 stephenfin so I should probably bug lucasagomes or someone to go add that for us at some point
15:05:20 stephenfin can I just say neutron's extension model is weird :)
15:05:20 ralonsoh stephenfin, I can do it
15:05:25 stephenfin not bad. just weird
15:05:37 ralonsoh but as commented, this is not mandatory
15:05:50 ralonsoh https://github.com/openstack/openstacksdk/blob/master/openstack/network/v2/floating_ip.py#L60-L64
15:06:17 stephenfin ralonsoh: No huge panic. Again, this is only used by deprecated networking proxy APIs in nova, which we'd be hoping no one would be using any more
15:06:24 stephenfin but then again, OVN is the future so...
15:25:32 sean-k-mooney we could run a ovn job on nova and have it trigger on any cnages to nova/network subtree
15:25:52 sean-k-mooney we can just grab the neutorn one and set a filter on ther files
15:26:28 sean-k-mooney want me to submit a patch for that?
15:27:36 sean-k-mooney by the way im not sure we need the port detail form the floating ip. we need the port detail from the port that has the floating ip but that is different
15:28:18 sean-k-mooney stephenfin: ralonsoh ^ i have been looking at other things so im not fully in sync with what the patch/code is doing and your conversation
15:28:55 sean-k-mooney but the only thing nova uses is the port detail form the neutron port itself
15:29:24 ralonsoh sean-k-mooney, I've submitted a patch to add this extension in OVN
15:29:25 sean-k-mooney that will always be populated if the port is bound
15:29:34 ralonsoh https://review.opendev.org/#/c/705982/
15:29:57 sean-k-mooney ralonsoh: sure but nova never need that info and enduser should not be relying on it
15:30:26 ralonsoh yes, that's why I insisted saying that this extension is not mandatory
15:30:33 sean-k-mooney im pretty sure that optional extention was added after we deprecated the proxy apis in nova
15:31:45 sean-k-mooney ralonsoh: i assume there is more to supporting the exteion then just adding that 1 line
15:32:03 ralonsoh this is the list of supported OVN extensions
15:32:04 sean-k-mooney unless this is entrily implement in the ml2 core plugin above the drivers?
15:32:14 ralonsoh this dict is used to create the config in the CI too
15:32:38 sean-k-mooney right but if networking-ovn does not have code support for it and its not implemented at teh plugin level then that is incorrect to add
15:32:53 ralonsoh sean-k-mooney, http://codesearch.openstack.org/?q=ML2_SUPPORTED_API_EXTENSIONS&i=nope&files=&repos=
15:32:55 sean-k-mooney so im asking does the networking-ovn ml2 driver need to be extended to supprot it
15:33:13 ralonsoh https://opendev.org/openstack/networking-ovn/src/branch/master/networking_ovn/l3/l3_ovn.py
15:33:38 mriosfer is recomended enable watchdog in openstack instances?
15:34:14 sean-k-mooney ok so this still seams wrong to me you should not need to enable it in the neutorn tree the driver networking-ovn repo should be provideing the support exteion list
15:35:00 sean-k-mooney mriosfer: am i dont know of any guidence either way. if yo need it then you can use it but its just an optional feature some operators wanted
15:35:41 ralonsoh sean-k-mooney, this is something still under discussion
15:35:58 sean-k-mooney ralonsoh: is the neutron/common/ovn/extensions directory added as part of try ing to merge networking-ovn back in tree
15:36:19 mriosfer sean: im going to test your notes in instances right now :)
15:36:46 ralonsoh sean-k-mooney, yes, thats in the neutron repo now
15:37:07 sean-k-mooney ralonsoh: so networking-ovn is nolonger required at all
15:37:29 ralonsoh nope
15:37:39 sean-k-mooney ralonsoh: actully thats off topic we can talk about it someother time
15:37:46 ralonsoh sean-k-mooney, sure!
15:42:27 stephenfin sean-k-mooney: I changed the behaviour to rely on that 'port_details' field in a recent patch because I didn't know it was an optional extension
15:43:07 stephenfin sean-k-mooney: we need that info purely so we can get the 'device_id' field, which is the instance UUID, for the deprecated floating IP proxy APIs
15:43:12 stephenfin deprecated by not removed
15:46:36 sean-k-mooney we should not need that however.
15:47:14 sean-k-mooney we can list the ports assocaiated with an insnatce and then we should eb able to list the floating ips assinged ot each port
15:47:35 mriosfer sean : :The requested amount of video memory 128 is higher than the maximum allowed by flavor 0 :( something i changed wrong https://gyazo.com/302f96f1f0e2363da2b9dd10ad741e3e?token=b6e41e022fa6260b90802950e02137bf
15:48:04 stephenfin sean-k-mooney: That sounds like a lot more rework though :)
15:48:20 stephenfin Possible, yes. Worth it?
15:53:10 mriosfer sean: found the parameter is : hw_video:ram_max_mb
15:54:21 openstackgerrit Stephen Finucane proposed openstack/nova master: Rework how we check for extensions https://review.opendev.org/705792
15:54:36 sean-k-mooney mriosfer: that is the flavor one
15:54:44 sean-k-mooney yes
15:56:22 Sundar sean-k-mooney: I am here if you have any comments or questions about your evaluation of Cyborg patches.
15:56:57 sean-k-mooney Sundar: when i tested them yesterday it failed in the cyborg api to send the arq binding notification to nova
15:59:26 Sundar sean-k-mooney: Could you point me to the cyborg logs?
16:02:00 sean-k-mooney Sundar: http://paste.openstack.org/show/789142/
16:05:34 Sundar sean-k-mooney: Looks like you are pulling in an old version of Cyborg patches. NovaAPIConnectFailure exception has been replaced with InvalidAPIResponse exception: https://review.opendev.org/#/c/698846/6/cyborg/common/nova_client.py
16:06:48 mriosfer sean: dxdiag should show the param of 128MB for vRAM?
16:07:16 mriosfer https://gyazo.com/1ad894cd16911a7d6f3a9083fbd65fad
16:09:43 sean-k-mooney i think so yes
16:10:02 sean-k-mooney but i have not tested that
16:32:04 mriosfer humm im not sure if machine is getting the 128MB vram
16:32:20 mriosfer sockets and threats now looks better
16:32:55 efried dansmith: Left a review on https://review.opendev.org/#/c/631243/
16:32:55 efried TL;DR: the structural comments from PS43 still need to be addressed.
16:32:55 efried But dansmith (and gibi) it would be nice if you could scan through my analysis and see if you agree, or if I'm making a big deal out of nothing.
16:33:33 efried Basically I'm saying the steps of processing the device profiles should follow the steps of processing bandwidth requests.
16:34:04 dansmith efried: I don't have context on the bandwidth stuff to make that comparison, but will read
16:34:30 efried dansmith: I seeded the code with comments in the appropriate places, hopefully it's easy enough to follow.
16:34:46 dansmith ack
16:37:24 dansmith efried: I think we've told him specifically to follow the network_info and block_device_info patterns everywhere, which I think his code does
16:37:35 dansmith efried: i.e. make these look like our other attachable things, which are ports and volumes
16:38:03 efried I don't think what I'm suggesting deviates from that, does it?
16:38:24 dansmith seems like it, but I'm still reading
16:40:55 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429
16:40:55 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.82 allowing boot from volume rescue https://review.opendev.org/701430
16:40:56 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212
16:40:56 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Support boot from volume instance rescue https://review.opendev.org/701431
16:41:00 dansmith I'm also pretty sure we specifically told him to not use the legacy reqspec.from_components stuff
16:41:06 dansmith let me see if I can find that
16:44:26 efried What he's got will work fine afaict and does seem simpler at first glance.
16:44:26 efried My concern is that it's logically very similar to how we're processing port bandwidth requests (pull stuff from flavor and $api, create granular request groups, put them in a special place in the request spec),
16:44:26 efried so it would be nice if the reader could follow that logic similarly for both kinds of resource.
16:44:37 dansmith https://review.opendev.org/#/c/631243/30/nova/objects/request_spec.py
16:45:32 dansmith granted what he was doing was a lot more than what I _think_ you want him using from_components() for
16:46:15 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add MigrationTypeField https://review.opendev.org/706013
16:46:19 efried dansmith: okay, yeah, I agree we shouldn't be doing the api callout from there. In what I'm suggesting, the device_profile_request_groups come into from_components ready-made, just like the port_resource_requests in the preceding chunk.
16:46:42 dansmith efried: shouldn't port_resource_requests just be resource_requests though?
16:46:53 efried yeah, that would be another great way to do it.
16:47:11 dansmith I'd much prefer that than just adding a new parameter of the same type of thing for each high level thing we add

Earlier   Later