| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-10-14 | |||
| 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. | |
| 12:41:34 | sean-k-mooney[m] | is it curently just focusing on the nic storage or both | |
| 12:41:46 | sean-k-mooney[m] | i feel like we curely have 2 diffent spec one for each right | |
| 12:41:50 | sean-k-mooney[m] | or am i miss remembering | |