| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-14 | |||
| 16:08:03 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:08:10 | bauzas | #info Please try to provide meaningful comment when you recheck | |
| 16:08:46 | opendevreview | Lajos Katona proposed openstack/nova master: blueprint: iothreads-for-instances https://review.opendev.org/c/openstack/nova/+/939254 | |
| 16:09:54 | bauzas | periodic jobs are all green | |
| 16:10:01 | bauzas | any gate failure to report ? | |
| 16:12:19 | bauzas | okay moving on | |
| 16:14:02 | bauzas | #topic Release Planning | |
| 16:14:09 | bauzas | #link https://releases.openstack.org/epoxy/schedule.html | |
| 16:14:16 | bauzas | #info Nova deadlines are set in the above schedule | |
| 16:14:53 | bauzas | #info 6 weeks before Feature Freeze | |
| 16:14:59 | bauzas | #info we'll try to create as os-traits release by the next 2 weeks, please provide your os-traits patches sooner than later. | |
| 16:15:02 | bauzas | you know this | |
| 16:16:09 | bauzas | #topic Review priorities | |
| 16:16:16 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | |
| 16:16:29 | bauzas | #action bauzas to update the etherpad with the latest changes | |
| 16:16:40 | bauzas | masahito: you had an itemù | |
| 16:16:52 | masahito | Thanks. | |
| 16:17:09 | masahito | I added two bugs in the bottom of the etherpad page. | |
| 16:17:29 | masahito | https://bugs.launchpad.net/nova/+bug/2075100 and https://bugs.launchpad.net/nova/+bug/2085709 | |
| 16:17:48 | masahito | The second one is a bug patch I mentioned before. | |
| 16:17:53 | gibi | masahito: I'm wondering if you problem is related to https://review.opendev.org/c/openstack/nova/+/932669 that fixed a freeze | |
| 16:18:42 | masahito | gibi: thanks, let me check. I didn't notice the patch. | |
| 16:20:05 | masahito | It looks like C or later release has the problem that long running thread blocks other thread operation because of libvirt connection. | |
| 16:21:53 | bauzas | masahito: okay, that's good that you added both fixes, we'll try to review them | |
| 16:23:03 | bauzas | can we move on ? | |
| 16:23:29 | masahito | I'm ok, thank you. | |
| 16:25:07 | bauzas | ack | |
| 16:25:15 | bauzas | #topic Stable Branches | |
| 16:25:24 | bauzas | elodilles: do you have anything ? | |
| 16:25:29 | elodilles | #info nothing to report, stable gates seem to be healthy | |
| 16:25:43 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:25:53 | elodilles | that's all from me | |
| 16:26:38 | bauzas | cool | |
| 16:27:45 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:27:54 | fwiesel | No updates from my side | |
| 16:27:54 | bauzas | fwiesel: anything on your side ? | |
| 16:27:56 | bauzas | cool | |
| 16:28:03 | bauzas | #topic Open discussion | |
| 16:30:06 | bauzas | nothing on the agenda, anything else ? | |
| 16:30:10 | masahito | If time is allowed, I want to hear your opinion for this spec, too https://review.opendev.org/c/openstack/nova-specs/+/937587 | |
| 16:30:50 | masahito | According to the gibi's comment, it's a bug not a new feature. We're wondering the spec approval is needed or not. | |
| 16:32:40 | bauzas | unfortunately, we're post spec approval deadline | |
| 16:34:15 | bauzas | hmmmm | |
| 16:34:19 | masahito | yes, that's why I asked the question. If it's a bug, we can push bug fix for the problem, IIUC. But it's defined as a new feature, we'll wait the next development cycle. | |
| 16:34:23 | bauzas | I don't have that context in mind | |
| 16:34:58 | bauzas | sean-k-mooney: about https://review.opendev.org/c/openstack/nova-specs/+/937587/2/specs/2025.1/approved/add-mutual-prefix.rst, do you think like gibi that's just a placement bug ? | |
| 16:35:14 | gibi | not a placement one but a nova one :) | |
| 16:35:47 | bauzas | because that's nova which knows that, I see | |
| 16:35:49 | bauzas | you're right | |
| 16:36:30 | bauzas | so we should do something like set(new_traits) - set(existing_traits) to calculate the ones that should be deleted | |
| 16:36:47 | bauzas | and if we don't do that for custom traits, I agree with you that's a bug | |
| 16:37:02 | bauzas | because operators expect to only get custom traits that they pass | |
| 16:37:08 | gibi | it is more like nova always generates the list of expected traits internally for the RP and then it just need to sync it with placement to overwrite what is there | |
| 16:38:01 | gibi | I think nova never allowed outside users to add traits to RPs that is owned by nova, I expect that nova overwrites the extra traits during the periodic. | |
| 16:38:24 | gibi | for some reason from the spec text it seem it is not the case for the traits from the provider.yaml | |
| 16:38:29 | sean-k-mooney | reading back | |
| 16:38:35 | gibi | so when those removed from the .yaml they are not removed from the RP | |
| 16:38:55 | gibi | I did not looked at the code to get a better picture | |
| 16:39:06 | sean-k-mooney | ah we dont clean them up | |
| 16:39:10 | bauzas | yes | |
| 16:39:16 | sean-k-mooney | i guess tha tmakes sense becuase we dont know who added them | |
| 16:39:27 | bauzas | and the question is : is that behavior expected or not ? (to not clean them up) | |
| 16:39:31 | masahito | yes, current behavior is one way, only adding a listed trait to the RP. | |
| 16:39:58 | sean-k-mooney | it could be exetned to do clean up but that more a new feature then a bug | |
| 16:40:17 | sean-k-mooney | i think we just left it out of scope | |
| 16:40:23 | sean-k-mooney | for the inital spec | |
| 16:40:29 | gibi | sean-k-mooney: but I expect nove to only overwrite any traits on the RP with its own list | |
| 16:40:30 | sean-k-mooney | im not sure wha tthe best way to do that owuld be | |
| 16:40:54 | gibi | do not try to mix and match traits from the RP and from it internal state | |
| 16:40:57 | sean-k-mooney | well no we supprot people usign the placment api to add traits to an rp | |
| 16:41:25 | bauzas | we have two possibilities here | |
| 16:41:29 | sean-k-mooney | so nova cant nessiarly remove custom traits | |
| 16:41:35 | gibi | then why we have provider.yamls? I assumed that provider.yamls was needed in the first place to make the trait addition work | |
| 16:41:36 | sean-k-mooney | it can remove standard traits | |
| 16:41:54 | bauzas | either we say this sounds something we need to design, and then it will be discussed for F | |
| 16:41:57 | sean-k-mooney | no it was needed ot have a declaritive way to do that | |
| 16:42:19 | sean-k-mooney | i think this need more discussion then we have time for in this meeting | |
| 16:42:22 | bauzas | or we say that the expected behavior is understood and then that series is just bugfix | |
| 16:42:47 | bauzas | if so, sounds to me a design discussion which resolves to => move to F | |
| 16:43:04 | sean-k-mooney | my perspecitive is that CUSTOM traits cna be added/remove via the api or declaritivly, standard triaits are managed by the virt driver | |
| 16:43:25 | sean-k-mooney | so the fact the custom trait is not removed is expected based on that view point | |
| 16:43:56 | sean-k-mooney | however i agree we coudl recored which traits came form the provider.yaml in some form and enable nova to clean them up | |
| 16:44:06 | sean-k-mooney | that woudl be a new functionaltiy however not a bug | |
| 16:45:50 | sean-k-mooney | im not sold on the idea of teh mutal_prefix propsoed in the current spec | |
| 16:46:45 | sean-k-mooney | its an approch but im not sure its the best approch | |
| 16:47:10 | bauzas | then, as said, we're post spec freeze, this would be discussed on the Foxtrot PTG | |
| 16:47:49 | gibi | *Flamingo | |
| 16:47:55 | bauzas | I know | |
| 16:47:57 | gibi | ;] | |
| 16:48:04 | masahito | :) | |
| 16:48:48 | bauzas | anyway, I guess we unfortunately need to move that spec to that cycle | |
| 16:48:54 | masahito | I see the conclusion. Looks like lots of approach and design discussion are there. | |
| 16:49:27 | bauzas | masahito: are you OK with that ? this doesn't mean we couldn't discuss that before Flamingo (meh) but we will only accept it when it's there | |
| 16:50:29 | masahito | yup. One question is any extra discussion on the spec is also blocked by the F release PTG? | |
| 16:50:40 | sean-k-mooney | no | |
| 16:50:45 | sean-k-mooney | we can continue ot disucss | |
| 16:50:53 | masahito | Got it. | |
| 16:50:54 | sean-k-mooney | jus tmove the spec file to the correct release folder | |
| 16:51:47 | bauzas | thanks masahito for understanding | |
| 16:51:52 | masahito | I see there is two approach is there for the provider.yaml behavior in the meeting. We;ll update the spec including the topic. | |