providers: add a new "azurestack" platform (client logic for AzureStackHub) about afterburn

[darkmuggle]

Allegedly -- and I've asked for documentation -- but AzureStack does not support the instance meta-data service.

[pekramp]

Allegedly -- and I've asked for documentation -- but AzureStack does not support the instance meta-data service.

got the documentation for you https://docs.microsoft.com/en-us/azure-stack/user/azure-stack-vm-considerations?view=azs-2002

Azure Instance Metadata Service | The Azure Instance Metadata Service provides info about running VM instances that can be used to manage and set up your VM. | The Azure Instance Metadata Service isn't supported on Azure Stack Hub.

[darkmuggle]

As it turns out, we need to implement check-in support. FCOS will boot, but it will NOT check-in and get a hostname.

[darkmuggle]

Since this AzureStack and its not a supported variant (AFAIK), I'm calling this a feature request and NOT a bug. Unless other victim are eager to work on this, I'd like to volunteer myself.

Work on this is tenatively scheduled for the 4.7 OCP cycle.

[darkmuggle]

/cc @cfBrianMiller

[lucab]

option private_245 => 'a8:3f:81:10'

This in fact 168.63.129.16. So, bad that we don't have #146 but good that the fallback worked there too.

http://169.254.169.254/metadata/instance/compute/name?api-version=2017-08-01&format=text

According to coreos/fedora-coreos-tracker#476 (comment) the problem is with the API version. Which is weird because the (Azure) platform docs at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service#versioning explicitly mention the version we are using. See https://docs.microsoft.com/en-us/azure-stack/user/azure-stack-vm-considerations?view=azs-2002#api-versions on API versions for AzureStack.

Going a bit further, the hostname is the simplest logic on Azure, so it's concerning that already this one fails on AzureStack. How do SSH keys logic and boot check-in logic behave on such platform?

[lucab]

Which then makes me wonder, where does an AzureStack instance get its hostname? Is that in the DHCP options?

[darkmuggle]

Now that Ignition [1] treats Azure Stack as a separate platform, we might have "just enough" to get FCOS/RHCOS booted on Azure{Stack,Hub} [1a, 1b]. The provided OVF from Microsoft looks suspect to me; the XML looks like its describing a Windows instance. Regardless the OVF XML given to us for AzureStack deviates substantially from what we know exists on Azure.

I started a stub [3], but after looking FCOS [4] packaging and RHCOS's previous failure to boot (caused by Afterburn checking in as if it was on AzureStack) is really superfluous.

The next steps are:

• Confirm that the OVF provided by MS is, in fact, from a Linux VM
• Attempt to boot RHCOS 4.6 or FCOS and see what happens

[1] https://github.com/coreos/ignition/blob/master/internal/providers/azurestack/azurestack.go
[1a] caveat emptor: this has not been tested on Azure Stack
[1b] caveat emptor: "just enough" is assumed to mean basic function means booting to a console. No Afterburn support. Remote access would be dependant on SSH keys provided by Ignition. Node is likely unusable beyond a POC.
[2] #463 (comment)
[3] 40f00e8
[4] https://src.fedoraproject.org/rpms/rust-afterburn/blob/master/f/rust-afterburn.spec#_49-53 uses the defaults set in
https://github.com/coreos/afterburn/blob/master/systemd/afterburn-checkin.service which would not apply to AzureStack

[darkmuggle]

/cc @ashcrow @miabbott

[prestist]

Done in #561