Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-01-14
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 bauzas #endmeeting
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 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.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 Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.log.html
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 sean-k-mooney tkajinam: it woudl stil need a spec freeze excption either way
16:57:49 tkajinam ok
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
17:04:39 tkajinam bauzas, yeah. we don't have very long time left for this cycle so we may need timely update to get that in for E
17:04:47 dansmith especially given the backports, seems like coverage would be good no?
17:04:54 tkajinam bauzas sean-k-mooney, thank you, both !
17:04:55 sean-k-mooney dansmith: i guess that a good point i was not really sure how to assert it was a proxy object
17:05:12 sean-k-mooney dansmith: i wasnt sure that an issubclass check woudl work but perhasp it could
17:05:26 sean-k-mooney dansmith: do you know if we have any test coverage to that effect?
17:05:39 dansmith sean-k-mooney: I think this is not special in that regard
17:06:19 dansmith I mean mocking the wrap method and asserting it was called would be something at least
17:06:41 sean-k-mooney oh mocking _wrap_libvirt_proxy
17:06:48 sean-k-mooney ya that could also work
17:06:53 bauzas sean-k-mooney: we have some example https://review.opendev.org/c/openstack/nova/+/677736/5/nova/tests/unit/virt/libvirt/test_host.py
17:06:59 bauzas or a Mock
17:07:11 bauzas anyway, sounds to me achievable
17:07:12 sean-k-mooney melwitt: ^ is that something you can do a follow up for
17:07:25 bauzas not testing the threads themselves

Earlier   Later