| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-08 | |||
| 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 | bauzas | lyarwood: do you want to discuss on your spec ? | |
| 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: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 | lyarwood | that would make my life easier | |
| 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: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 | dansmith | but not just a "2.98: change a bunch of 200s to 202s" | |
| 15:08:54 | bauzas | sec, giving you the API rules | |
| 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 | bauzas | https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion for nova specifics | |
| 15:10:58 | lyarwood | yes | |
| 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 ^ | |
| 15:12:48 | bauzas | but we mention something : | |
| 15:12:50 | bauzas | " | |
| 15:12:50 | bauzas | The exception to not needing a microversion when returning a previously unspecified error code is the 400, 403, 404 and 415 cases. This is considered OK to return even if previously unspecified in the code since it’s implied given keystone authentication can fail with a 403 and API validation can fail with a 400 for invalid json request body. Request to url/resource that does not exist always fails with 404. Invalid content typ | |
| 15:12:50 | bauzas | es are handled before API methods are called which results in a 415. | |
| 15:12:50 | bauzas | " | |
| 15:12:57 | lyarwood | right but at least it's fixed later when they opt-in to some other change | |
| 15:13:06 | dansmith | bauzas: that has nothing to do with this case | |
| 15:13:15 | bauzas | nothing tells us to not ask for a microversion if changing from 200 | |
| 15:13:25 | bauzas | dansmith: sure, I was just looking at what we wrote :) | |
| 15:13:45 | bauzas | to see whether we said "cool if 200 -> 202 and async" | |
| 15:13:50 | sean-k-mooney | bauzas: under that policy we sould have to do a microversion but there is no untily in changing the repssonce doe and making it opt in | |
| 15:13:51 | dansmith | lyarwood: right but all of those kinds of death-by-1000-cuts things impact people, which is why we didn't do a massive cleanup early on | |
| 15:14:10 | dansmith | lyarwood: right now if you know that api returns 200 and you check for 200, then returning 202 could break client code even though absolutely nothing has changed | |
| 15:14:25 | dansmith | it'd be bad client code, granted, but.. it's pain for pretty much no gain | |