Earlier  
Posted Nick Remark
#openstack-nova - 2022-06-14
12:39:22 sean-k-mooney so if we just continue the backport of the sorting behavior we could close it as a dupe i guess
12:39:56 sean-k-mooney that does raise the question of if we should change the default for pack vs spread on master and or still look at the other implemation in the future
12:39:56 gibi sean-k-mooney: thanks
12:40:29 gibi I think we can chance default on master now
12:40:33 gibi if we want
12:40:45 gibi probably not on stable
12:44:09 sean-k-mooney right not stabel but i can propose a patch to change the default and add a release note for people to review
12:47:40 gibi yeah, lets try
12:48:00 gibi I have to refresh myself about the trade off though
12:49:42 sean-k-mooney spread will try to put vms on empty numa nodes first pack does the reverse trying to use all aviable space on numa ndoes before using the next one
12:50:06 sean-k-mooney if you have 2 numa nodes and but 3 vms 1 that need a full numa node and 2 that each need a half numa node
12:50:26 sean-k-mooney then with pack all 3 will in any order
12:50:45 sean-k-mooney with spread unless the big vms is booted first only 2 of the 2 will schdule
12:50:54 sean-k-mooney gibi: ^ that the main trade off
12:51:28 gibi thanks
12:51:41 sean-k-mooney but if you spread you get better cpu/memory performace in the guest until the node is full and then its the same
12:52:08 gibi I think both way is valid, but if we know that the scheduling performance is better in the spread case then that might be enough reasoning to switch
12:52:29 gibi the default
12:52:41 sean-k-mooney yep both are valid but i personaly prefer spread as the default
12:53:02 sean-k-mooney it does need to be configurable
12:53:09 sean-k-mooney so that operators can choose
12:53:38 sean-k-mooney you could technially have differnt values on scheduler vs compute too
12:53:52 sean-k-mooney you could use spread in schduler and pack on computes
12:54:55 bauzas gibi: good news, I was able to ask for multiple vGPUs
12:54:59 sean-k-mooney currently we recompute the pinning on the compute anyway since we throwaway the schduler info
12:55:20 bauzas but yeah, we hit the warning, so we only have one VGPU
12:55:27 sean-k-mooney bauzas: using generic mdevs to use differnt device classees for differnt host gpus
12:55:40 sean-k-mooney or via multi create
12:55:46 bauzas sean-k-mooney: lemme upload the functest
12:55:52 sean-k-mooney ack
13:09:36 opendevreview Sylvain Bauza proposed openstack/nova master: Add a functest for verifying multiple VGPU allocations https://review.opendev.org/c/openstack/nova/+/845747
13:09:42 bauzas sean-k-mooney: ^
13:10:34 bauzas sean-k-mooney: tl,dr: given of the nvidia driver issue (you can't ask for more than one VGPU per pGPU per instance), operators would then want to spread the vGPUs between multiple pGPUs
13:12:49 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/845748
13:26:14 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/845753
13:29:29 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Clean up when queued live migration aborted https://review.opendev.org/c/openstack/nova/+/845754
13:42:05 opendevreview Sylvain Bauza proposed openstack/nova master: WIP : Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757
13:42:11 bauzas gibi: ^
14:15:50 gibi bauzas: left feedback :)
14:16:05 bauzas cool, this is just a WIP tho
14:17:19 bauzas gibi: thanks for commenting, those are good thoughts
14:18:25 gibi I didn't even relaized that it is a WIP, it has functional test :D
14:19:06 bauzas Zuul will hit my face as I think I'm closing some gaps
14:19:15 bauzas and I'll need to change some UTs
14:27:36 ygk_12345 can someone look into this https://bugs.launchpad.net/oslo.messaging/+bug/1978562 please
14:32:52 opendevreview Balazs Gibizer proposed openstack/nova master: Clean up mapping input to address spec types https://review.opendev.org/c/openstack/nova/+/845765
14:36:29 opendevreview Balazs Gibizer proposed openstack/nova master: Clean up mapping input to address spec types https://review.opendev.org/c/openstack/nova/+/845765
15:02:10 opendevreview Elod Illes proposed openstack/placement stable/victoria: Add periodic-stable-jobs template https://review.opendev.org/c/openstack/placement/+/845770
15:03:28 opendevreview Artom Lifshitz proposed openstack/nova master: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/824048
15:09:15 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/845748
15:10:56 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/845753
15:11:18 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Clean up when queued live migration aborted https://review.opendev.org/c/openstack/nova/+/845754
15:21:59 opendevreview Balazs Gibizer proposed openstack/nova master: Remove unused PF checking from get_function_by_ifname https://review.opendev.org/c/openstack/nova/+/845775
15:30:50 opendevreview Balazs Gibizer proposed openstack/nova master: Fix type annotation of pci.Whitelist class https://review.opendev.org/c/openstack/nova/+/845780
15:35:30 ygk_12345 can someone look into this https://bugs.launchpad.net/oslo.messaging/+bug/1978562 please
15:40:23 bauzas reminder: nova meeting in 20 mins
15:50:57 opendevreview Balazs Gibizer proposed openstack/nova master: Move __str__ to the PciAddressSpec base class https://review.opendev.org/c/openstack/nova/+/845781
16:00:00 opendevmeet The meeting name has been set to 'nova'
16:00:00 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:00 opendevmeet Meeting started Tue Jun 14 16:00:00 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:00 bauzas #startmeeting nova
16:00:06 bauzas howdy back
#openstack-nova - 2022-06-15
03:29:03 opendevreview Merged openstack/nova stable/ussuri: Reproduce bug 1953359 https://review.opendev.org/c/openstack/nova/+/822047
03:29:10 opendevreview Merged openstack/nova stable/ussuri: Extend the reproducer for 1953359 and 1952915 https://review.opendev.org/c/openstack/nova/+/822048
04:28:23 opendevreview Merged openstack/nova stable/ussuri: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/822050
06:24:34 gibi sean-k-mooney: about hw:bfv=True. I don't think putting everything into flavor is a good idea. We already have the flavor explosion issue
06:25:50 gibi also in analogous for hw:bfv_type somebody could start asking for hw:port_vnic_type=direct
06:26:28 sean-k-mooney[m] they could but they have wanted to do that for years too
06:26:37 gibi and we said no :)
06:27:00 sean-k-mooney[m] yep im not sure the flavor explosion issue is reall still an issue
06:27:17 sean-k-mooney[m] i think operators are just used to there being many
06:27:18 gibi we still heard the term last week
06:27:45 sean-k-mooney[m] right but they just accept it and create lots of flavors
06:28:56 gibi OK, so if we say no for a long time to hw:bfv=True then they will accept that too :) and stop asking for more orchestrations
06:29:14 sean-k-mooney[m] like some of the telco provideders litrally create seperate flavors for every application in a multi app vnf automaticaly via heat
06:29:37 sean-k-mooney[m] well the latter will never happen
06:29:43 gibi :)
06:29:51 sean-k-mooney[m] but the flavor may not be the right place
06:30:13 sean-k-mooney[m] i dont thing its unreasonable to have a way to say always uses cinder volumes
06:30:32 sean-k-mooney[m] or always to it on these set of hosts by default
06:30:37 gibi if it is _always_ then this can be a config option
06:30:54 sean-k-mooney[m] not it cant be
06:31:05 sean-k-mooney[m] that would be config driven api behavior
06:31:20 gibi or even the admin can define the nova instance dir to be in a place with close to 0 disk space to force it
06:31:20 sean-k-mooney[m] which is one of the reasons we didnt like having a cinder images type
06:32:02 sean-k-mooney[m] well they can force it differntly via config options to day but its not somethign you can discover without trying to boot a vm
06:32:50 sean-k-mooney[m] they are stilll raising it as a pain point so obviouls they still want a way to do this
06:33:34 sean-k-mooney[m] i tried to adress this issue differntly in the past by proposing the idea of vm porfiles to have a semi composable flavor
06:35:11 sean-k-mooney[m] the profiles would only have extra specs that did not change resouce usage so therefor did not change billing
06:35:37 gibi extra spec can reqeust pinning that might be billed differently.
06:35:56 sean-k-mooney[m] as a use you can request that in your image
06:35:56 gibi but I feel I'm too negative today. sorry
06:36:21 sean-k-mooney[m] so if the falvor has not explictly disabled it you can always do that
06:36:30 gibi still dedicated cpus are billed differently in public clouds afaik
06:36:45 sean-k-mooney[m] right but that trivial to adress
06:36:57 sean-k-mooney[m] just put hw:cpu_policy=shared in the base flavors
06:37:42 sean-k-mooney[m] today if you do not do that you can just put hw_cpu_policy=deicated in the image
06:38:01 sean-k-mooney[m] i assumed you were going to bring up resouce:
06:38:17 gibi so in my mind this is similar to network connectivity. if you need it pass a pre-created port to nova. so I would move the whole disk question out from the flavor too. If you need disk (:D) then pass either a pre-created local-disk or a pre-created volume to the boot command.
06:38:21 sean-k-mooney[m] which is why i said extra specs that dont affect resouce useage

Earlier   Later