| opendevreview | Merged openstack/nova master: revert: remove populate_missing_availability_zones https://review.opendev.org/c/openstack/nova/+/971894 | 01:49 |
|---|---|---|
| opendevreview | Abhishek Kekane proposed openstack/nova-specs master: Add Download glance images using temporary URLs https://review.opendev.org/c/openstack/nova-specs/+/1010607 | 07:34 |
| 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 | 09:40 |
| *** root is now known as Guest2750 | 11:23 | |
| tkajinam | I wonder if we have a good mechanism now to report "max limit" defined per compute nodes ? | 12: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:08 |
| sean-k-mooney | not realy | 12:20 |
| sean-k-mooney | well | 12:21 |
| sean-k-mooney | you can use provider.yaml i belive | 12:21 |
| sean-k-mooney | traits are not corrct | 12:21 |
| sean-k-mooney | so in placement you can set min_unit and max_unit in the invetory | 12:21 |
| sean-k-mooney | those defautl to 1 and total inventory count by default | 12:22 |
| sean-k-mooney | and contol the size of an allocation against that inventory | 12:22 |
| sean-k-mooney | so you can techniall set the min_unit and max_unit in the vcpu invetory | 12:22 |
| sean-k-mooney | and then placement will enforce that for you | 12:22 |
| sean-k-mooney | and i think provider.yaml is able to do that | 12:23 |
| sean-k-mooney | its just a littel obscure | 12:23 |
| sean-k-mooney | you can definetly do that vai the placement api for what its worth | 12:24 |
| sean-k-mooney | each inventory also has step_size | 12:25 |
| tkajinam | hmmm | 12:25 |
| 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 |
| tkajinam | sean-k-mooney, the question is related to the virtio-net queue spec | 12:26 |
| 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 |
| sean-k-mooney | one sec im going to swap client brb | 12:26 |
| tkajinam | I was wondering if there is a good way to report that in placement and ignore anything below the requested number | 12:26 |
| tkajinam | sean-k-mooney, sure | 12:27 |
| 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:27 |
| 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 |
| sean-k-mooney[m] | ok im borrowing stephens desk so i disturbe emma less while on the ptg sessions | 12:28 |
| 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 |
| sean-k-mooney[m] | so no not currently | 12:28 |
| sean-k-mooney[m] | what i woudl look at | 12:28 |
| sean-k-mooney[m] | is how we did it for the number of adress bits | 12:29 |
| sean-k-mooney[m] | we reprot the maxium number of adress space bits a host supprot | 12:29 |
| sean-k-mooney[m] | but not to placement instead we reprot it as a compute capablity | 12:29 |
| sean-k-mooney[m] | and use the comptue capablity filter to enfoce it | 12:30 |
| tkajinam | ah ok | 12:30 |
| tkajinam | ah yeah I found that | 12:30 |
| sean-k-mooney[m] | https://github.com/openstack/nova/commit/1038a633870b24b2409205cc3c5fe066442dd49f | 12:31 |
| sean-k-mooney[m] | that is the best example we have of scheduling on a numeric value that is not consumed | 12:31 |
| sean-k-mooney[m] | i.e. where we do not need to decremnt that totale or create allcoations | 12:31 |
| tkajinam | that's a good solution so far, though we may want something within placement in long term. | 12:32 |
| tkajinam | we got the 2nd example where we need this | 12:32 |
| sean-k-mooney[m] | im sure there are others | 12:32 |
| sean-k-mooney[m] | we discuss modeling this in placement with invetoies of max int or infinity inventories | 12:32 |
| sean-k-mooney[m] | in practice eigher woudl work and could reuse min_unit, max_unit and step_size | 12:33 |
| sean-k-mooney[m] | but placment invetories are for countble things | 12:33 |
| tkajinam | yeah that's the proble | 12:33 |
| sean-k-mooney[m] | not for configuration or state | 12:33 |
| tkajinam | and traits are non-countable | 12:34 |
| tkajinam | we want something countable but non-consumable | 12:34 |
| sean-k-mooney[m] | honestly that would not be a terrible evolution fo the placement api in my view | 12:34 |
| sean-k-mooney[m] | or our usage of it | 12:34 |
| tkajinam | yeah | 12:34 |
| tkajinam | and would be more efficient because you can do local filtering within placement db | 12:35 |
| 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 |
| sean-k-mooney[m] | i woudl update the multi queue spec to follow the max_adresspace design for this | 12:35 |
| sean-k-mooney[m] | but we could evaulate what to do in the future in a more native way | 12:35 |
| tkajinam | yes I left such comment there, because the current proposal is saying they let instance creation fail and put it to rescheduling | 12:35 |
| tkajinam | IMHO we should filter non-suitable compute nodes instead of trying to use it and fail | 12:36 |
| sean-k-mooney[m] | ya which is not great | 12:36 |
| sean-k-mooney[m] | we could have a trait COMPUTE_NIC_MULTIQUEUE_COUNT | 12:37 |
| sean-k-mooney[m] | to advertise that a host supprot that funcitonalty but encodeing the amount in the trait | 12:37 |
| sean-k-mooney[m] | woudl be even less correct then a max int invetory in my view | 12:37 |
| tkajinam | yeah I agree | 12:38 |
| 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 |
| sean-k-mooney[m] | is it curently just focusing on the nic storage or both | 12:41 |
| sean-k-mooney[m] | i feel like we curely have 2 diffent spec one for each right | 12:41 |
| sean-k-mooney[m] | or am i miss remembering | 12:41 |
| sean-k-mooney[m] | there is a spec related to iothread and block device multi queue | 12:42 |
| sean-k-mooney[m] | and then i think one for contoling the count of quee allcoated to neutorn interfaces | 12:42 |
| 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:43 |
| 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:45 |
| tkajinam | want their admin to enforce the limit *per tenant-basis* | 12:46 |
| tkajinam | we likely discuss the same detail later :-) | 12:46 |
| tkajinam | sean-k-mooney[m], I assume you'd join the watcher sessions today, right ? | 12:50 |
| opendevreview | Merged openstack/nova master: Add info log when destination hypervisor is too old https://review.opendev.org/c/openstack/nova/+/907972 | 14:01 |
| sean-k-mooney[m] | yes but i will be joining for the pci grouping topic | 14:09 |
| sean-k-mooney[m] | i can join specific sessions if needed | 14:09 |
| 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 |
| sean-k-mooney[m] | i.e. some admin created policy | 14:10 |
| sean-k-mooney[m] | that users coudl select but ya the falvor also works | 14:10 |
| opendevreview | Merged openstack/nova master: libvirt: set remaining to 0 when no disk to migrate https://review.opendev.org/c/openstack/nova/+/873846 | 14:15 |
| adamcarthur5 | Hey folks, I hope I haven't butchered the timings, I'll be on the call 15 minutes from now | 15:42 |
| tkajinam | adamcarthur5, I think that works. we are resuming at 1600UTC and your topic is the next one | 15:48 |
| Uggla | adamcarthur5, yep perfect | 15:49 |
| Uggla | JayF, cid ping bulk read API session will start in 10mn | 15:50 |
| cid | \o/ | 15:51 |
| JayF | cid: feel free to attend or not, I thought I'd put both of us on the ping list :) | 15:53 |
| cid | Certainly. I will be attending. | 15:53 |
| Uggla | adamcarthur5 are you in the room ? | 16:01 |
| JayF | yeah he's in | 16:01 |
| opendevreview | Dan Smith proposed openstack/nova-specs master: Add cross-cell-live-migration spec https://review.opendev.org/c/openstack/nova-specs/+/1008081 | 19:23 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!