| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-14 | |||
| 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 | |
| 17:07:26 | dansmith | well, follow up won't get into the backport | |
| 17:07:34 | sean-k-mooney | dansmith: your right that it proably shoudl have been included in the initall patch | |
| 17:07:48 | dansmith | might be cleaner to revert and re-do it with tests... we could backport tests, but it's messy-er | |
| 17:08:07 | sean-k-mooney | the first backport does not look like it has merged yet | |
| 17:08:11 | sean-k-mooney | so that still an option | |
| 17:09:57 | sean-k-mooney | i guess the refence patch that mel refers to has some examples we can reuse https://review.opendev.org/c/openstack/nova/+/677736/5/nova/tests/unit/virt/libvirt/test_host.py | |
| 17:11:01 | dansmith | sean-k-mooney: so will you propose a revert on master? | |
| 17:11:06 | sean-k-mooney | its kind of a wackamole probelem, it would be nice if we had some way to poison the module in test so that it could not return non wapped obejcts | |
| 17:11:16 | sean-k-mooney | dansmith: sure i can | |
| 17:11:26 | dansmith | thanks | |
| 17:11:36 | dansmith | I'll stand by to fast approve :) | |
| 17:12:02 | opendevreview | sean mooney proposed openstack/nova master: Revert "libvirt: Wrap un-proxied listDevices() and listAllDevices()" https://review.opendev.org/c/openstack/nova/+/939262 | |
| 17:12:42 | opendevreview | sean mooney proposed openstack/nova master: Revert "libvirt: Wrap un-proxied listDevices() and listAllDevices()" https://review.opendev.org/c/openstack/nova/+/939262 | |
| 17:12:50 | sean-k-mooney | just fixed a typo in the commit | |