| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-10-14 | |||
| 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. | |
| 12:32:11 | tkajinam | we got the 2nd example where we need this | |
| 12:32:24 | sean-k-mooney[m] | im sure there are others | |
| 12:32:50 | sean-k-mooney[m] | we discuss modeling this in placement with invetoies of max int or infinity inventories | |
| 12:33:30 | sean-k-mooney[m] | in practice eigher woudl work and could reuse min_unit, max_unit and step_size | |
| 12:33:45 | sean-k-mooney[m] | but placment invetories are for countble things | |
| 12:33:54 | tkajinam | yeah that's the proble | |
| 12:33:57 | sean-k-mooney[m] | not for configuration or state | |
| 12:34:00 | tkajinam | and traits are non-countable | |
| 12:34:18 | tkajinam | we want something countable but non-consumable | |
| 12:34:30 | sean-k-mooney[m] | honestly that would not be a terrible evolution fo the placement api in my view | |
| 12:34:38 | tkajinam | yeah | |
| 12:34:38 | sean-k-mooney[m] | or our usage of it | |
| 12:35:00 | tkajinam | and would be more efficient because you can do local filtering within placement db | |
| 12:35:03 | sean-k-mooney[m] | but im not sure it gets use much beyond what we can already do in the compute capabliteis filter | |
| 12:35:30 | sean-k-mooney[m] | i woudl update the multi queue spec to follow the max_adresspace design for this | |
| 12:35:48 | sean-k-mooney[m] | but we could evaulate what to do in the future in a more native way | |
| 12:35:58 | tkajinam | yes I left such comment there, because the current proposal is saying they let instance creation fail and put it to rescheduling | |
| 12:36:22 | tkajinam | IMHO we should filter non-suitable compute nodes instead of trying to use it and fail | |
| 12:36:23 | sean-k-mooney[m] | ya which is not great | |
| 12:37:23 | sean-k-mooney[m] | we could have a trait COMPUTE_NIC_MULTIQUEUE_COUNT | |
| 12:37:45 | sean-k-mooney[m] | to advertise that a host supprot that funcitonalty but encodeing the amount in the trait | |
| 12:37:59 | sean-k-mooney[m] | woudl be even less correct then a max int invetory in my view | |
| 12:38:14 | tkajinam | yeah I agree | |
| 12:41:05 | sean-k-mooney[m] | ill try and find some more time to loop back to that spec in the next week or so. | |