| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-02 | |||
| 18:13:02 | sean-k-mooney | ac | |
| 18:13:04 | sean-k-mooney | ack | |
| 18:13:42 | gmaan | accordingly I can work on some doc on that, which is what i mentioned to you about doc bcz it is not consistent and agreed | |
| 18:14:47 | sean-k-mooney | anyway melwitt we got side tracked | |
| 18:14:54 | sean-k-mooney | i approved the devstack patch | |
| 18:15:38 | sean-k-mooney | i think once i look at the tempest resut im ok eot start ith the nova-vtpm job as seprate but i would really prefer to consoldiate it with nova-next or nova-alt-config i think in the future | |
| 18:23:10 | melwitt | thanks sean-k-mooney | |
| 18:24:26 | sean-k-mooney | so its currently runnign 3 live migrtiton tests https://ee4ee966b92d55ec0885-e7631c5842b30279943de651c580e67f.ssl.cf2.rackcdn.com/openstack/82adf7b225984621891eae9f930ba6ab/testr_results.html | |
| 18:24:54 | sean-k-mooney | that usign the host policy right | |
| 18:25:07 | sean-k-mooney | where we copy the secret over rpc | |
| 18:25:47 | sean-k-mooney | and i assume we will have additoanl tempest test for deployment eventually with a new compute feature flag or a change to the tempest config to enable those later | |
| 18:25:50 | melwitt | yes | |
| 18:26:11 | melwitt | yes, those are proposed already bc what I did was split them out when we weren't going to get to merge deployment mode yet | |
| 18:27:05 | sean-k-mooney | ack but they will need to be gated by a new flag in the compute_feature_flags in tempest or similar in whitebox | |
| 18:27:24 | sean-k-mooney | becasue master tempet need to supprot the older branches i.e. 2026.1 | |
| 18:27:26 | gmaan | yeah | |
| 18:27:44 | sean-k-mooney | so we will eenither need to have a new config for the aviabel deployment modes | |
| 18:27:47 | sean-k-mooney | and skip based on taht | |
| 18:28:03 | sean-k-mooney | which woudl be my prefernce in this case since ist a list in nova | |
| 18:28:21 | sean-k-mooney | or boolean values | |
| 18:28:51 | sean-k-mooney | the reason im askign is becasue i dont see the poplicies defiend here https://review.opendev.org/c/openstack/nova/+/978841/6/.zuul.yaml#424 | |
| 18:30:18 | sean-k-mooney | looks like tempest currently just has a bool for is it suprptoed at all https://review.opendev.org/c/openstack/tempest/+/957475/31/tempest/config.py | |
| 18:30:30 | melwitt | ah it's bc during review we changed to make the parent job devstack-whitebox-multinode and they are set there already | |
| 18:30:31 | sean-k-mooney | which is ok for now but we will need to evolve that | |
| 18:30:39 | melwitt | *whitebox-devstack-multinode | |
| 18:31:37 | sean-k-mooney | it also only hass a bool | |
| 18:31:39 | sean-k-mooney | https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/config.py#L371-L373 | |
| 18:31:49 | sean-k-mooney | not which mode the host is in | |
| 18:32:01 | sean-k-mooney | i guess | |
| 18:32:20 | sean-k-mooney | from a pure tempest poitn of view it does not care | |
| 18:32:28 | melwitt | yeah, since we split the policies we'll need a separate gate for the hibiscus ones. if it had not split we would just have the bool. but alas | |
| 18:32:39 | sean-k-mooney | but we cant test both mdoes properly at the same time | |
| 18:33:15 | sean-k-mooney | melwitt: so the point im tryign to make is we need to be able to test botht the case wehre nova owns the secrete | |
| 18:33:23 | sean-k-mooney | and the case wehre the user does but we can copy it | |
| 18:33:33 | melwitt | yeah I was thinking of the current config of the supported modes is in whitebox https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zuul.yaml#L109 so we didn't have to do it in the nova .zuul.yaml | |
| 18:33:41 | sean-k-mooney | and i dont see how we can do that without either 4 nodes | |
| 18:33:49 | sean-k-mooney | or reconfigurign the nova config | |
| 18:34:35 | sean-k-mooney | we used ot reconfigure the nova config in whitebox and still can durign test but we tried to move aways form that for stablity reasons | |
| 18:35:52 | melwitt | it currently works to test both modes so I'm not yet sure why we would need to change config but I'm sure i'm missing something | |
| 18:36:09 | melwitt | (the proposed patches not yet merged works with both modes) | |
| 18:36:30 | sean-k-mooney | ho do you knwo form one execution in a job where both deployment and host are allowed which the vm is using and how are you forcing that | |
| 18:36:47 | melwitt | or is your point that that would change since H was cut? | |
| 18:37:42 | sean-k-mooney | im saying we need to test with host mode (rpc copy) and with deployment mdoe secrest owned by nova) | |
| 18:38:02 | sean-k-mooney | and we need to ensure that one or the other is used durign the migrtion | |
| 18:38:14 | melwitt | there are currently separate tests for each mode and they both run in the same job, last I checked. I don't know if cutting the branch could have changed that | |
| 18:38:15 | sean-k-mooney | without lookign at somting like debug messages | |
| 18:38:56 | sean-k-mooney | oh they are forciign the mode via image properties | |
| 18:39:09 | sean-k-mooney | sorry flavor extra specs | |
| 18:39:12 | sean-k-mooney | not image proeprties | |
| 18:39:14 | melwitt | yeah you have to select the mode | |
| 18:39:18 | sean-k-mooney | right | |
| 18:39:20 | gmaan | I think we are mixing the deployment mode testing in current changes. I have not reviewed/thoguht about deployment mode yet as those are not merged but host/user worked fine in existing tests/job | |
| 18:39:57 | sean-k-mooney | gmaan: no i forgot that we can expicty set the mode in teh falvor | |
| 18:40:10 | gmaan | ohk | |
| 18:40:17 | sean-k-mooney | gmaan: we talked about haveing default per hsot and listing what each host can allow ectra in teh config | |
| 18:40:20 | melwitt | 'user' currently is just verifying it's still blocked in the API but we were chatting about enabling live migration for 'user' if the API policy or secret ACLs would otherwise allow it | |
| 18:40:37 | sean-k-mooney | and i was tryign to understand how a host that allows all 3 was tested spertaly with all 3 | |
| 18:40:44 | melwitt | yeah, that got changed during spec review. no more choice on the default, 'user' is the only default | |
| 18:41:06 | sean-k-mooney | right this is one of the thing that evovled | |
| 18:41:21 | sean-k-mooney | and in the last ptg we entirlly remvoed the image options | |
| 18:41:32 | melwitt | right | |
| 18:41:35 | sean-k-mooney | becasue fo the resize isssues | |
| 18:41:50 | sean-k-mooney | feels weeried that we chose the make it simpler option | |
| 18:41:54 | sean-k-mooney | we shoudl do that more | |
| 18:42:01 | melwitt | because rebuild is not implemented, so we didn't want to create a path where the user gets stuck with a mode and can't change it | |
| 18:43:17 | sean-k-mooney | so i have been ocationally suggeting to james that we look at runign more of whitebox in nova-next this cycle | |
| 18:43:18 | melwitt | if your image properties are locked-in (bc you can't rebuild), you will have a flavor/image conflict for resizes | |
| 18:43:33 | sean-k-mooney | melwitt: yep i just had paged out that converstion | |
| 18:44:02 | sean-k-mooney | ok after reviewign the whitebox code as well im ok with moving forward with this job for now | |
| 18:44:08 | melwitt | yeah. it's been a long and complicated journey | |
| 18:44:35 | sean-k-mooney | melwitt: before we add new test i woudl like to change the whitebox cofnig slightly so we list which polices are enabeld | |
| 18:44:45 | sean-k-mooney | i think | |
| 18:44:54 | melwitt | ok. yeah I was just thinking we merged all the tests and etc but no job running them so I figured maybe we want to go with that for now and then whatever happens this cycle I can adapt it | |
| 18:44:55 | sean-k-mooney | and skip the relevent tests | |
| 18:45:11 | sean-k-mooney | no its just user and host form what i saw | |
| 18:45:58 | sean-k-mooney | when we add deployment without another way to know if it shoudl work it will block the 2026.1 branch | |
| 18:46:00 | melwitt | right. and user is kind of a negative test, it just verifies that requests are rejected | |
| 18:46:11 | sean-k-mooney | well i guess it wont but only because this job is not there | |
| 18:46:30 | sean-k-mooney | but i assume we woudl liek to backport this job? | |
| 18:46:37 | sean-k-mooney | to have coverage | |
| 18:46:48 | melwitt | I have not heard anyone suggest that yet | |
| 18:47:20 | melwitt | we have coverage by way of whitebox which IIRC runs as a periodic | |
| 18:47:20 | sean-k-mooney | i mean its not hard to do and the test coverage would be valuabel but its not strictly requried | |
| 18:47:33 | melwitt | this latest thing we are making it sort of an official nova thing I guess | |
| 18:48:11 | sean-k-mooney | yes in the weekly perdic job | |
| 18:48:24 | sean-k-mooney | but i dont think whitebox-devstack-multinode | |
| 18:48:28 | sean-k-mooney | currently runs this test | |
| 18:49:06 | melwitt | oh you mean since we missed the window in G. yeah that's true | |
| 18:49:41 | sean-k-mooney | unless i missunderstood | |
| 18:49:42 | melwitt | so yeah I guess we need to backport it. | |
| 18:49:53 | sean-k-mooney | the host policy did merge before feature freeze adn is in 2026.1 right | |
| 18:49:57 | melwitt | no you're right. I've just been brain fried | |
| 18:49:59 | melwitt | yes | |
| 18:50:06 | sean-k-mooney | ok cool. | |
| 18:50:27 | sean-k-mooney | we could do this slightly diffently. | |
| 18:50:53 | sean-k-mooney | we coudl move whitebox-devstack-multinode to check | |
| 18:51:08 | sean-k-mooney | and update whitebox-devstack-multinode to run the vtpm test by default | |
| 18:51:31 | sean-k-mooney | that woudl give us a weekly perodic on 2026.1 i think | |
| 18:51:59 | sean-k-mooney | that getting to complciated | |
| 18:53:50 | gmaan | tests are present in 2026.1 so yes job needs to be backported | |