| opendevreview | Takashi Natsume proposed openstack/nova-specs master: Create specs directory for 2024.2 Dalmatian https://review.opendev.org/c/openstack/nova-specs/+/906073 | 00:36 |
|---|---|---|
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Updates glance fixture for create image https://review.opendev.org/c/openstack/nova/+/906088 | 05:23 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Fixes: bfv vm reboot ends up in an error state. https://review.opendev.org/c/openstack/nova/+/906089 | 05:23 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Added context manager for instance lock https://review.opendev.org/c/openstack/nova/+/873648 | 05:44 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/877446 | 05:44 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Removed explicit call to delete attachment https://review.opendev.org/c/openstack/nova/+/891289 | 05:44 |
| bauzas | _colby: I'm here now but let's discuss this when you're back, I have some questions (saw your pastebin) | 08:32 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Fixes: bfv vm reboot ends up in an error state. https://review.opendev.org/c/openstack/nova/+/906089 | 09:19 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Configure and teardown ephemeral encryption secrets https://review.opendev.org/c/openstack/nova/+/826754 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: imagebackend: Add support to libvirt_info for LUKS based encryption https://review.opendev.org/c/openstack/nova/+/826755 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Add encryption support to convert_image https://review.opendev.org/c/openstack/nova/+/870934 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Support create with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870932 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Support resize with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870933 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Add hw_ephemeral_encryption_secret_uuid image property https://review.opendev.org/c/openstack/nova/+/870935 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Add encryption support to qemu-img rebase https://review.opendev.org/c/openstack/nova/+/870936 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Support snapshot with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870937 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Support rebuild and unshelve with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/870939 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Support rescue with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/873675 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: make <encryption> a subelement of <source> https://review.opendev.org/c/openstack/nova/+/905515 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: WIP Support migration with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/905512 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: Reject (resize|rebuild) API requests with conflicting encryption https://review.opendev.org/c/openstack/nova/+/904240 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for qcow2 with LUKS https://review.opendev.org/c/openstack/nova/+/772273 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS https://review.opendev.org/c/openstack/nova/+/884313 | 09:55 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | 09:55 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625 | 10:46 |
| 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 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: add coverage for registered dyn opts https://review.opendev.org/c/openstack/nova/+/902771 | 10:46 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: FUP: add coverage for registered dyn opts https://review.opendev.org/c/openstack/nova/+/902771 | 10:54 |
| *** tosky_ is now known as tosky | 12:50 | |
| 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:18 |
| 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 |
| 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 |
| opendevreview | Tobias Urdin proposed openstack/nova master: Fix wrong nova-manage command in upgrade check https://review.opendev.org/c/openstack/nova/+/880819 | 13:29 |
| opendevreview | Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021 | 13:33 |
| opendevreview | Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021 | 13:36 |
| 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:28 |
| 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 |
| opendevreview | Merged openstack/nova master: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/900831 | 14:48 |
| bauzas | gibi: thanks a lot for the mdev series on both bugfix series | 14:52 |
| bauzas | gibi: are you available for discussing about https://review.opendev.org/c/openstack/nova/+/845757/3/nova/virt/libvirt/driver.py#8563 ? | 14:52 |
| bauzas | (just replied) | 14:58 |
| gibi | bauzas: o/. | 14:59 |
| bauzas | tl;dr: we continue to support VGPU allocations reshape in our code | 14:59 |
| bauzas | and yeah, that's crazy. | 14:59 |
| gibi | so the reshape test needs a from state and to create a from state we need to support some old behavior? | 14:59 |
| bauzas | gibi: well, the better would be to cut from tree all the reshape code | 15:00 |
| bauzas | that's what I replied | 15:00 |
| bauzas | I'm just about to file a blueprint about it | 15:00 |
| 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 |
| bauzas | and then amend my bugfix to not care about non-nested RPs | 15:01 |
| bauzas | but see, that's chicken and eggs here | 15:02 |
| 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 |
| gibi | (I'm not suggesting to do the reshape removal in the current cycle) | 15:02 |
| 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 |
| bauzas | and then, just fix the test to not fail | 15:03 |
| gibi | 1) on your patch I only asked for a tracker for the cleanup so you don't need to change anything there | 15:03 |
| gibi | 2) when thinking about the removal of the `allocated_rp.parent_uuid is None:` conditional | 15:04 |
| 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 |
| gibi | is it so? | 15:05 |
| gibi | OR, does _allocate_mdevs called during reshape itself? | 15:06 |
| gibi | and during reshape you need the conditional | 15:07 |
| 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:07 |
| bauzas | sorry, was filing the blueprint | 15:09 |
| bauzas | https://blueprints.launchpad.net/nova/+spec/drop-vgpu-reshape-support | 15:09 |
| gibi | thanks! | 15:10 |
| bauzas | yeah, that's correct, the reshape test assumes to create a mdev *before* the reshape | 15:10 |
| bauzas | so we can reshape the allocation | 15:10 |
| bauzas | hence the crazy conditional | 15:10 |
| 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:11 |
| gibi | but I guess it is better use of our time to remove the whole reshape support | 15:12 |
| bauzas | I would need to read the functional test in question but I get your point | 15:12 |
| bauzas | that's actually maybe something to test quickly | 15:12 |
| bauzas | I can write a POC on top of that patch | 15:12 |
| gibi | if you have time :) | 15:13 |
| bauzas | as a FUP, that'd remove the logic and then we could see what exactly to do in the functest | 15:13 |
| bauzas | gibi: I can try to spend a couple of hours on that, I'm pretty done with implementing stuff now | 15:13 |
| bauzas | my left tasks are mostly rebases and reviews | 15:13 |
| bauzas | + the mtty patch | 15:14 |
| bauzas | gibi: thanks for your idea, I'll try it ;) | 15:14 |
| * bauzas goes to school | 15:14 | |
| gibi | cool :) | 15:15 |
| bauzas | sean-k-mooney: tbc, you're -1.9999 because of the documentation for https://review.opendev.org/c/openstack/nova/+/845757 ? | 16:10 |
| 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 |
| bauzas | what I could do is try to test with two different custom rcs | 16:12 |
| bauzas | so we could document that this way | 16:12 |
| 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:24 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757 | 16:40 |
| bauzas | sean-k-mooney: updated based on your concerns of the portability of group_policy ^ | 16:44 |
| 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 |
| bauzas | if you look at the generated docs, they will see a big red warning about using group_policy | 16:45 |
| sean-k-mooney | bauzas: i thikn we shoudl be removing all supprot for group_policy in the flavor | 17:08 |
| sean-k-mooney | and in placement in a new placment microverison | 17:09 |
| sean-k-mooney | isolsate beween sepicifc groups is fine | 17:09 |
| sean-k-mooney | but not how it currently works | 17:09 |
| 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 |
| bauzas | have you seen my new revision ? | 17:14 |
| sean-k-mooney | of the followup patch yes im still -1.999 | 17:15 |
| bauzas | I tend to disagree with you | 17:15 |
| sean-k-mooney | maybe -1.95 you did at least add the other options | 17:15 |
| bauzas | because we have a gap that we need to solve | 17:16 |
| bauzas | I'm just fixing some tech debt where we were only looking at one allocation | 17:16 |
| bauzas | and I'm just documenting ways to alleviate the problem | 17:16 |
| 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:16 |
| bauzas | the group policy is really the simplest way for ops that don't care about qos-bandwidth or other nested resources | 17:17 |
| bauzas | and there are big warnings in the docs explaining the limitations of that approach | 17:17 |
| sean-k-mooney | sure but that does not mean the shoudl use it even if they dont have those constraits | 17:17 |
| bauzas | so your -1.95 seems very nitpicky honestlyu | 17:17 |
| sean-k-mooney | it the way that will cause them the most upgrade pain | 17:17 |
| sean-k-mooney | would you prefer i put it to -2 then | 17:17 |
| bauzas | putting -2 for docs seems a bit harsh for me | 17:18 |
| bauzas | I can just remove the whole doc | 17:18 |
| sean-k-mooney | its not about the doc | 17:18 |
| bauzas | and leave the patch | 17:18 |
| bauzas | I can even drop the functional test | 17:18 |
| sean-k-mooney | its about recomending somehting that we know will cause upgrade apin in the future | 17:18 |
| sean-k-mooney | the func test is fine | 17:19 |
| bauzas | do you understand that all of your concerns are about the doc file ? | 17:19 |
| bauzas | not about the python module? | 17:19 |
| bauzas | like I said, I can just drop the doc and leave ops find the way they prefer by themselves | 17:19 |
| 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:19 |
| sean-k-mooney | so yes its all about the doc | 17:20 |
| bauzas | so, I'll split the patch | 17:20 |
| bauzas | I'll just address the python fix in one change | 17:20 |
| sean-k-mooney | no | 17:20 |
| bauzas | and we'll discuss the docs things in a separate change | 17:20 |
| sean-k-mooney | please keep it in two | 17:20 |
| sean-k-mooney | you can add a thid for the doc if you like | 17:20 |
| bauzas | that's what I'm suggesting | 17:21 |
| bauzas | 1/ functest | 17:21 |
| sean-k-mooney | but im just askign you to swap 20 lins of docs | 17:21 |
| bauzas | 2/ patch | 17:21 |
| bauzas | 3/ doc | 17:21 |
| bauzas | so your concern is about the future and the fact that we persist flavors right? | 17:21 |
| sean-k-mooney | yes | 17:21 |
| bauzas | I'm just trying to understand the concern correctly | 17:22 |
| bauzas | say one day another great feature would provide other nested RPs | 17:22 |
| bauzas | and ops eagerly wanting it | 17:22 |
| sean-k-mooney | yep | 17:22 |
| sean-k-mooney | or endusers | 17:22 |
| bauzas | those new children would be one separate RPs but the GPU ones, right? | 17:23 |
| sean-k-mooney | it might not be the operator | 17:23 |
| sean-k-mooney | that not the issue | 17:23 |
| sean-k-mooney | if we use isolate you cant have 2 request_groups form the same rp | 17:23 |
| sean-k-mooney | so pci in placment for example | 17:23 |
| sean-k-mooney | you wont be abel to have 2 vfs form teh same hsot nic | 17:23 |
| bauzas | I get it | 17:24 |
| bauzas | isolate applies to all resource groups | 17:24 |
| sean-k-mooney | yep | 17:24 |
| bauzas | so the problem is really with prefilters then ? | 17:24 |
| sean-k-mooney | no | 17:24 |
| bauzas | because the flavors wouldn't express those | 17:24 |
| bauzas | pci in placement is a good strawman, let's continue to use it for the example | 17:24 |
| sean-k-mooney | the problem is with the placment api | 17:25 |
| sean-k-mooney | well it also apples to cyborg or neturon prots with resouce requests | 17:25 |
| bauzas | say I have VGPUS and PCI | 17:25 |
| sean-k-mooney | sure | 17:25 |
| bauzas | the problem arises when I want to ask for both, right? | 17:25 |
| sean-k-mooney | yes | 17:25 |
| bauzas | and what if I'm asking for a single resource ? | 17:26 |
| bauzas | (resource *class) | 17:26 |
| sean-k-mooney | yes | 17:26 |
| sean-k-mooney | so pci in placeemnt is a less good exampel because we dont suppot that with neturon port yet. but ill give you an example | 17:27 |
| bauzas | you agree that's not a problem if I'm only asking for VGPU *or* PCI, right ? | 17:27 |
| sean-k-mooney | openstack flavor set vgpu_2 --property "resources1:VGPU=1" \ | 17:27 |
| sean-k-mooney | --property "resources2:VGPU=1" \ | 17:27 |
| sean-k-mooney | --property "group_policy=isolate" | 17:27 |
| sean-k-mooney | if we add --property "hw:pci_ailias=my_vf:2" | 17:28 |
| sean-k-mooney | then if we only have one defivce with my_vf aviaable | 17:28 |
| bauzas | I got it | 17:28 |
| bauzas | hence my warning | 17:28 |
| sean-k-mooney | then isolate will break that | 17:28 |
| bauzas | .. warning:: Be careful when using ``group_policy`` as this policy is global to all the resources request. If you ask for other resources but only VGPUs in your flavor, that ``isolate`` policy will also apply for other | 17:28 |
| bauzas | ResourceProviders. | 17:28 |
| bauzas | that will be written in solid red | 17:29 |
| sean-k-mooney | and it also breadk AggregateInstanceExtraSpecsFilter and computecapaitlies filter | 17:29 |
| bauzas | written too | 17:29 |
| bauzas | .. note:: If you use ``AggregateInstanceExtraSpecsFilter`` filter, you also need to configure your aggregates metadata with the ``group_policy`` values. | 17:29 |
| bauzas | (well, I can add the mention to computecapabilitiesFilter for sure) | 17:29 |
| sean-k-mooney | and neutron QOS prots and cyborg integration if the cyborg request profile has multiple devices | 17:30 |
| bauzas | that's covered by the warning section | 17:30 |
| sean-k-mooney | can you see why an approch that break 5 differnt feature is not something i want to recomemnd people to use as the first option | 17:30 |
| bauzas | I'm ready to bet that a very small fraction of users and ops don't care a bit about any of those stuff | 17:30 |
| sean-k-mooney | sure so we can docuemnt it for them but not the first way we recomemnd | 17:31 |
| bauzas | this isn't breaking the feature, this is a limitation saying "you can't and shouldn't request multiple vgpus per instance if you want to create a flavor that asks for more than vgpus" | 17:31 |
| sean-k-mooney | all im asking you to do is move lines 132-156 after lines 158-181 | 17:31 |
| bauzas | if you really want to mix resources, do other ways | 17:32 |
| bauzas | let's talk about the alternatives | 17:32 |
| bauzas | custom traits | 17:32 |
| bauzas | what you're proposing requires ops to define distinct traits between GPUs | 17:32 |
| bauzas | even if they share the same type | 17:33 |
| bauzas | the only difference would be "I'm GPU A" while the other would be "I'm GPU B" | 17:33 |
| bauzas | that's not great, right? | 17:33 |
| sean-k-mooney | well since this bugfix is really a feature then yes | 17:33 |
| sean-k-mooney | without intoducing a new feature to expclity supprot selecting vgpus form diffent parent pysical devices | 17:34 |
| sean-k-mooney | and makign that work transparly you whave to reuse one of our supproted features to acive the same goal | 17:34 |
| bauzas | the real fix is is to drop the silly warning https://review.opendev.org/c/openstack/nova/+/845757/4/nova/virt/libvirt/driver.py#b8541 and just provide a loop | 17:35 |
| bauzas | we could improve that for sure in a blueprint | 17:35 |
| bauzas | we discussed that years ago and we said that it would require some better placement syntax | 17:36 |
| bauzas | before that, there is a quickwin | 17:36 |
| sean-k-mooney | we dont supprot booting a vm with multiple gpus upstream today. it can be done ebcasue we dont block it but this is a new feature | 17:36 |
| bauzas | today, there a gap that prevents you to request two allocations | 17:37 |
| sean-k-mooney | right and its not supported as a result | 17:37 |
| sean-k-mooney | upstream and downstream | 17:37 |
| bauzas | pas-ha[m]: this is Friday but I'd appreciate your thoughts https://review.opendev.org/c/openstack/nova/+/845757/ | 17:38 |
| bauzas | pas-ha[m]: we can talk on Monday | 17:38 |
| bauzas | sean-k-mooney: in the meantime, I'll split https://review.opendev.org/c/openstack/nova/+/845757/ in twice | 17:39 |
| bauzas | and just leave the doc discussion aside | 17:39 |
| sean-k-mooney | sure im ok with merging the repoducer and fix then following up with the doc. can you also add a short release note to the fix patch | 17:44 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757 | 17:44 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: document how to ask for more a single vGPU https://review.opendev.org/c/openstack/nova/+/906151 | 17:44 |
| bauzas | sean-k-mooney: if I go with a relnotes that would be a fixes section just mentioning that now you can request vGPUs using multiple resource groups | 17:45 |
| sean-k-mooney | bauzas: so another way to do this which we can disucss monday | 17:45 |
| sean-k-mooney | is we could have a weigher that perferve allocatoin candates that had resouce form diffent RPs | 17:45 |
| sean-k-mooney | bauzas: yep exactly just short and sweet | 17:46 |
| bauzas | cool | 17:46 |
| spatel | sean-k-mooney hey! | 17:46 |
| spatel | quick question, does snapshot include memory footprint also ? | 17:47 |
| _colby | bauzas: Thank you for your help. So I removed all the resource providers except those listed in the nova config for the device types and now nova is spinning up vgpu instances correctly. Its even creating the mdevs on its own. So I guess it was tying to create an mdev for a device not listed in the config | 17:47 |
| bauzas | _colby: good to know | 17:48 |
| bauzas | _colby: while you're here, I'd like your opinion | 17:48 |
| sean-k-mooney | spatel: no | 17:49 |
| sean-k-mooney | spatel: snaptions are of the root disk only | 17:49 |
| sean-k-mooney | for image baccked innstances | 17:49 |
| bauzas | _colby: I provided a patch that would allow you to request VGPU allocations with different resource groups https://review.opendev.org/c/openstack/nova/+/906151/1 | 17:49 |
| bauzas | _colby: the main concern is how to correctly express the request and my personal take is that in general VGPU flavors only ask for VGPUs | 17:50 |
| bauzas | _colby: do you confirm that you're not interested in mixing vgpu resources and other resources like pci passthrough devices in the same flavor ? | 17:51 |
| spatel | sean-k-mooney good to know :) thanks | 17:56 |
| _colby | bauzas: we have a hypervisor that is strictly for passthrough and some that use vGPU. On the vGPU host we offer a vGPU option with 100% of the GPU though. | 17:58 |
| _colby | Is it even possible to do passthrough with vgpu? With passthrough the nvidia drivers on the hypervisor need to be disabled | 17:59 |
| sean-k-mooney | _colby: not passthogu of a vgpu | 18:00 |
| bauzas | _colby: and you wouldn't be interested in requesting qos-bandwidth ports or cyborg ? | 18:00 |
| _colby | ah I see | 18:00 |
| sean-k-mooney | we mean booting a vm with a sriov nic + a vgpu | 18:00 |
| _colby | not on our system no | 18:00 |
| bauzas | _colby: the context is that I'm documenting some usage | 18:00 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/906151/1/doc/source/admin/virtual-gpu.rst#136 | 18:01 |
| bauzas | if you start using some extra spec parameter called 'group_policy', you may not be able to request other things | 18:01 |
| bauzas | but you can continue to request for a single vGPU *and* other things tho | 18:01 |
| bauzas | the alternative is to do a lot of configuration by privoding distinct traits https://review.opendev.org/c/openstack/nova/+/906151/1/doc/source/admin/virtual-gpu.rst#158 | 18:02 |
| bauzas | but that sounds nearly impracticable for ops to me | 18:02 |
| _colby | bauzas: interesting. Our use case this should be fin. We have not actually had many requests for multiple vgpus, and we dont offer any special NIC options at this time. | 18:05 |
| _colby | We have HPC systems for uses who need things like that. This is more for research groups to use for their projects. | 18:05 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757 | 18:06 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: document how to ask for more a single vGPU https://review.opendev.org/c/openstack/nova/+/906151 | 18:06 |
| bauzas | sean-k-mooney: added the relnote ^ | 18:06 |
| bauzas | sean-k-mooney: _colby also provided some insights about their VGPU usages | 18:06 |
| bauzas | _colby: thanks for your valuable feedback | 18:08 |
| bauzas | _colby: fwiw, we have a couple of improvments in flight this cycle and you may be interested in getting those | 18:08 |
| sean-k-mooney | yep i saw | 18:09 |
| bauzas | https://review.opendev.org/q/topic:%22bug/2041519%22+AND+(is:open+OR+is:merged) | 18:09 |
| sean-k-mooney | _colby even with the patch that bauzas is providing to fix this current bug i would really treat multipel vgpus as experimental | 18:09 |
| bauzas | _colby: the above link would give you the SRIOV fix | 18:10 |
| bauzas | sean-k-mooney: I'm cool with documenting that | 18:10 |
| sean-k-mooney | bauzas: have you tested the move operatios with multipel vgpus. like cold migrate and or your future live migration supprot | 18:10 |
| bauzas | (the fact that's more an unsupported feature than a real thing) | 18:11 |
| bauzas | sean-k-mooney: no tbc | 18:11 |
| bauzas | although I don't see any reason why it wouldn't work | 18:11 |
| sean-k-mooney | i woudl certenly feel more comfortabel saying "multiple vgpus in the same vm is experimatal, please report bugs" | 18:11 |
| bauzas | sean-k-mooney: that's why I'm offering to drop the doc | 18:12 |
| bauzas | the relnote seems enough to me | 18:12 |
| bauzas | if people want to use it, cool | 18:12 |
| sean-k-mooney | lets discuss that next week. you shoudl go start your weekend | 18:13 |
| bauzas | the patches are all ready now | 18:13 |
| bauzas | let's see what CI is saying | 18:13 |
| bauzas | btw. it occured to me that our jobs become again flakey on weird things | 18:13 |
| sean-k-mooney | ya a little | 18:20 |
| sean-k-mooney | any thing in particalr | 18:20 |
| sean-k-mooney | i have seen some nova-lvm failures | 18:20 |
| opendevreview | Jay Faulkner proposed openstack/nova stable/2023.2: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/906155 | 21:11 |
| *** obrest is now known as obre | 21:15 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!