| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-08 | |||
| 10:26:57 | sean-k-mooney | but not if its odl | |
| 10:26:59 | gibi | I see | |
| 10:28:05 | sean-k-mooney | gibi: the short answer why we dont wait is we dont rebind the ports on hard reboot so we only get event for backend that send plug time event and since beforfe train we could not tell if ovs port were plug time or bind time we could not wait safly | |
| 10:28:30 | sean-k-mooney | gibi: are you seeing a issue wiht not waiting currently? | |
| 10:28:52 | sean-k-mooney | or was this just courisity | |
| 10:29:13 | gibi | I have a downstream case (on pike) where the nova unplug / replug behavior at openstack server start causes problems in ODL | |
| 10:29:40 | gibi | but you said that odl won't even send us plugtime events | |
| 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 | |