cloud-netconfig-azure

[rjschwei]

We need to dynamically determine the available API versions.

[jgleissner]

In theory, selecting the API version the script was developed with is the right thing, as it makes sure the script does not break when there is an API change. The issue I ran into that an existing version seemingly disappeared may be that the version I used was never officially released.

Microsoft announced the metadata service availability here: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service

The announcement reads that 2017-04-02 and 2017-08-01 are the supported API versions, with 2017-04-02 the only one that is supported in the disconnected regions, so I suggest we use that version. We could implement a fallback mechanism that selects a version automatically in case the tested one goes away, but of course API changes may break the scripts in odd ways so perhaps it would be preferable to explicitly error out in that situation.

The EC2 back-end uses the latest API, which I think we should change to a specific version too so we make sure we use a tested version that works with the scripts.

Another issue is that metadata is not available on ASM (yet, according to https://azure.microsoft.com/en-us/blog/announcing-general-availability-of-azure-instance-metadata-service/). I could swear that I've seen metadata available in a classic VM as I actually tested cloud-netconfig in ASM as well, but perhaps that was experimental and temporary. This means that cloud-netconfig doesn't currently work properly in classic VMs.

[rjschwei]

I am OK with a hard coded API version as the preferred version, however given that we know we are looking for specific data in a specific format I think that if for whatever reason the preferred API is not available we should try harder and find a different version to see if we can get the data. This applies to both frameworks.

As to the ASM problem. It is no longer possible to launch VMs in Azure using the web console, thus ASM VMs can only be launched via command line. I am not aware of any supported command line tool that uses ASM that allows the user to have multiple network interfaces. Thus I think we do not need to worry about the metadata service in ASM, as long as the code exits gracefully if there's no data, that IMHO means to simply write an ifcfg-eth0 setup for DHCP.

[jgleissner]

I've update the code to use explicitly use tested and supported versions in EC2 and Azure. I'll look into implementing a fallback mechanism when I get a chance. Since assumptions made about where the data is and how it is formatted don't necessarily hold true when using an untested version, we'll need to add some more sanity checks where metadata is processed.

Regarding ASM, the node based azure cli allows running instances with multiple NICs, but I agree this is probably low priority. The code checks whether metadata is available and exits if not, so I think we're good.