| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-22 | |||
| 16:54:29 | sean-k-mooney | there are 2 netowrks aviable the public and private network. i know there was a bug in neutron at one point where external networks(public) would not be visiable unless also marked as shared or something like that | |
| 16:54:35 | sean-k-mooney | so maybe that was fixed | |
| 16:54:52 | sean-k-mooney | it would be more helpful if the error actully listed the networks | |
| 16:59:12 | sean-k-mooney | neutron have been modifygin there rback policy around networks https://github.com/openstack/neutron/commit/f22f7ae012e75b34051945fcac29f955861896ab | |
| 17:25:48 | elodilles | thanks melwitt and sean-k-mooney , i'll try to look into these next week (though secretly hoping that the issue is familiar to someone and there will be a fix by then o:)) | |
| 17:44:23 | sean-k-mooney | it sound like some of the issue we ocational have with tempest | |
| 17:45:03 | sean-k-mooney | but i dont recally anything sepficic | |
| 17:45:10 | sean-k-mooney | so maybe the neutron folks would know | |
| 18:19:21 | melwitt | I see there is code for handling multiple networks (https://github.com/openstack/python-novaclient/blob/2bd135c13793da48af5fbad5208b00aaba7e39dc/novaclient/tests/functional/v2/test_servers.py#L229) however that means test_boot_server_with_auto_network will be skipped. so even if we added a self.multiple_networks check to the failing test, we presumably have lost coverage of test_boot_server_with_auto_network | |
| 18:19:54 | gmann | sean-k-mooney: dansmith: melwitt: can you please check these two placement review, it is needed for oslo.policy 4.4.0 which enable new defaults by default https://review.opendev.org/c/openstack/placement/+/926870/2 https://review.opendev.org/c/openstack/placement/+/926935/1 | |
| 18:19:54 | melwitt | I have not been able to find the cause of the change in networks available in the test env | |
| 18:20:39 | opendevreview | Dan Smith proposed openstack/nova master: Use format_inspector from oslo https://review.opendev.org/c/openstack/nova/+/925025 | |
| 18:21:25 | dansmith | gmann: "X_ROLES" really? | |
| 18:23:02 | sean-k-mooney | melwitt: the test that is failing is expresssly testing booting without specifyign any network info | |
| 18:23:10 | sean-k-mooney | melwitt: on micorversion 2.1 | |
| 18:23:21 | sean-k-mooney | melwitt: which shoudl use the default network | |
| 18:23:42 | sean-k-mooney | or rahter any network if there only one | |
| 18:24:08 | melwitt | I know | |
| 18:24:36 | sean-k-mooney | im asking about htis on neutron too and they also suggested perhaps https://github.com/openstack/neutron/commit/f22f7ae012e75b34051945fcac29f955861896ab | |
| 18:24:43 | sean-k-mooney | which is what i was wondering about | |
| 18:24:56 | sean-k-mooney | so i might try pinning the neutron version to the commit before that | |
| 18:25:04 | melwitt | I'm just saying there is a different test that exists in the test suite that intends to test network auto behavior. and that test will skip itself if multiple networks are found. and I don't have a passing job run to look at whether the test used to run because the last successful run was months ago | |
| 18:25:55 | gmann | dansmith: its a common header in test class and to add service role I need to do that | |
| 18:26:17 | sean-k-mooney | melwitt: ack im wonderign if this was an unintetional change in behvior on the nturon side however | |
| 18:26:26 | sean-k-mooney | they do not use microversion | |
| 18:26:32 | sean-k-mooney | so its hard to say | |
| 18:26:33 | dansmith | gmann: but... where does it come from, or where is it honored? that's not a real-world header? | |
| 18:27:08 | sean-k-mooney | it comes for the keystone auth midelware i think? | |
| 18:27:15 | gmann | dansmith: yeah, it is just for test in NoAuthMiddleware used by tests | |
| 18:27:22 | gmann | https://github.com/openstack/placement/blob/c8255d70c89f60cf85676ac5cfbb313ea44645c0/placement/auth.py#L35C7-L35C23 | |
| 18:27:44 | melwitt | sean-k-mooney: yeah. I agree a change happened elsewhere. I was just trying to point out that even if we fix it by "if self.multiple_networks" we might have lost coverage on the other test. do we care? maybe not because it's novaclient. but I just wanted to point it out | |
| 18:28:05 | dansmith | gmann: hrm, okay | |
| 18:28:22 | sean-k-mooney | melwitt: well the cli has been deprecated for removal for 2 years now | |
| 18:28:43 | sean-k-mooney | melwitt: and as of a few weeks ago nova client is nolonger used by the osc | |
| 18:28:50 | melwitt | I knowwwww :) just mentioning the thing that I noticed | |
| 18:29:03 | sean-k-mooney | melwitt: so i wonder if its time to remove the cli or stop testing it | |
| 18:29:12 | melwitt | yeah let's bin it | |
| 18:29:33 | sean-k-mooney | taht would also fix the fact it does not run on 3.11+ | |
| 18:30:08 | melwitt | heheh | |
| 18:30:10 | sean-k-mooney | i.e. https://review.opendev.org/c/openstack/python-novaclient/+/926532 | |
| 18:30:18 | sean-k-mooney | so what would you prefer to do | |
| 18:30:40 | sean-k-mooney | just remove the job or actully drop the shell module and the correspondign tests | |
| 18:31:08 | gmann | dansmith: thanks, and this one also which reflect the oslo.policy new version in requirements.txt https://review.opendev.org/c/openstack/placement/+/926935 | |
| 18:31:20 | dansmith | gmann: yeah I'm looking through tests right now | |
| 18:31:25 | dansmith | just checking that failure | |
| 18:31:30 | sean-k-mooney | im personally hoping we can entirly drop nova client in 2025.2 if other project update to the sdk by then | |
| 18:31:33 | gmann | dansmith: ohk | |
| 18:32:14 | dansmith | gmann: so don't we need to remove some default override in placement? | |
| 18:32:27 | dansmith | or was placement not defaulting to new RBAC like others? | |
| 18:33:17 | gmann | dansmith: yeah, it was not defaulted to new RBAC and doing it in oslo.policy does it for placement with 4.4.0 | |
| 18:33:33 | gmann | with oslo.policy 4.4.0 | |
| 18:33:36 | dansmith | gmann: okay, but presumably this is almost a non-issue for placement since it's admin only? | |
| 18:33:57 | gmann | dansmith: yeah, except reshaper operation which is service' | |
| 18:34:04 | gmann | *service role only | |
| 18:34:23 | melwitt | sean-k-mooney: I dunno I was just being silly without thinking about it. I think it would be easy to make the job pass for now. not sure what to do longer term. probably need to get a sanity check at a nova meeting or something, not sure what direction most would want | |
| 18:34:31 | dansmith | gmann: okay | |
| 18:35:54 | sean-k-mooney | melwitt: ya i considered proposing a check on the number of networks and skiping the test if there was more then 1 for example | |
| 18:36:10 | sean-k-mooney | but im not sure we shoudl be investing too much effort in fixing these anymore | |
| 18:36:43 | melwitt | yeah, I hear you. I agree this is not sustainable | |
| 18:40:37 | sean-k-mooney | im going to finsih for the week soon but ill try an propsoe a DNM to try pinnign to the older neutron and see if that passes or not | |
| 18:41:00 | sean-k-mooney | and in paralle ill propsoe a quick patch to make the functional job nonvoting to unblock it | |
| 18:41:11 | sean-k-mooney | then ill check back on those on monday | |
| 18:43:04 | melwitt | ok cool | |
| 18:49:50 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test nova against LUKS inspector https://review.opendev.org/c/openstack/nova/+/925026 | |
| 18:50:05 | dansmith | melwitt: ^ | |
| 18:50:33 | dansmith | expecting nova and glance to reject that luks image currently | |
| 19:00:08 | melwitt | 👀 | |
| 19:15:07 | sean-k-mooney | melwitt: i actully think i tmight be related to https://review.opendev.org/c/openstack/neutron/+/920174 and this https://launchpad.net/bugs/2066369 | |
| 19:18:42 | opendevreview | sean mooney proposed openstack/python-novaclient master: [DNM] testing job failure https://review.opendev.org/c/openstack/python-novaclient/+/926950 | |
| 19:22:28 | opendevreview | sean mooney proposed openstack/python-novaclient master: make python-novaclient-functional non voting https://review.opendev.org/c/openstack/python-novaclient/+/926951 | |
| 19:22:49 | sean-k-mooney | https://review.opendev.org/c/openstack/python-novaclient/+/926951 shoudl make it non voting | |
| 19:36:23 | melwitt | sean-k-mooney: huh. not sure how that could result in the multiple networks but the time frame lines up | |
| 19:38:51 | sean-k-mooney | melwitt: because i think it got a 404 for any networks before | |
| 19:39:06 | sean-k-mooney | i.e. before it worked because it did not see any networks | |
| 19:39:14 | melwitt | ?! | |
| 19:39:38 | melwitt | I would not expected create with auto to work if no networks found? | |
| 19:39:52 | melwitt | weird | |
| 19:40:05 | sean-k-mooney | so now its seeing two netwroks and failing | |
| 19:40:20 | sean-k-mooney | but i think before it might now have been seeing any networks and bootign without a network | |
| 19:40:42 | sean-k-mooney | thats just a guess but that was the only neutron patch that seamed to line up | |
| 19:41:18 | melwitt | yeah.. I didn't think that "auto" would include 'none' but I don't know that level of detail about it | |
| 19:42:00 | sean-k-mooney | i have never booted a nova instance wituout passsing a network or explictly passing none | |
| 19:42:22 | melwitt | same | |
| 19:42:26 | sean-k-mooney | so im not a good judge of what shoudl work in that regard | |
| 19:43:21 | melwitt | yeah. I was just thinking superficially, "get me a network" I would not have expected no network to be an option 😂 | |
| 19:43:34 | melwitt | get me a not a network | |
| 19:44:51 | sean-k-mooney | well this test is not testing that functionatliy | |
| 19:44:58 | dansmith | "get me an airgap" | |
| 19:45:42 | sean-k-mooney | also i didnt know "self.run_hooks('modify_body_for_create', body, **kwargs)" was a thing, now can i unlearn that the nova clinet allows you to supply hooks that change its behvior | |
| 19:46:24 | melwitt | lol | |
| 19:49:05 | sean-k-mooney | the 6% ginger beer i have in the fridge might help with that | |
| 19:49:18 | sean-k-mooney | i should go test this theory o/ | |
| 19:50:14 | sean-k-mooney | melwitt: by the way this test is usign the 2.1 microverison | |
| 19:50:27 | sean-k-mooney | so its not using the autoacocate behvior | |
| 19:50:35 | sean-k-mooney | and its falling back to the older behavior | |
| 19:51:05 | melwitt | hm ok | |
| 19:51:39 | sean-k-mooney | """Required parameter when there are multiple networks defined for the tenant. When you do not specify the networks parameter, the server attaches to the only network created for the current tenant. """ | |
| 19:52:02 | sean-k-mooney | so my theory is before they fixed the bug there was no network visiable and now there are 2 | |
| 19:55:13 | melwitt | ahhh | |
| 20:05:54 | sean-k-mooney | i think we are taking this return https://github.com/openstack/nova/blob/3bdb298e685417ed0ecabbba12062d148ad58826/nova/network/neutron.py#L1181-L1189 | |