Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-01-14
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 bauzas fwiesel: anything on your side ?
16:27:54 fwiesel No updates from my 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.
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

Earlier   Later