| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-14 | |||
| 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. | |
| 16:52:04 | bauzas | ++ | |
| 16:53:18 | bauzas | okay, I guess it's time for closing the meeting | |
| 16:53:21 | bauzas | anything anyone ? | |
| 16:53:50 | tkajinam | I have one but I can first discuss it with a few people after the meeting is finished. | |
| 16:54:30 | bauzas | cool | |
| 16:54:33 | tkajinam | and bring it again to the meeting next week if needed | |
| 16:54:40 | bauzas | ++ then, thanks all | |
| 16:54:44 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.log.html | |
| 16:54:44 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.txt | |
| 16:54:44 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.html | |
| 16:54:44 | opendevmeet | Meeting ended Tue Jan 14 16:54:44 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:54:44 | bauzas | #endmeeting | |
| 16:55:28 | elodilles | thanks o/ | |
| 16:56:03 | masahito | thank you. bye o/ | |
| 16:56:33 | tkajinam | sean-k-mooney, I wonder if you think https://review.opendev.org/c/openstack/nova-specs/+/932653 can be specless or we should keep the full workflow for it. | |
| 16:56:58 | sean-k-mooney | there are no api changes | |
| 16:57:13 | sean-k-mooney | so it could be specless in theory | |
| 16:57:16 | tkajinam | yeah | |
| 16:57:32 | sean-k-mooney | i would not be opposed to that | |
| 16:57:49 | tkajinam | ok | |
| 16:57:49 | sean-k-mooney | tkajinam: it woudl stil need a spec freeze excption either way | |
| 16:57:59 | sean-k-mooney | the blueprint approval dealine was also last week | |
| 16:58:04 | tkajinam | ahh, ok | |
| 16:58:25 | sean-k-mooney | bauzas: ^ i dont know how you feel about that | |
| 16:58:57 | sean-k-mooney | burst qos limtis have been supproted in libvirt sin 2.4.0 baically forever | |
| 16:59:15 | sean-k-mooney | nova just does not hook them up if they are present on a cidner volume | |
| 16:59:22 | tkajinam | the author asked me the way forward several times privately and I was wondering switching it to specless makes it easy to move the proposal forward | |
| 16:59:28 | sean-k-mooney | so to me this is a small libvirt driver feature | |
| 16:59:56 | tkajinam | yeah. what we basically need is to pick up a few additional spec keys and put these into additional iotune parameters in domain xml | |
| 17:00:09 | sean-k-mooney | tkajinam: well the main issue is they did not respone publicly for like 2 month and we didnt get feedback form cidner | |
| 17:00:16 | bauzas | tkajinam: would you be able to write a small description in the blueprint ? | |
| 17:00:40 | tkajinam | sean-k-mooney, yeah. | |
| 17:00:42 | bauzas | once we have that, then we could look whether it's specless and then accepting it as an exception if we really want | |
| 17:00:57 | tkajinam | bauzas, yeah I can or I can ask MengyangZhang[m] to do so. | |
| 17:01:09 | bauzas | would be nice | |
| 17:01:37 | tkajinam | ok so I'd ask MengyangZhang[m] to add quick description and probably propose actual change, and then we can make the decision in upcoming weeks | |
| 17:01:49 | tkajinam | based on these | |
| 17:03:45 | bauzas | yeah, that'd be nice | |
| 17:03:57 | bauzas | I don't want to rush them, but the sooner the better | |
| 17:04:05 | dansmith | sean-k-mooney: melwitt: kinda surprised to see this merge with not a line of test coverage: https://review.opendev.org/c/openstack/nova/+/932669 | |
| 17:04:25 | dansmith | especially since it looks like it's getting backported all the way | |