Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-10-14
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
12:42:12 sean-k-mooney[m] there is a spec related to iothread and block device multi queue
12:42:32 sean-k-mooney[m] and then i think one for contoling the count of quee allcoated to neutorn interfaces
12:43:39 sean-k-mooney[m] i know for the nic one i was also suggesting that while the flavor/image is ok it might be better to have a neutron port exstions or port hint to allow you to request a prefered number of queues per interface
12:45:33 tkajinam sean-k-mooney[m], yeah I saw that and that sounds a good idea. but they want their admin to enforce the limit so port extra spec may not work for that use case.
12:46:35 tkajinam want their admin to enforce the limit *per tenant-basis*
12:46:58 tkajinam we likely discuss the same detail later :-)
12:50:23 tkajinam sean-k-mooney[m], I assume you'd join the watcher sessions today, right ?
14:01:08 opendevreview Merged openstack/nova master: Add info log when destination hypervisor is too old https://review.opendev.org/c/openstack/nova/+/907972
14:09:49 sean-k-mooney[m] yes but i will be joining for the pci grouping topic
14:09:59 sean-k-mooney[m] i can join specific sessions if needed
14:10:40 sean-k-mooney[m] if you eanted per port admin enfoced limest i woudl propse it as a qos policy or simialr on the neutron side
14:10:50 sean-k-mooney[m] i.e. some admin created policy
14:10:58 sean-k-mooney[m] that users coudl select but ya the falvor also works

Earlier   Later