| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-10-14 | |||
| 13:35:49 | tkajinam | that's a single one, sorry | |
| 13:35:54 | gibi | :) | |
| 13:36:04 | tkajinam | I'm just going through patches appearing in my patches as conflicts | |
| 13:36:21 | tkajinam | that's a not big win but a easy small step | |
| 13:36:52 | gibi | I abandoned the snp series from your colleague the other day | |
| 13:36:57 | gibi | as we landed yours | |
| 13:37:02 | tkajinam | gibi, yeah I saw that. thanks | |
| 13:37:10 | gibi | that was at least 5 patches to get rid off | |
| 13:37:28 | tkajinam | by the way I noticed we didn't discuss if nova-reviewers (or whatever it is named) should have right to abandon changes or -2. -2 might be too powerful but I personally feel like having more people to sweep the queue may be helpful | |
| 13:38:25 | tkajinam | gibi, let's go into lfx insight to find how we get "number of reviews closed by the person" | |
| 13:38:44 | tkajinam | and abandon 1000 reviews before you bring that stat number to your mgmt :-P | |
| 13:39:01 | gmaan | Uggla: I might be away from 15 - 15.15 UTC ish to drop kids to school. I think cross cell migration and graceful shutdown is schedules after that 15 UTC? | |
| 13:39:46 | gibi | tkajinam: I'm totally OK for nova-reviewers to got abadon rights. | |
| 13:39:50 | gibi | to get | |
| 13:40:19 | tkajinam | :-) | |
| 13:40:21 | gibi | -2 is something that needs a dicussion for sure | |
| 13:40:43 | gibi | I think -2 is sticky across patchsets so yeah that might be too much | |
| 13:41:05 | Uggla | gmaan true for graceful. But x cell LM is starting at 15UTC | |
| 13:41:10 | tkajinam | gmaan, 1500-1600UTC : Cross-cell live migration | |
| 13:41:20 | tkajinam | gmaan, 1700-1800UTC : Nova graceful shutdown part-3: operations self-termination point | |
| 13:41:36 | gmaan | yeah, i will be away for about 15 min for the cross-cell one | |
| 13:41:39 | tkajinam | (just copy-pasting agenda lines) | |
| 13:42:33 | gmaan | gibi: as you are here, or maybe dansmith or elodilles knows, do you know why nova-tox-validate-backport is non voting in check pipeline and voting in gate pipeline? catching invalid backport in check pipeline is worth right? | |
| 13:43:20 | gibi | I do remember it was intentional but I cannot come up with a why | |
| 13:43:30 | gibi | I think we need elodilles' memories | |
| 13:43:31 | dansmith | gmaan: I think it might be because we wanted to be able to line up backports before master merged without having to recheck them again after master merged, but still prevent them landing out of order | |
| 13:43:47 | gibi | ohh that sounds reasonable | |
| 13:43:50 | gibi | one less recheck | |
| 13:44:02 | dansmith | right, else we'd sort of serialize the whole thing | |
| 13:44:02 | gmaan | ohk, yeah, prevent recheck is good reason | |
| 13:45:34 | gmaan | let me add it reason in zuul file. i was wondering why we made it like this. thanks | |
| 13:53:29 | gibi | thanks gmaan for documenting it | |
| 14:01:18 | sean-k-mooney[m] | gmaan: its very intentional that its non-voting n check | |
| 14:01:52 | sean-k-mooney[m] | and yes we anted it to not make the job red when we were proposing the backports | |
| 14:02:06 | sean-k-mooney[m] | to avoid having to do a recheck alwasy | |
| 14:02:18 | gmaan | yeah | |
| 14:02:39 | Leo[m] | Hello, my PTG topic "Support for Hostname-based Ceph Mon References" is scheduled for now. Is this the right chat for Nova PTG discussions? Thank you | |
| 14:03:00 | dansmith | Leo[m]: https://meetpad.opendev.org/nova-2027.1-ptg | |
| 14:03:57 | dansmith | Leo[m]: we reordered you after another session since you weren't on, so just hold up for a bit and you'll be next | |
| 14:05:00 | Leo[m] | Ok, thank you | |
| 14:19:32 | dansmith | abhishekk: we have a question for you about image trusted certificate verification, maybe we can circle back to it when you're in the nova room later | |
| 14:35:23 | abhishekk | dansmith: ack, you can post the question now as well | |
| 16:32:58 | gibi | Uggla: gmaan: heads up at some point between 17:00-18:00 UTC, which is potentially in the graceful shutdown discussion, I have to switch to mobile and that will put me in a more listening mode than speaking mode. | |
| 16:33:38 | Uggla | gibi: ok thanks to let us know | |
| 16:35:29 | Uggla | tkajinam, you have good taste in music! ;) | |
| 16:36:08 | tkajinam | ;-) | |
| 17:52:58 | dansmith | Uggla: you're not locally recording the nova sessions are you? | |
| 17:59:41 | gmaan | added the notes in 'AGREE' section https://etherpad.opendev.org/p/nova-2027.1-ptg#L670 | |
| 17:59:50 | Uggla | dansmith, no record. | |
| 18:00:39 | dansmith | Uggla: ack, figured.. we had at least two cores not able to attend sessions this week or for part so just wondering.. that's one down side to meetpad for this stuff | |
| 18:04:20 | elodilles | gmaan: sorry, missed your ping. but dansmith and sean-k-mooney[m] answered your question o:) (this was the patch that introduced and explained the non-voting+voting setup -> https://review.opendev.org/c/openstack/nova/+/796626 ) | |
| 18:13:17 | gmaan | elodilles: yeah, thanks | |
| 18:15:02 | gmaan | no notification about new change here. eems opendevreview bot not working? | |
| 18:15:19 | gmaan | dansmith: gibi but i added note about backport validation job in this https://review.opendev.org/c/openstack/nova/+/1010507 | |
| 18:15:24 | opendevreview | Ghanshyam Maan proposed openstack/nova master: [Trivial] Add a notes for nova-tox-validate-backport being non-voting in check https://review.opendev.org/c/openstack/nova/+/1010507 | |
| 18:15:33 | gmaan | oh, late but working :) | |
| 18:17:35 | dansmith | gmaan: I stephenfin'd it .. he would be very proud :) | |
| 18:18:27 | gmaan | thanks :) | |
| 22:07:18 | opendevreview | Merged openstack/nova master: [Trivial] Add a notes for nova-tox-validate-backport being non-voting in check https://review.opendev.org/c/openstack/nova/+/1010507 | |
| #openstack-nova - 2026-10-15 | |||
| 01:49:56 | opendevreview | Merged openstack/nova master: revert: remove populate_missing_availability_zones https://review.opendev.org/c/openstack/nova/+/971894 | |
| 07:34:09 | opendevreview | Abhishek Kekane proposed openstack/nova-specs master: Add Download glance images using temporary URLs https://review.opendev.org/c/openstack/nova-specs/+/1010607 | |
| 09:40:12 | opendevreview | Nathan Harper proposed openstack/nova master: nova-compute-ironic: Handle absent network metadata during config-drive creation https://review.opendev.org/c/openstack/nova/+/1010626 | |
| 12:06:58 | tkajinam | I wonder if we have a good mechanism now to report "max limit" defined per compute nodes ? | |
| 12:08:06 | tkajinam | I mean ... if I want to control "maximum vcpu cores per instance on that specific host", is there any good scheme I can use to reflect that in placement ? I initially thought that might be trait but I don't think trait reflects quantity part | |
| 12:20:54 | sean-k-mooney | not realy | |
| 12:21:02 | sean-k-mooney | well | |
| 12:21:16 | sean-k-mooney | you can use provider.yaml i belive | |
| 12:21:28 | sean-k-mooney | traits are not corrct | |
| 12:21:45 | sean-k-mooney | so in placement you can set min_unit and max_unit in the invetory | |
| 12:22:08 | sean-k-mooney | those defautl to 1 and total inventory count by default | |
| 12:22:26 | sean-k-mooney | and contol the size of an allocation against that inventory | |
| 12:22:50 | sean-k-mooney | so you can techniall set the min_unit and max_unit in the vcpu invetory | |
| 12:22:59 | sean-k-mooney | and then placement will enforce that for you | |
| 12:23:08 | sean-k-mooney | and i think provider.yaml is able to do that | |
| 12:23:15 | sean-k-mooney | its just a littel obscure | |
| 12:24:50 | sean-k-mooney | you can definetly do that vai the placement api for what its worth | |
| 12:25:37 | sean-k-mooney | each inventory also has step_size | |
| 12:25:53 | tkajinam | hmmm | |
| 12:26:05 | sean-k-mooney | so you can for example say this host can only have vms with between 2 an 8 cpus in multiples of 2 | |
| 12:26:09 | tkajinam | sean-k-mooney, the question is related to the virtio-net queue spec | |
| 12:26:39 | tkajinam | sean-k-mooney, in that spec maximum virtio-net queue acceptable in a specific compute node is determined by [libvirt] max_queues in nova.conf there | |
| 12:26:55 | sean-k-mooney | one sec im going to swap client brb | |
| 12:26:57 | tkajinam | I was wondering if there is a good way to report that in placement and ignore anything below the requested number | |
| 12:27:05 | tkajinam | sean-k-mooney, sure | |
| 12:27:35 | tkajinam | (and I thought there may not be a good mechanism for it, but dropped that question here just in case I'm not aware of something nice available | |
| 12:28:07 | opendevreview | Matt Crees proposed openstack/nova master: Add test_update_devices_preserves_vf_network_caps https://review.opendev.org/c/openstack/nova/+/989121 | |
| 12:28:11 | opendevreview | Matt Crees proposed openstack/nova master: Don't drop pci_dev network caps when VF is in use https://review.opendev.org/c/openstack/nova/+/982660 | |
| 12:28:11 | sean-k-mooney[m] | ok im borrowing stephens desk so i disturbe emma less while on the ptg sessions | |
| 12:28:39 | sean-k-mooney[m] | so no not currently | |
| 12:28:45 | sean-k-mooney[m] | what i woudl look at | |
| 12:29:06 | sean-k-mooney[m] | is how we did it for the number of adress bits | |
| 12:29:42 | sean-k-mooney[m] | we reprot the maxium number of adress space bits a host supprot | |
| 12:29:58 | sean-k-mooney[m] | but not to placement instead we reprot it as a compute capablity | |
| 12:30:08 | sean-k-mooney[m] | and use the comptue capablity filter to enfoce it | |
| 12:30:34 | tkajinam | ah ok | |
| 12:30:57 | tkajinam | ah yeah I found that | |
| 12:31:06 | sean-k-mooney[m] | https://github.com/openstack/nova/commit/1038a633870b24b2409205cc3c5fe066442dd49f | |
| 12:31:42 | sean-k-mooney[m] | that is the best example we have of scheduling on a numeric value that is not consumed | |
| 12:31:56 | sean-k-mooney[m] | i.e. where we do not need to decremnt that totale or create allcoations | |
| 12:32:04 | tkajinam | that's a good solution so far, though we may want something within placement in long term. | |