Fail to get http openstack metadata if the Linux instance runs on Hyper-V

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1895976

Launchpad details

affected_projects = ['compute-hyperv', 'nova', 'os-win']
assignee = None
assignee_name = None
date_closed = 2020-11-24T17:58:51.427379+00:00
date_created = 2020-09-17T13:14:30.255688+00:00
date_fix_committed = 2020-10-15T19:39:21.116851+00:00
date_fix_released = 2020-11-24T17:58:51.427379+00:00
id = 1895976
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1895976
milestone = None
owner = avladu
owner_name = Adrian Vladu
private = False
status = fix_released
submitter = avladu
submitter_name = Adrian Vladu
tags = []
duplicates = []

Launchpad user Adrian Vladu(avladu) wrote on 2020-09-17T13:14:30.255688+00:00

Because of the commit that introduced platform checks for enabling / using http openstack metadata (1efa8a0), cloud-init on Linux machines will stop loading http metadata when running on "unsupported" platforms / hypervisors like Hyper-V, XEN, OracleCloud, VMware, OpenTelekomCloud - leading to a whole suite of bug reports and fixes to a non-issue.

Let's try to solve this problem once for all the upcoming platforms / hypervisors by adding a configuration option on the metadata level: perform_platform_check or check_if_platform_is_supported (suggestions are welcome for the naming). The value of the config option should be true in order to maintain backwards compatibility. When set to true, cloud-init will check if the platform is supported.

No one would like to patch well-working OpenStack environments for this kind of issues and it is always easier to control / build the images you use on private OpenStack.

[ubuntu-server-builder]

Launchpad user Ryan Harper(raharper) wrote on 2020-09-17T17:30:36.424751+00:00

Hi,

Can you run 'cloud-init collect-logs' and attach the tarball?

Generally the Nova driver should be returning well-known system-product-name values regardless of underlying hypervisor tech/cloud.

https://bugs.launchpad.net/cloud-init/+bug/1881814

[ubuntu-server-builder]

Launchpad user Adrian Vladu(avladu) wrote on 2020-09-17T17:44:31.330536+00:00

I think the cloud-init logs won't help in this matter, as all they say is that 'the metadata could not be loaded, bad things to come'.

The problem is that Hyper-V exposes 'Virtual Machine' as product_name, thus this check fail: detect_openstack from 1efa8a0#diff-d0124efa9c349e076a076e7061eee70eR217.

I checked there seems Hyper-V does not have an API to set the product_name for a VM, but has an API to change the chassis tag to anything we would like. Even if that can be done, both nova and cloud-init have to be changed.

In case of cloud-init, another valid DMI chassis tag should be added here: 1efa8a0#diff-d0124efa9c349e076a076e7061eee70eR31

In case of nova, the valid tag should be set here: https://github.com/openstack/os-win/blob/master/os_win/utils/compute/vmutils.py#L369
vs_data.ChassisAssetTag= "OPENSTACK_ON_HYPERV"

See: https://docs.microsoft.com/en-us/windows/win32/hyperv_v2/msvm-virtualsystemsettingdata

But what I do not like is that everyone that wants to add in the future some other exotic or upcoming platform, it has to change code in both places. Also, these kind of changes are usually not deemed backwards compatible, so there is a valid point that the existent Ubuntu versions, for example, will never include that change.

That is why I suggest to create a new cloud-init per metadata config option (called like this: self.ds_cfg.get("perform_platform_check", True)), which when set to false, cloud-init shoud not perform platform checks.

[ubuntu-server-builder]

Launchpad user Adrian Vladu(avladu) wrote on 2020-09-17T17:47:38.802100+00:00

I still need to better investigate if the product_name can be set using the existing Hyper-V VM APIs. The backward compat and future platform support concerns will stil be valid IMHO.

[ubuntu-server-builder]

Launchpad user Adrian Vladu(avladu) wrote on 2020-09-17T17:55:18.352065+00:00

Another option would be to make a per metadata config option called valid_dmi_asset_tag = ["valid tag 1", "valid tag 2"], and another one for product_names: valid_dmi_product_tag = ["OpenStack", "OpenStack Nova"]. This implementation also has the advantage that is backwards compatible.

[ubuntu-server-builder]

Launchpad user Ryan Harper(raharper) wrote on 2020-09-17T18:12:05.828880+00:00

these kind of changes are usually not deemed backwards compatible, so there is a valid point that the existent Ubuntu versions, for example, will never include that change.

Cloud-init updates from master are regularly (roughly once a quarter) released into previous Ubuntu LTS versions.

If there are changes to cloud-init needed they can be released into older versions of Ubuntu. In some cases where new features would change behavior, those are disabled in the older Ubuntu releases. For an issue like this where it would fix otherwise broken behavior it would be enabled in all of the releases.

[ubuntu-server-builder]

Launchpad user Adrian Vladu(avladu) wrote on 2020-09-22T09:32:29.306951+00:00

@ryan can you please take a look at this potential fix?
#580

The above cloud init PR is accompanied by two other patches on os-win and nova:

os-win: https://review.opendev.org/#/c/752714/
nova: https://review.opendev.org/#/c/752723/

Thank you,
Adrian Vladu

[ubuntu-server-builder]

Launchpad user Balazs Gibizer(balazs-gibizer) wrote on 2020-09-22T10:25:36.413904+00:00

I'm setting this bug to InProgress for both Nova and os-win due to patches exists. See comment #6

[ubuntu-server-builder]

Launchpad user Balazs Gibizer(balazs-gibizer) wrote on 2020-09-22T10:26:36.501296+00:00

Actually os-win patch has already been merged so setting the bug to Fix committed for os-win.

[ubuntu-server-builder]

Launchpad user Dan Watkins(oddbloke) wrote on 2020-10-15T19:39:34.788549+00:00

A fix for this has just landed in cloud-init: d76d6e6

[ubuntu-server-builder]

Launchpad user Chad Smith(chad.smith) wrote on 2020-11-24T17:58:53.996642+00:00

This bug is believed to be fixed in cloud-init in version 20.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.