Public bug reported: The fix to bug https://bugs.launchpad.net/nova/+bug/1827492 https://review.opendev.org/#/c/659703/8
changed the behavior of nova.virt.configdrive.required_by to depend on instance.launched_at https://review.opendev.org/#/c/659703/8/nova/virt/configdrive.py@196 but did not reorder https://github.com/openstack/nova/blob/86524773b8cd3a52c98409c7ca183b4e1873e2b8/nova/compute/manager.py#L1757-L1758 as a result when nova.compute.manager._update_instance_after_spawn is called instance.launched_at is always set before we call nova.virt.configdrive.update_instance as a result instance.config_drive will always be set to false if not set on the api. this results in a vm that is spawned on a host with force_config_drive=True initally spawning with a config drive but loosing it after a hard reboot. for any deployment that uses config driver for vendor data or device role tagging because they do not deploy the metadata service this is a regressions as they cannot fall back to the metadta service. this also might cause issue for deployment that support the deprectated file injection api that is part of the v2.1 api as the files are only stored in the config drive and are not part metadta endoint note: i have not checked if we autoset instnace.config_drive when you use file injection or not so it may be unaffected since the breakage of the other support uscases is enough to justify this bug. the fix is simple jsut swap the order of https://github.com/openstack/nova/blob/86524773b8cd3a52c98409c7ca183b4e1873e2b8/nova/compute/manager.py#L1757-L1758 and then instance will have there instnace.config_drive value set correctly when they first boot and it will be sticky for the lifetime of the instance. ** Affects: nova Importance: Medium Assignee: sean mooney (sean-k-mooney) Status: Confirmed ** Tags: libvirt -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1835822 Title: vms loose acess to config drive with CONF.force_config_drive=True after hard reboot Status in OpenStack Compute (nova): Confirmed Bug description: The fix to bug https://bugs.launchpad.net/nova/+bug/1827492 https://review.opendev.org/#/c/659703/8 changed the behavior of nova.virt.configdrive.required_by to depend on instance.launched_at https://review.opendev.org/#/c/659703/8/nova/virt/configdrive.py@196 but did not reorder https://github.com/openstack/nova/blob/86524773b8cd3a52c98409c7ca183b4e1873e2b8/nova/compute/manager.py#L1757-L1758 as a result when nova.compute.manager._update_instance_after_spawn is called instance.launched_at is always set before we call nova.virt.configdrive.update_instance as a result instance.config_drive will always be set to false if not set on the api. this results in a vm that is spawned on a host with force_config_drive=True initally spawning with a config drive but loosing it after a hard reboot. for any deployment that uses config driver for vendor data or device role tagging because they do not deploy the metadata service this is a regressions as they cannot fall back to the metadta service. this also might cause issue for deployment that support the deprectated file injection api that is part of the v2.1 api as the files are only stored in the config drive and are not part metadta endoint note: i have not checked if we autoset instnace.config_drive when you use file injection or not so it may be unaffected since the breakage of the other support uscases is enough to justify this bug. the fix is simple jsut swap the order of https://github.com/openstack/nova/blob/86524773b8cd3a52c98409c7ca183b4e1873e2b8/nova/compute/manager.py#L1757-L1758 and then instance will have there instnace.config_drive value set correctly when they first boot and it will be sticky for the lifetime of the instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1835822/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
