Open tla5 opened 8 months ago
Hello @tla5 thanks for the complete report. I wrote the Ignition IMDS Azure fetching and indeed I recall that it can return a status code 200 with an empty config, that's why there is a check on the length received which triggers the fallback on custom data. I did not reproduced but I feel it fails before I think it does not succeed to get the answer from the IMDS server if it was the case, even with an empty config, it would have failed later. Here, we can clearly see it's hanging. I'll try to reproduce for investigation.
I think it fails because azurestack
is a bit different regarding the CDROM filesystems:
https://github.com/coreos/ignition/blob/528dbbfba1404cda78bcc7628b06dbea9d441388/internal/providers/azurestack/azurestack.go#L31-L34
// These constants are the types of CDROM filesystems that might // be used to present a custom-data volume. Azure proper uses a // udf volume, while Azure Stack might use udf or iso9660.
In this case, if we're using azure
we might miss the iso9660
fs which makes us fall into this infinite loop: https://github.com/coreos/ignition/blob/528dbbfba1404cda78bcc7628b06dbea9d441388/internal/providers/azure/azure.go#L169
I'm wondering if we could not merge azurestack
and azure
Ignition provider and teach Ignition to discover if it's running in azurestack or azure.
Some of the historical discussion about azure vs azurestack support in Fedora CoreOS could be useful here.
Thank you for your investigation!
teach Ignition to discover if it's running in azurestack or azure
This could be done by querying the IMDS' compute endpoint, which returns a specific azEnvironment
value on Azure Stack
Hello, I'm opening this issue as recommended on the Matrix Flatcar channel.
Current situation
From what I can tell, the Azure Flatcar image cannot reliably be used out of the box on Azure Stack due to issues related to Ignition: the provider being set to
azure
, Ignition attempts to get its configuration from theuserData
property through the IMDS API (code).This attribute is not available on Azure Stack yet, but IMDS still replies to Ignition which causes
ignition-fetch
to hang (and the VM to stay stuck in a perpetualCreating
state).Impact
Flatcar Azure images cannot be used on Azure Stack, and no off-the-shelf alternative is proposed as far as I know.
Ideal future situation/Implementation options
It would be good to have either official images configured for Azure Stack, or a way to customize the existing Azure image to change Ignition's provider configuration from
azure
toazurestack
(i.e. by patching the OEM partition).Additional information
Here are some relevant logs from an attempt at running an Azure Stack-hosted Flatcar VM using
flatcar_production_azure_image.vhd
Running a query from another VM hosted on that Azure Stack instance to the IMDS service yields the following:
Interestingly, the response is empty but, despite what's commented in the Ignition provider, it doesn't seem to fall back to the OVF device method.