| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-08 | |||
| 10:30:00 | gibi | so waiting won't be the solution | |
| 10:30:17 | gibi | wondering if for backends not supporting plug time events we need to rebind | |
| 10:30:20 | sean-k-mooney | ah ml2/odl used to send events at bind time yes not at plug time but i think later version might have adress that | |
| 10:30:43 | gibi | ohh, good info, then I have to figure out the odl version too | |
| 10:31:05 | sean-k-mooney | give me to second and ill see if i can find that in the odl neutron driver | |
| 10:32:04 | sean-k-mooney | basically to support bind time event they had to open a websock that odl could call back to to send event to neutron which neuton could then send to nova | |
| 10:32:11 | sean-k-mooney | that was not part of the orginal ml2 driver | |
| 10:32:52 | gibi | you mean for plug time event | |
| 10:33:01 | sean-k-mooney | so in the legacy driver they just hardcoded the port as active as soon as the port was bound https://opendev.org/openstack/networking-odl/src/branch/master/networking_odl/ml2/legacy_port_binding.py#L58-L61 | |
| 10:33:28 | sean-k-mooney | which resulted in network-vif-plugged beign sent at bind time only | |
| 10:34:03 | sean-k-mooney | then latere they added a way to get port status updates form odl https://opendev.org/openstack/networking-odl/commit/3432e0f875f8243a2c1febf2012bd0f58863c56b | |
| 10:34:34 | sean-k-mooney | https://opendev.org/openstack/networking-odl/src/branch/master/networking_odl/ml2/port_status_update.py#L91-L95 | |
| 10:34:46 | sean-k-mooney | and then they would correctly send plug time events | |
| 10:35:02 | sean-k-mooney | gibi: but pike might predate that | |
| 10:35:32 | gibi | cool, I can check the dates then | |
| 10:35:36 | gibi | sean-k-mooney: thanks a lot | |
| 10:36:08 | gibi | so the solution is fresh enough networking-odl to have plug time event, and the in yoga think about waiting for plug time event at reboot as well | |
| 10:36:15 | sean-k-mooney | no worries assuming we can confirm this works today we could add odl also to the list of "send plug events" or whatever and then start waiting | |
| 10:36:29 | sean-k-mooney | yep | |
| 10:36:52 | gibi | does neutron have odl jobs in the upstream ci? | |
| 10:36:53 | sean-k-mooney | so we dont really need to wait for the ptg to discuss this i just have not had time to work on a spec | |
| 10:37:05 | sean-k-mooney | good question im not sure | |
| 10:37:10 | gibi | ok I will check that too | |
| 10:37:12 | sean-k-mooney | i suspect not | |
| 10:37:24 | sean-k-mooney | networking-odl should have jobs however | |
| 10:37:48 | gibi | ahh good point that is a separate repo with it own jobs | |
| 10:38:05 | sean-k-mooney | https://opendev.org/openstack/networking-odl/src/branch/master/.zuul.d/project.yaml#L51-L52 | |
| 10:38:26 | sean-k-mooney | it also has multi node versions | |
| 10:38:38 | gibi | cool then we can have test coverage upstream about the change | |
| 10:39:06 | sean-k-mooney | am on thing i have been talking to artom about is possible adding some other network toplogies to nova's gate as a periodic | |
| 10:39:49 | sean-k-mooney | so right now we have ovs with iptables in nova-next, we have ovn for most things and linux bridge for some file changes | |
| 10:40:16 | sean-k-mooney | it might be nice to add a weekly multi node odl and ml2/ovs job | |
| 10:40:41 | sean-k-mooney | weekly multi-node job that is to tesst migration and resize ectra | |
| 10:41:09 | gibi | I would expect that some of this coverage is already running on the neutron side | |
| 10:41:34 | gibi | but if not then I agree we can add it | |
| 10:41:43 | sean-k-mooney | that will tell them if we break things but only if the project is activly beign developed | |
| 10:42:33 | sean-k-mooney | it looks like networking-odl for example only gets comiits every month or so | |
| 10:42:48 | gibi | yeah, that is a good point too | |
| 10:43:02 | gibi | then we need the periodic to trigger testing even if networking-odl is not changed | |
| 10:43:47 | sean-k-mooney | yep just to make sure we did not break something. but really weekly is more then enought i think | |
| 10:43:56 | sean-k-mooney | we can review it like the placment jobs | |
| 10:44:41 | gibi | yepp, agree | |
| 10:45:04 | sean-k-mooney | gibi: i would also like to add dpdk at some point but i have not been maintaining networking-ovs-dpdk so i will need to add devstack support for dpdk or fix it before thats even posible at this poing | |
| 10:45:07 | sean-k-mooney | *point | |
| 10:46:00 | gibi | I support that idea too. Downstream we use dpdk a lot, so would be nice to get coverage for it upstream. | |
| 10:46:15 | sean-k-mooney | fortunetly on the dpdk front its support by distros now so its now just a matter of turning it on and seting a few config values but still need to sit down and do that | |
| 10:46:38 | gibi | let me know if I can help | |
| 10:47:00 | sean-k-mooney | sure will do. when i get around to workign on the devstack patches ill let you know | |
| 11:09:46 | opendevreview | sean mooney proposed openstack/nova master: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/811947 | |
| 11:14:44 | sean-k-mooney | noonedeadpunk: hopefully you dont mind me updateing ^ | |
| 11:15:07 | sean-k-mooney | gibi: can you take a look at ^ when you have time | |
| 11:16:26 | gibi | ack I will try | |
| 11:19:48 | noonedeadpunk | sure I'm not! | |
| 12:20:59 | opendevreview | Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/813180 | |
| 14:37:22 | lyarwood | stupid Friday question but can anyone think of an API where we've changed the return code in a microversion? I want to fix the POST os-volume_attachments method to return 202 but I can't think of the best way to do this | |
| 14:39:17 | lyarwood | ah nvm I see just duplicate the actual method and decorate it | |
| 15:00:02 | bauzas | lyarwood: correct, I was about to point it to you | |
| 15:00:09 | bauzas | (sorry for the late ping, kids taxi) | |
| 15:00:20 | stephenfin | lyarwood: There are quite a few APIs that suffer from that issue. Are you just going to do the one or multiple? | |
| 15:00:20 | bauzas | lyarwood: do you want to discuss on your spec ? | |
| 15:04:11 | bauzas | lyarwood: fwiw, I'm leaving in 25 mins for the weekend | |
| 15:06:43 | lyarwood | bauzas: sorry was just getting a drink, happy to chat now if you had any questions etc | |
| 15:06:59 | bauzas | I briefly looked at your spec | |
| 15:07:21 | lyarwood | stephenfin: just os-volume_attachments for now but I'll likely start to address others once I've worked this out | |
| 15:07:48 | lyarwood | I'm not sure if people would prefer a single microversion for everything etc | |
| 15:08:10 | dansmith | so, I'm pretty sure that we originally said we wouldn't do microversions for things like this | |
| 15:08:27 | bauzas | if 500, yes | |
| 15:08:31 | dansmith | because nobody is going to opt-in to a new return code, or opt out (back?) to the old one | |
| 15:08:31 | lyarwood | that would make my life easier | |
| 15:08:38 | sean-k-mooney | dont we requrie a microversion if you are chaning the reponcoe code to one that is not currently used | |
| 15:08:42 | bauzas | I mean, 500 to something clearer, not a microversion | |
| 15:08:45 | dansmith | if you're changing other things about the api, then doing the return code as part of it makes sense | |
| 15:08:54 | bauzas | sec, giving you the API rules | |
| 15:08:54 | dansmith | but not just a "2.98: change a bunch of 200s to 202s" | |
| 15:09:13 | sean-k-mooney | well 200 to 202 is blocking to async | |
| 15:09:16 | lyarwood | I wonder why we have TODOs everywhere for this then | |
| 15:09:19 | dansmith | sean-k-mooney: yeah, I'm not saying do it without a microversion, I'm saying don't do it unless there's something else changing | |
| 15:09:44 | lyarwood | oh sorry I see | |
| 15:09:53 | sean-k-mooney | https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202 | |
| 15:09:58 | lyarwood | well tbh it's never going to get done in that case | |
| 15:10:33 | sean-k-mooney | lyarwood: you want to move this to be an async api yes? | |
| 15:10:40 | dansmith | if we | |
| 15:10:44 | bauzas | https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html for the API general rules | |
| 15:10:46 | lyarwood | sean-k-mooney: it already is | |
| 15:10:55 | sean-k-mooney | oh then 200 is wrong ya | |
| 15:10:58 | lyarwood | yes | |
| 15:10:58 | bauzas | https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion for nova specifics | |
| 15:11:04 | dansmith | are moving it from sync to async, then *of course* it makes sense to change, but just a microversion for changing the return code but not the behavior is kinda silly | |
| 15:11:22 | sean-k-mooney | right | |
| 15:11:28 | sean-k-mooney | im more ok with not haveing a microversion | |
| 15:11:32 | sean-k-mooney | if we are not changing behavior | |
| 15:11:35 | sean-k-mooney | just the return code | |
| 15:11:44 | dansmith | I'm not saying we should do that | |
| 15:11:46 | bauzas | technically, we agreed on asking for a microversion https://docs.openstack.org/nova/latest/_images/graphviz-a4c9682faf139450eed50fdcc7dd06df5677c197.png | |
| 15:12:04 | bauzas | unless it was changing from HTTP500 | |
| 15:12:05 | dansmith | I'm saying returning 200 for an async api that has always been async is unfortunate, but not that big of a deal | |
| 15:12:07 | sean-k-mooney | dansmith: you are say until we modify tese again dont change it | |
| 15:12:14 | dansmith | sean-k-mooney: yes | |
| 15:12:32 | dansmith | nobody is going to opt-in to "no new behavior but a more accurate return value" | |
| 15:12:45 | sean-k-mooney | i think that is also reasonable becasue of ^ | |