Earlier  
Posted Nick Remark
#openstack-nova - 2024-01-19
09:55:15 opendevreview melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912
10:46:02 opendevreview Sylvain Bauza proposed openstack/nova master: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625
10:46:02 opendevreview Sylvain Bauza proposed openstack/nova master: vgpu: Allow device_addresses to not be set https://review.opendev.org/c/openstack/nova/+/902084
10:46:03 opendevreview Sylvain Bauza proposed openstack/nova master: WIP: add coverage for registered dyn opts https://review.opendev.org/c/openstack/nova/+/902771
10:54:54 opendevreview Sylvain Bauza proposed openstack/nova master: FUP: add coverage for registered dyn opts https://review.opendev.org/c/openstack/nova/+/902771
13:18:46 opendevreview Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381
13:25:04 opendevreview Tobias Urdin proposed openstack/nova master: libvirt: set remaining to 0 when no disk to migrate https://review.opendev.org/c/openstack/nova/+/873846
13:25:09 opendevreview Tobias Urdin proposed openstack/nova master: libvirt: set remaining to 0 when no disk to migrate https://review.opendev.org/c/openstack/nova/+/873846
13:29:28 opendevreview Tobias Urdin proposed openstack/nova master: Fix wrong nova-manage command in upgrade check https://review.opendev.org/c/openstack/nova/+/880819
13:33:50 opendevreview Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021
13:36:20 opendevreview Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021
14:28:45 opendevreview Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381
14:38:30 opendevreview Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381
14:48:43 opendevreview Merged openstack/nova master: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/900831
14:52:32 bauzas gibi: thanks a lot for the mdev series on both bugfix series
14:52:47 bauzas gibi: are you available for discussing about https://review.opendev.org/c/openstack/nova/+/845757/3/nova/virt/libvirt/driver.py#8563 ?
14:58:55 bauzas (just replied)
14:59:17 gibi bauzas: o/.
14:59:34 bauzas tl;dr: we continue to support VGPU allocations reshape in our code
14:59:40 bauzas and yeah, that's crazy.
14:59:45 gibi so the reshape test needs a from state and to create a from state we need to support some old behavior?
15:00:07 bauzas gibi: well, the better would be to cut from tree all the reshape code
15:00:15 bauzas that's what I replied
15:00:30 bauzas I'm just about to file a blueprint about it
15:01:37 bauzas papework-wise, I feel brave enough to have a 6th effort on VGPU (and a 6th potential conflict) that would drop the whole reshape code (and tests)
15:01:50 bauzas and then amend my bugfix to not care about non-nested RPs
15:02:08 bauzas but see, that's chicken and eggs here
15:02:09 gibi can we decouple the test from the reshape support? E.g. can we prepare the from state purely in placement / db and then let the reshape code run on that state?
15:02:53 gibi (I'm not suggesting to do the reshape removal in the current cycle)
15:03:26 bauzas gibi: not sure I get your point, are you asking me to modify my patch to assert that that the allocated RP is always a child RP ?
15:03:51 bauzas and then, just fix the test to not fail
15:03:54 gibi 1) on your patch I only asked for a tracker for the cleanup so you don't need to change anything there
15:04:32 gibi 2) when thinking about the removal of the `allocated_rp.parent_uuid is None:` conditional
15:05:13 gibi I assume that you need that conditional becuase the functional reshape test sets up the from state (with VGPU on root RP) while nova is running and therefore you need the conditional
15:05:28 gibi is it so?
15:06:51 gibi OR, does _allocate_mdevs called during reshape itself?
15:07:16 gibi and during reshape you need the conditional
15:07:38 gibi anyhow this is not super important now. We have a tracker, we will get back to this when we have time to clean up
15:09:45 bauzas sorry, was filing the blueprint
15:09:48 bauzas https://blueprints.launchpad.net/nova/+spec/drop-vgpu-reshape-support
15:10:19 gibi thanks!
15:10:35 bauzas yeah, that's correct, the reshape test assumes to create a mdev *before* the reshape
15:10:45 bauzas so we can reshape the allocation
15:10:53 bauzas hence the crazy conditional
15:11:39 gibi OK. so hypotetically we could try to set up the from state purely in DB / placement and only start up the nova-compute service after it. So we won't try to create an mdev with nova in the from state
15:12:08 gibi but I guess it is better use of our time to remove the whole reshape support
15:12:08 bauzas I would need to read the functional test in question but I get your point
15:12:34 bauzas that's actually maybe something to test quickly
15:12:55 bauzas I can write a POC on top of that patch
15:13:16 gibi if you have time :)
15:13:21 bauzas as a FUP, that'd remove the logic and then we could see what exactly to do in the functest
15:13:46 bauzas gibi: I can try to spend a couple of hours on that, I'm pretty done with implementing stuff now
15:13:58 bauzas my left tasks are mostly rebases and reviews
15:14:07 bauzas + the mtty patch
15:14:52 bauzas gibi: thanks for your idea, I'll try it ;)
15:15:14 gibi cool :)
16:10:54 bauzas sean-k-mooney: tbc, you're -1.9999 because of the documentation for https://review.opendev.org/c/openstack/nova/+/845757 ?
16:12:03 bauzas I'm asking for that due to the fact you're OK with the functest https://review.opendev.org/c/openstack/nova/+/845747/3
16:12:24 bauzas what I could do is try to test with two different custom rcs
16:12:37 bauzas so we could document that this way
16:24:10 kashyap tobias-urdin: Thanks for the respin here: https://review.opendev.org/c/openstack/nova/+/879021. Will look on Mon. (I'm buried in another context now)
16:40:13 opendevreview Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757
16:44:34 bauzas sean-k-mooney: updated based on your concerns of the portability of group_policy ^
16:45:06 bauzas I still think we want to document this as this is simpler for operators if they don't give a shit about other nested resource classes
16:45:34 bauzas if you look at the generated docs, they will see a big red warning about using group_policy
17:08:48 sean-k-mooney bauzas: i thikn we shoudl be removing all supprot for group_policy in the flavor
17:09:33 sean-k-mooney and in placement in a new placment microverison
17:09:49 sean-k-mooney isolsate beween sepicifc groups is fine
17:09:54 sean-k-mooney but not how it currently works
17:14:31 sean-k-mooney bauzas: regarding the funtional test i woudl personally prefer if you provided fucntioal tests usign custom resouce classes and/or traits too
17:14:47 bauzas have you seen my new revision ?
17:15:30 sean-k-mooney of the followup patch yes im still -1.999
17:15:41 bauzas I tend to disagree with you
17:15:48 sean-k-mooney maybe -1.95 you did at least add the other options
17:16:01 bauzas because we have a gap that we need to solve
17:16:20 bauzas I'm just fixing some tech debt where we were only looking at one allocation
17:16:35 bauzas and I'm just documenting ways to alleviate the problem
17:16:36 sean-k-mooney im ok with you documeiting the group_policy way if its not the first way we present adn it not the one we recommend
17:17:07 bauzas the group policy is really the simplest way for ops that don't care about qos-bandwidth or other nested resources
17:17:28 bauzas and there are big warnings in the docs explaining the limitations of that approach
17:17:37 sean-k-mooney sure but that does not mean the shoudl use it even if they dont have those constraits
17:17:44 bauzas so your -1.95 seems very nitpicky honestlyu
17:17:46 sean-k-mooney it the way that will cause them the most upgrade pain
17:17:55 sean-k-mooney would you prefer i put it to -2 then
17:18:09 bauzas putting -2 for docs seems a bit harsh for me
17:18:19 bauzas I can just remove the whole doc
17:18:22 sean-k-mooney its not about the doc
17:18:24 bauzas and leave the patch
17:18:36 bauzas I can even drop the functional test
17:18:44 sean-k-mooney its about recomending somehting that we know will cause upgrade apin in the future
17:19:11 sean-k-mooney the func test is fine
17:19:18 bauzas do you understand that all of your concerns are about the doc file ?
17:19:25 bauzas not about the python module?
17:19:51 bauzas like I said, I can just drop the doc and leave ops find the way they prefer by themselves
17:19:58 sean-k-mooney so i think it woudl be nice ot have other func test as well but you have enocuh to merge the patch i think
17:20:02 sean-k-mooney so yes its all about the doc
17:20:14 bauzas so, I'll split the patch
17:20:30 bauzas I'll just address the python fix in one change
17:20:43 sean-k-mooney no
17:20:43 bauzas and we'll discuss the docs things in a separate change

Earlier   Later