Wednesday, 2024-02-14

opendevreviewTakashi Kajinami proposed openstack/os-traits master: Add a new trait for AMD SEV-ES  https://review.opendev.org/c/openstack/os-traits/+/90896602:58
opendevreviewTakashi Kajinami proposed openstack/os-traits master: Add a new trait for AMD SEV-ES  https://review.opendev.org/c/openstack/os-traits/+/90896602:59
opendevreviewTakashi Kajinami proposed openstack/os-traits master: Add a new trait for AMD SEV-ES  https://review.opendev.org/c/openstack/os-traits/+/90896603:00
opendevreviewTakashi Kajinami proposed openstack/os-resource-classes master: Add MEM_ENCRYPTED_CONTEXT_V2 resource class  https://review.opendev.org/c/openstack/os-resource-classes/+/90896703:02
opendevreviewTakashi Kajinami proposed openstack/os-resource-classes master: Add MEM_ENCRYPTED_CONTEXT_V2 resource class  https://review.opendev.org/c/openstack/os-resource-classes/+/90896703:49
opendevreviewAmit Uniyal proposed openstack/nova master: enforce remote console shutdown  https://review.opendev.org/c/openstack/nova/+/90182405:36
opendevreviewAmit Uniyal proposed openstack/nova master: enforce remote console shutdown  https://review.opendev.org/c/openstack/nova/+/90182407:23
opendevreviewribaudr proposed openstack/nova master: Amend ShareMappingStatus due to asynchronous call  https://review.opendev.org/c/openstack/nova/+/90886407:37
opendevreviewribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction)  https://review.opendev.org/c/openstack/nova/+/83119407:37
opendevreviewribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part)  https://review.opendev.org/c/openstack/nova/+/83309007:37
opendevreviewribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process  https://review.opendev.org/c/openstack/nova/+/88007507:37
opendevreviewribaudr proposed openstack/nova master: Deletion of associated share mappings on instance deletion  https://review.opendev.org/c/openstack/nova/+/88147207:37
opendevreviewribaudr proposed openstack/nova master: Add metadata for shares  https://review.opendev.org/c/openstack/nova/+/85050007:37
opendevreviewribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part)  https://review.opendev.org/c/openstack/nova/+/85482307:37
opendevreviewribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute manager part)  https://review.opendev.org/c/openstack/nova/+/85482407:37
opendevreviewribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part)  https://review.opendev.org/c/openstack/nova/+/86028407:37
opendevreviewribaudr proposed openstack/nova master: Support resuming an instance with shares (compute manager part)  https://review.opendev.org/c/openstack/nova/+/86028507:37
opendevreviewribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares  https://review.opendev.org/c/openstack/nova/+/86028607:37
opendevreviewribaudr proposed openstack/nova master: Support rescuing an instance with shares (driver part)  https://review.opendev.org/c/openstack/nova/+/86028707:37
opendevreviewribaudr proposed openstack/nova master: Support rescuing an instance with shares (compute manager part)  https://review.opendev.org/c/openstack/nova/+/86028807:37
opendevreviewribaudr proposed openstack/nova master: Allow to mount manila share using Cephfs protocol  https://review.opendev.org/c/openstack/nova/+/88386207:37
opendevreviewribaudr proposed openstack/nova master: Check shares support (compute manager)  https://review.opendev.org/c/openstack/nova/+/88575107:37
opendevreviewribaudr proposed openstack/nova master: Add share lock/unlock and restrict visibility  https://review.opendev.org/c/openstack/nova/+/89034007:37
opendevreviewribaudr proposed openstack/nova master: Check shares support (only API exception)  https://review.opendev.org/c/openstack/nova/+/88575207:37
opendevreviewribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (API)  https://review.opendev.org/c/openstack/nova/+/83683007:37
opendevreviewribaudr proposed openstack/nova master: Check shares support (API)  https://review.opendev.org/c/openstack/nova/+/85049907:37
opendevreviewribaudr proposed openstack/nova master: Add helper methods to attach/detach shares  https://review.opendev.org/c/openstack/nova/+/88575307:37
opendevreviewribaudr proposed openstack/nova master: Add instance.share_attach notification  https://review.opendev.org/c/openstack/nova/+/85050107:37
opendevreviewribaudr proposed openstack/nova master: Add instance.share_detach notification  https://review.opendev.org/c/openstack/nova/+/85102807:37
opendevreviewribaudr proposed openstack/nova master: Add shares to InstancePayload  https://review.opendev.org/c/openstack/nova/+/85102907:37
opendevreviewribaudr proposed openstack/nova master: Add instance.share_attach_error notification  https://review.opendev.org/c/openstack/nova/+/86028207:38
opendevreviewribaudr proposed openstack/nova master: Add instance.share_detach_error notification  https://review.opendev.org/c/openstack/nova/+/86028307:38
opendevreviewribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working.  https://review.opendev.org/c/openstack/nova/+/85208607:38
opendevreviewribaudr proposed openstack/nova master: Add virt/libvirt error test cases  https://review.opendev.org/c/openstack/nova/+/85208707:38
opendevreviewribaudr proposed openstack/nova master: Docs about Manila shares API usage  https://review.opendev.org/c/openstack/nova/+/87164207:38
opendevreviewmelanie witt proposed openstack/nova master: block_device: Add encryption attributes to swap disks  https://review.opendev.org/c/openstack/nova/+/88431208:04
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Configure and teardown ephemeral encryption secrets  https://review.opendev.org/c/openstack/nova/+/82675408:04
opendevreviewmelanie witt proposed openstack/nova master: imagebackend: Add support to libvirt_info for LUKS based encryption  https://review.opendev.org/c/openstack/nova/+/82675508:04
opendevreviewmelanie witt proposed openstack/nova master: Add encryption support to convert_image  https://review.opendev.org/c/openstack/nova/+/87093408:04
opendevreviewmelanie witt proposed openstack/nova master: Add hw_ephemeral_encryption_secret_uuid image property  https://review.opendev.org/c/openstack/nova/+/87093508:04
opendevreviewmelanie witt proposed openstack/nova master: libvirt: make <encryption> a sub element of <source>  https://review.opendev.org/c/openstack/nova/+/90551508:04
opendevreviewmelanie witt proposed openstack/nova master: Support create with ephemeral encryption for qcow2  https://review.opendev.org/c/openstack/nova/+/87093208:04
opendevreviewmelanie witt proposed openstack/nova master: Support (resize|cold migration) with ephemeral encryption for qcow2  https://review.opendev.org/c/openstack/nova/+/87093308:04
opendevreviewmelanie witt proposed openstack/nova master: Support live migration with ephemeral encryption for qcow2  https://review.opendev.org/c/openstack/nova/+/90551208:04
opendevreviewmelanie witt proposed openstack/nova master: Support rebuild with ephemeral encryption for qcow2  https://review.opendev.org/c/openstack/nova/+/87093908:04
opendevreviewmelanie witt proposed openstack/nova master: Support rescue with ephemeral encryption for qcow2  https://review.opendev.org/c/openstack/nova/+/87367508:04
opendevreviewmelanie witt proposed openstack/nova master: Add encryption support to qemu-img rebase  https://review.opendev.org/c/openstack/nova/+/87093608:04
opendevreviewmelanie witt proposed openstack/nova master: Support snapshot with ephemeral encryption for qcow2  https://review.opendev.org/c/openstack/nova/+/87093708:04
opendevreviewmelanie witt proposed openstack/nova master: Add backing_encryption_secret_uuid to BlockDeviceMapping  https://review.opendev.org/c/openstack/nova/+/90796008:04
opendevreviewmelanie witt proposed openstack/nova master: WIP Support encrypted backing files for qcow2  https://review.opendev.org/c/openstack/nova/+/90796108:04
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS  https://review.opendev.org/c/openstack/nova/+/88431308:04
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS  https://review.opendev.org/c/openstack/nova/+/88991208:04
opendevreviewSylvain Bauza proposed openstack/nova master: Modify the mdevs in the migrate XML  https://review.opendev.org/c/openstack/nova/+/90425809:02
Ugglagibi, I pushed an updated serie this morning. Hopefully I fixed most of your comments.10:08
opendevreviewNobuhiro MIKI proposed openstack/nova master: libvirt: Support maxphysaddr.  https://review.opendev.org/c/openstack/nova/+/90751610:12
bauzasUggla: I'm starting to look at your series :)10:18
Ugglabauzas, thx10:18
opendevreviewAmit Uniyal proposed openstack/nova master: Added context manager for instance lock  https://review.opendev.org/c/openstack/nova/+/87364810:26
opendevreviewAmit Uniyal proposed openstack/nova master: Separate OSError with ValueError  https://review.opendev.org/c/openstack/nova/+/90882510:26
opendevreviewAmit Uniyal proposed openstack/nova master: Disconnecting volume from the compute host  https://review.opendev.org/c/openstack/nova/+/87744610:26
opendevreviewAmit Uniyal proposed openstack/nova master: Removed explicit call to delete attachment  https://review.opendev.org/c/openstack/nova/+/89128910:26
stephenfinUggla: Are you happy with https://review.opendev.org/c/openstack/openstacksdk/+/893505 now? Sounds like you figured out the issues you were having using SDK for Manila so that doc is probably correct?12:50
Ugglastephenfin, tbh not really I did not manage to use the service token. So for the moment I left it behind.12:59
stephenfinah, okay12:59
gansogibi, dansmith, sean-k-mooney: hi! could you please review this small patch when you have a few minutes? thanks in advance! https://review.opendev.org/c/openstack/nova/+/90605313:11
sean-k-mooneyganso: its currenlty in merge conflict so it needs a rebase13:12
gansosean-k-mooney: it is? I thought it was predicting a merge conflict with other unmerged patches. Let me rebase it and fix the conflits then, just a sec13:13
sean-k-mooneyganso: no when it says merge conflcit on the left like that its not mergable with master13:14
sean-k-mooneythis is really a feature by the way but ill try and load some context13:14
gansosean-k-mooney: oh I was looking at a stale page. I had to ctrl+F5  for it to show up13:15
gansosean-k-mooney: a feature? you mean it wouldn't be backportable?13:15
opendevreviewRodrigo Barbieri proposed openstack/nova master: Use dedicated live migration network during pre-migration  https://review.opendev.org/c/openstack/nova/+/90605313:19
sean-k-mooneyganso: without new config option i dont think it is backportable no13:25
sean-k-mooneyganso: any change in what network are used could break an existing deployment13:26
sean-k-mooneyganso: im on a call by the way so i have only skimed the patch so perhaps that not a concern13:26
sean-k-mooneywe ahve a new related feature13:26
sean-k-mooneywhich allows configuing what network we use for cold migration13:27
sean-k-mooneywhich is i belive the same code that is deictating what network we are usign itn pre-migration13:27
gansosean-k-mooney: I understand the concern. I have a customer that is running into this issue. They have 2 networks, one for controller and one for migration. The bug causes the controller network to be used and the patch actually addresses the use of the correct migration network. It doesn't change their setup.13:28
sean-k-mooneywe added https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.migration_inbound_addr13:28
gansosean-k-mooney: yep, that is the setting my customer is using to determine the migration network. The issue is that the setting is being ignored by the pre-live-migration step13:29
sean-k-mooneyganso: migration_inbound_addr is somethign we are adding this cycle13:29
sean-k-mooneyso unless they are using master they are suign live_migration_inbound_addr13:29
gansosean-k-mooney: hmmmmmm let me confirm the naming, maybe it is similar to the other one I'm referring to13:30
sean-k-mooneywhich is currently only for the libvirt part13:30
gansosean-k-mooney: yes! live_migration_inbound_addr13:31
gansosean-k-mooney: yes they are using libvirt13:31
sean-k-mooneyright so for cold migration there was no way to use a diffent netwrok before now13:31
gansosean-k-mooney: so the pre-live-migration code is using the wrong address, derived from the same way cold migration determine its address13:31
sean-k-mooneyyep13:31
sean-k-mooneyso on master you could "fix this" by settin gboth option to use the migration network13:31
sean-k-mooneyfor older release it may be valid to change but it not valid to make cold migratoin use the live migration network13:31
sean-k-mooneybased on only live_migration_inbound_addr13:32
gansosean-k-mooney: I am not familiar with the patch code, I just found the fix proposal that I need, but I am a bit surprised that the fix needs an object versioning bump to  make it use the correct network config instead of the wrong one13:32
gansosean-k-mooney: certainly, wouldn't make sense the change the cold-migration behavior, that  indeed would be a new feature13:32
sean-k-mooneyso its not clear its using the wrong netwrok 13:32
sean-k-mooneytechncially the exisitng option is only for the libvirt traffic13:33
gansosean-k-mooney: but fixing something that is a broken behavior in a previously accepted feature is kinda not really a new feature IMO13:33
sean-k-mooneyganso: based on the docs for live_migration_inbound_addr13:33
sean-k-mooneytis not broken13:33
sean-k-mooneythere expecation is incorrect based on teh docuemtned behavior13:33
sean-k-mooneyganso: im not saying what you ask for is not an imporvement13:34
sean-k-mooneyim just sayting that is not what the docs say the config option does13:34
sean-k-mooney"""This option indicates the IP address which should be used as the target for live migration traffic when migrating to this hypervisor. This metadata is then used by the source of the live migration traffic to construct a migration URI."""13:34
sean-k-mooneycopying the disk for block migration is not part of the live migration traffic13:34
gansowell, pre-live-migration is part of live-migration, and if live-migration is not using live-migraiton-inbound-addr then it is somewhat diverging from expected behavior13:35
gansosean-k-mooney: oh copying the disk is not part of live migration traffic13:35
gansosean-k-mooney: I see, the devil is in the details xD13:35
sean-k-mooneyright this option is litrrally jsut for the data copied by libvirt13:35
sean-k-mooneynot the addtional actoins taken by nova13:35
sean-k-mooneybut i agree the enhacment that you are asking for makes sense btu that is why its kind of a feature not a bug13:36
gansosean-k-mooney: yea I understand the reasoning now. The fact that it changes the object versioning already makes it non-backportable If I understand correctly, so the fix would need to be coded differently to be backportable anyway13:37
sean-k-mooneyyes13:37
gansoI need to analyze the code to see if that would be possible, but then also whether it would be acceptable as an backportable enhancement to an existing feature (pending more discussion)13:38
sean-k-mooneyganso: so the new feature we added https://github.com/openstack/nova/commit/6bca37e904e9e56b250b123abde1901e951c8c9a13:39
gansoI will talk to my customer first13:39
sean-k-mooneyi think would solve this usecase13:39
sean-k-mooneyand that is coded in a way that is backportable13:39
sean-k-mooneyso we coudl disucss if we wanted to backport this upstream to adress that bug13:39
sean-k-mooneygibi: ^13:39
gansosean-k-mooney: it is? but it is introducing a new config option (and it is indeed a new feature) so I assumed even if the code is backportable, it wouldn't be accepted to be13:40
sean-k-mooneydo you think https://bugs.launchpad.net/nova/+bug/1939869 is a vaild reason to backport the new migration_inboud_address config option13:40
sean-k-mooneyganso: we normally would not backport it unless there is a large pain point that affects operators13:41
sean-k-mooneywe do sometime back port new config options the impoarnt thing with a backport of this kind is it must not change behaivor by default13:42
sean-k-mooneywhich is true in this case if you want to move all traffic to the migratoin network with that feature you have to set the config option to use the dedicated networks ip/fqdn/hostname13:42
gansosean-k-mooney: if the default value of the new config options retains the existing behavior, that is less concerning impact for existing deployments while backporting13:43
sean-k-mooneyyep it does which is and we also did that for upgrades13:43
sean-k-mooneywe did not want to change the behavior on upgade for the same config file13:43
sean-k-mooneyelodilles: ^ i know this is  borderline but i think gibis feature is a more reasoable approch then https://review.opendev.org/c/openstack/nova/+/90605313:44
gansosean-k-mooney: yea if it solves the issue I am happy with backporting that instead. I need to test to be 100% sure, but it probably does as you say13:45
gansothat other patch may even not be that much necessary anymore13:45
sean-k-mooneyganso: i bleivle https://github.com/openstack/nova/commit/6bca37e904e9e56b250b123abde1901e951c8c9a#diff-486ddc37ce8e7c105a51566dd2cffbda034f28fae7eaad2e74abf470ab296352L4514 is the important part13:46
sean-k-mooneyi belive get_host_ip_addr is the common fucntion that is causing hte current behavior so yes https://review.opendev.org/c/openstack/nova/+/906053 shoudl not be requried anymore13:47
gansoyep13:49
opendevreviewRodrigo Barbieri proposed openstack/nova stable/2023.2: [libvirt]Add migration_inbound_addr  https://review.opendev.org/c/openstack/nova/+/90899514:55
gansosean-k-mooney: I proposed the backport just to get the discussion started ^. Waiting to hear gibi's thoughts on this14:56
sean-k-mooneyack 14:56
dougszuThanks for looking at https://review.opendev.org/c/openstack/nova/+/906053. It comes from a time before the other patch. I will take a look at it shortly. 15:02
*** d34dh0r5- is now known as d34dh0r5315:02
elodillessean-k-mooney: well, if it's more like a feature than a bugfix, then best to avoid the backport, though, there can be exceptions, i mean, if the stable cores agrees that it worth the risk and most probably won't cause any regression, then it can be backported. (the only thing is NOT to change the current behaviour for existing deployments, i'd say)15:02
sean-k-mooneyelodilles: ya for upgrade reasons when we added this it preserved the existing behavior15:03
sean-k-mooneyelodilles: so if we were to backport it as with master you would have to modify the config option to use it15:04
elodilles+115:04
sean-k-mooneyelodilles: tl;dr we supprot movign the libvirt traffic to a dedicate network but only for live migraton 15:04
sean-k-mooneythe feature enables that for cold migration15:04
sean-k-mooneyand as a sideffect also move the block copy done by nova wich is common for live migration to the new network if you opt in with the config option15:05
sean-k-mooneynot all users were aware that the live_migration_inbound_adr is just for the libvirt traffic15:05
sean-k-mooneynot also for novas data transfers15:05
sean-k-mooneyhttps://bugs.launchpad.net/nova/+bug/1939869 is partly a misundertaing of how thing work but i dont think its an unresobale expectation and other operator may have fallen faul of that too15:06
elodillesi see, thanks for the details15:08
elodillessean-k-mooney: added my (long) comment to the backport o:)15:19
sean-k-mooneyack we proably should chat about this either in the channel or in the team meetign to get import form stable folks in general15:21
elodilles+115:22
opendevreviewMerged openstack/nova master: HyperV: Add todo to remove HyperVLiveMigrateData object  https://review.opendev.org/c/openstack/nova/+/90663615:30
dougszusean-k-mooney: Perhaps I missed something, but for https://bugs.launchpad.net/nova/+bug/1939869, i'm not sure how  https://review.opendev.org/c/openstack/nova/+/908995 is going to 'fix'  it. Since the source HV is calling the target HV by RPC, which then needs to get the IP of the source HV (not the hostname)16:01
sean-k-mooneydougszu: it wont because it should not16:04
sean-k-mooneyhoweve if you set the other config option then those calls shoudl use that for the data transfer16:05
sean-k-mooneydougszu: defiening live_migration_inbound_addr should not cause the config driver or other data to be copied via that api16:06
sean-k-mooneyits a miss understanding fo what the config option currently is for16:06
sean-k-mooneythe new config option https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.migration_inbound_addr16:07
sean-k-mooneystates """ metadata is then used by the source of the migration traffic to construct the commands used to copy data (e.g. disk image) to the destination."""16:07
sean-k-mooneyso migration_inbound_addr should modify the adress used for the ssh/rsync 16:08
dougszuYeah, no problem with rejecting the bug report.16:08
sean-k-mooneybut live_migration_inbound_addr should only modify the libvirt traffic16:08
dougszuThis bit, from i've seen happens the other way though: "metadata is then used by the source of the migration traffic to construct the commands used to copy data (e.g. disk image) to the destination"16:09
dougszuI.e. the copy is initiated from the destination to the source16:09
dougszuEg. this runs on the dest: https://review.opendev.org/c/openstack/nova/+/906053/4/nova/virt/libvirt/driver.py#1091716:12
dougszuSo there has to be some way of transferring the source IP/FQDN etc to the dest16:12
dougszuApologies if I've missed something :D 16:13
gansodougszu: I see your point, the custom IP config set in the source would need to be propagated to the destination somehow, as it wouldn't matter that the destination has a custom migration IP too because that's not the relevant one, it is the source one16:19
dougszuganso: yeah, that's it. Wondering if it's worth converting https://review.opendev.org/c/openstack/nova/+/906053 to a feature request16:23
sean-k-mooneythats not how this work16:25
sean-k-mooneythe info is passed form the dest back to the souce16:26
sean-k-mooneyas the migration is started form the soucrce16:26
sean-k-mooneyand we copy the data form the source to test16:26
sean-k-mooney*dest16:26
gansosean-k-mooney: the migration of VM data is, the disk copy no. In the logs that I have I see the dest ssh'ing to the src to scp the disk16:28
dougszu+1, I definitely see the scp initiated from the dest. Eg. for fetching config drive during live migrate.16:29
gansodougszu: to be honest, if the patch already merged doesn't address the issue, then it becomes even more important that the new one does, and being a non-backportable feature prevents customers from accessing the fix unless they upgrade to caracal, which for some is a long time in the future16:30
sean-k-mooneyhum really 16:30
dougszuAs in the bug report at the top: https://bugs.launchpad.net/nova/+bug/193986916:30
sean-k-mooneyi would have to look at that again but for config dirve specificaly16:30
dougszuHappy to share more logs16:30
sean-k-mooneywe dont actully need to copy it manually16:30
sean-k-mooneylibvirt can and will do that now16:30
sean-k-mooneythere was a bug in libvirt several year ago16:30
sean-k-mooneythat required us to do that but i tought we removed that code16:30
dougszu It's also the glance image (if it's no longer available in glance) 16:30
sean-k-mooneyso that should be done form the souce to dest i tought but perhaps its on the dest16:31
sean-k-mooneyok lets do this16:31
sean-k-mooneyour normall request for any complex bug16:32
sean-k-mooneyis to first create a reproducer fucntional test showing the buggy behavior16:32
sean-k-mooneyso it woudl be good to try and simulate this with a fuctional test to show that16:32
gansosean-k-mooney: hmmmmm if it was an older libvirt bug that may not longer be valid or that version no longer used since a given version that matches recent nova version we would backport to (for example focal-zed), so maybe instead of backporting the new config option, or even going with the new patch that bumps the object version, we could perhaps shift things around and move that from the source as you say and use the 16:38
gansolive_migration_inbound_addr instead16:38
gansoactually I don't think zed is used on focal, it is from jammy onwards, and in jammy it may be that every libvirt version available does not have that bug16:38
sean-k-mooneyso there are a few issue at play here.16:39
sean-k-mooneyfirst you should not be doing live migation by doing "openstack server migrate --live-migration --block-migration`"16:39
sean-k-mooney--block-migation was depercated about 6+ years ago16:39
gansosean-k-mooney: oh I didn't know that, the customer is using --block-migration because that's the only way they can get the config drive moved. Is there a better way to do this?16:40
sean-k-mooneyin mitaka we added auto to do the right thing16:42
sean-k-mooneyhttps://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-mitaka16:42
gansosean-k-mooney: by "auto" you mean, not specifying anything? in that case the code complains that it is not in shared storage16:43
sean-k-mooneyso if you do openstack --os-compute-api=2.25 server migrate --live <server>16:44
sean-k-mooneythen it will just do the right thing16:44
sean-k-mooneyand we will leave libvirt copy the config drive i belive16:44
sean-k-mooneyganso: there was a specific bug with libvirt and live migrating with iso files attached as a cdrom16:45
sean-k-mooneythat requried us to copy it first16:45
sean-k-mooneybut that was in like ubuntu 16.0416:45
sean-k-mooneyresolved in libvirt v1.2.17.16:45
sean-k-mooneyhttps://bugs.launchpad.net/nova/+bug/124620116:46
dougszuIt's this code block running on dest (contains both config drive and glance image copy): https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1089216:46
dougszuI'm not seeing where it's gated on --block-migration, but could have missed something16:47
sean-k-mooneyright that was added by https://review.opendev.org/c/openstack/nova/+/365420/1/nova/virt/libvirt/driver.py16:47
sean-k-mooneythat code is not needed anymore and has not been for litrally years16:47
dougszuFor config drive yeah, but not the Glance image?16:48
sean-k-mooneyya so that code https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L10899-L1091116:48
sean-k-mooneycan be removed16:48
sean-k-mooneyfor the backing file16:48
sean-k-mooneywe cant remvoe it but its not a bug that that does nto use the live16:49
sean-k-mooney*live_migrateion_inboud_adr16:49
sean-k-mooneyim not sure if that will now work with the new migration migration_inbound_addr16:50
sean-k-mooneyi belive it should but it it does not it would be a bug in that new feature16:50
gansosean-k-mooney: ok I will ask my customer to re-test that with the --os-compute-api=2.25 --live and without --block-migration and see if that solves the issue16:51
sean-k-mooneyack16:52
dougszuThanks, I can do some more testing. Good to know the config drive code can be removed.16:52
gansosean-k-mooney: btw I thought --live was deprecated in favor of --live-migration, --live was the one that specified the dest and --live-migration leaves it to the scheduler16:52
sean-k-mooneyoh right16:52
sean-k-mooneyya in either case the impoatnt point it to use a microversion >= 2.2516:52
sean-k-mooneyto get the auto behvior16:52
gansosean-k-mooney: thanks for the explanation! :)16:55
sean-k-mooneya straignt revert of https://review.opendev.org/c/openstack/nova/+/365420 wont work because of merge conflcits16:56
opendevreviewsean mooney proposed openstack/nova stable/mitaka: Revert "[libvirt] Live migration fails when config_drive_format=iso9660"  https://review.opendev.org/c/openstack/nova/+/90893716:56
sean-k-mooneyactully never mind apprently it will work16:56
opendevreviewsean mooney proposed openstack/nova stable/mitaka: Revert "[libvirt] Live migration fails when config_drive_format=iso9660"  https://review.opendev.org/c/openstack/nova/+/90893716:57
sean-k-mooneyactully the striagt revert is wrong for other reason but ill see if i can remove that code properly oh also its agaisnt the wrong branch16:58
sean-k-mooneyso ignore ^16:58
sean-k-mooneydougszu: ganso what i was going to say is if either of ye feel like reverting the config drive bit on master i can review16:59
sean-k-mooneyif not ill add this to my todo list and se if we can remove that17:00
dougszuI'll try and have a go tomorrow17:00
gansosean-k-mooney: I rather have my customer test first to be sure there will be a code path that addresses their config drive migration. At the moment I am not sure as I am not familiar with that part of the code. It should go "auto" as you say but each case could be different18:13
*** jph4 is now known as jph18:32

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!