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

[Adrian Vladu]

Because of the commit that introduced platform checks for enabling / using http openstack metadata (https://github.com/canonical/cloud-init/commit/1efa8a0a030794cec68197100f31a856d0d264ab), 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.

[Ryan Harper (raharper)]

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

[Adrian Vladu (avladu)]

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 https://github.com/canonical/cloud-init/commit/1efa8a0a030794cec68197100f31a856d0d264ab#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: https://github.com/canonical/cloud-init/commit/1efa8a0a030794cec68197100f31a856d0d264ab#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.

[Adrian Vladu (avladu)]

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.

[Adrian Vladu (avladu)]

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.

[Ryan Harper (raharper)]

> 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.

[Adrian Vladu (avladu)]

@ryan can you please take a look at this potential fix?
https://github.com/canonical/cloud-init/pull/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

[Balazs Gibizer (balazs-gibizer)]

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

[Balazs Gibizer (balazs-gibizer)]

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

[Dan Watkins (oddbloke)]

A fix for this has just landed in cloud-init: https://github.com/canonical/cloud-init/commit/d76d6e6749315634efe0494501270740e8fef206

[Chad Smith (chad.smith)]

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.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3786