openstack: Support config drive without EC2 metadata

[olljanat]

Nutanix AHV uses cloud-init/Ignition which is based on OpenStack implemention.

However it provides only OpenStack metadata without EC2 metadata which why current logic added by #462 fails to error:

# journalctl -u coreos-metadata
Jan 10 06:39:45 localhost systemd[1]: Starting coreos-metadata.service - Flatcar Metadata Agent...
Jan 10 06:39:45 localhost coreos-metadata[1423]: Error: failed to run
Jan 10 06:39:45 localhost coreos-metadata[1423]: Caused by:
Jan 10 06:39:45 localhost coreos-metadata[1423]:     0: writing metadata attributes
Jan 10 06:39:45 localhost coreos-metadata[1423]:     1: failed to open file '"/tmp/afterburn-EZcXvr/ec2/latest/meta-data.json"'
Jan 10 06:39:45 localhost coreos-metadata[1423]:     2: No such file or directory (os error 2)
Jan 10 06:39:45 localhost systemd[1]: coreos-metadata.service: Main process exited, code=exited, status=1/FAILURE
Jan 10 06:39:45 localhost systemd[1]: coreos-metadata.service: Failed with result 'exit-code'.
Jan 10 06:39:45 localhost systemd[1]: Failed to start coreos-metadata.service - Flatcar Metadata Agent.

So this PR simply adds logic which allow OpenStack metadata to be returned even when EC2 metadata is not available.

Tested with this custom build in Flatcar Linux:

# journalctl -u coreos-metadata
Jan 10 10:35:22 localhost systemd[1]: Starting coreos-metadata.service - Flatcar Metadata Agent...
Jan 10 10:35:23 localhost systemd[1]: Finished coreos-metadata.service - Flatcar Metadata Agent.

[prestist]

@olljanat sorry if this is a misplaced question, but looking at the supported platforms, and the code base Nutanix is not listed. If Nutanix ATH works with open stack settings, It might make sense to make a provider based off of the open stack provider as a template?

[olljanat]

@prestist That is valid question. The part which I don’t know well enough is that what actually is relationship between Openstack and Amazon EC2? Because it is those EC2 parts which fails without this.

Are those expected to be always available in all OpenStack environments? I would guess not because they were not part of original implementation so this would be actually bugfix to incorrect fallback logic in #462

[prestist]

@olljanat, ah, I see. Yeah I guess in that case we can probably update the commit to drop the details about Nutanix ATH, In some limited research it could be turned off and in those cases it will error as you have shown. Then we should be falling back on the network service.

[olljanat]

@prestist That works for me. PR updated.

[jlebon]

Can you reply in #1131 to #1131 (comment)?

But that said, for Nutanix specifically note that at least in Ignition, it is a registered provider. Initially the Afterburn piece was not added because it was originally said that no metadata was provided. Possibly this changed in more recent versions. Regardless, this patch is fine, but it might make sense in the future to indeed have a dedicated nutanix provider here too that just shares code with the OpenStack one given that Afterburn is commonly used in combination with Ignition.

[olljanat]

Can you reply in #1131 to #1131 (comment)?

Your approach is fine. Approved that and closing this one.

But that said, for Nutanix specifically note that at least in Ignition, it is a registered provider. Initially the Afterburn piece was not added because it was originally said that no metadata was provided. Possibly this changed in more recent versions. Regardless, this patch is fine, but it might make sense in the future to indeed have a dedicated nutanix provider here too that just shares code with the OpenStack one given that Afterburn is commonly used in combination with Ignition.

I see that those patches was written by Red Hat employees so it might be related to Nutanix + Red Hat partnership.

However, only very small number of Linux distros actually publishes Nutanix AHV specific images so it easier for everyone if we can keep using OpenStack based images.