| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-14 | |||
| 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 | |
| 17:13:08 | opendevreview | ribaudr proposed openstack/os-traits master: Add 'HW_PCI_LIVE_MIGRATABLE' https://review.opendev.org/c/openstack/os-traits/+/939264 | |
| 17:17:53 | sean-k-mooney | dansmith: thinking about it, i guess the tpool.proxy is a "contains" or "has a" relationship rahter then an inheritance so self.assertIsInstance() works in that case. so that makes sense | |
| 17:18:38 | sean-k-mooney | we are not just replacing the metacass or simairl on teh orginl object, its fully wrapping it | |
| 19:52:37 | melwitt | sean-k-mooney: sorry about that. I'm not sure why I thought tpool proxy stuff in general wasn't covered in unit tests. I see now that there is, so I'll add to that area with the reproposal | |
| 19:56:16 | sean-k-mooney | melwitt: it was dansmith that noticed, i didnt think we had testign that the returned obejcts were proxies either | |
| 19:57:06 | dansmith | maybe it's just me, but any patch that touches production code and doesn't touch anything in the test tree at all should probably be a red flag, and at least have a note in the commit message about why it's not tested | |
| 19:58:50 | sean-k-mooney | ocationally its a pure refactor with no observable change, that how i was looking at this but that was not actully ture in this case | |
| 19:59:02 | sean-k-mooney | we can observe that the objects are wrapped | |
| 20:00:08 | melwitt | it was originally a test patch that I uploaded for someone to run experiments while I was debugging a downstream incident and then time passed and then for some reason I didn't find the existing test coverage. I thought it was something we don't test in general, but obviously I had missed it | |
| 20:01:50 | dansmith | sean-k-mooney: sure a refactor is a good reason to have no test coverage showing the refactor has no impact.. but this was not that :) | |
| 20:03:37 | sean-k-mooney | does anyone maintian storyboard or freezer anymore? | |
| 20:03:44 | sean-k-mooney | i assume no | |
| 20:07:44 | melwitt | dunno anything about freezer but afaik storyboard is no longer being developed | |
| 20:08:25 | sean-k-mooney | so there is an eventlet isseu with watcher im trying to debug | |
| 20:08:47 | sean-k-mooney | but very few projects use the apschduler lib | |
| 20:08:48 | JayF | sean-k-mooney: obligatory: have you ensured the new eventlet+oslo.log releases don't fix it? | |
| 20:08:57 | sean-k-mooney | and sofar i dont think they use eventlet | |
| 20:09:07 | sean-k-mooney | JayF: yep | |
| 20:09:18 | JayF | too bad :( | |
| 20:09:42 | sean-k-mooney | im tryign to confirm if wathcer is the only project that uses that lib and eventlet | |
| 20:10:09 | sean-k-mooney | zuul ueses apscheduler for example but i dotn thinik it uses eventlet | |