no cloud agents: azure

[dustymabe]

In #12 we decided that we'd like to try to not ship cloud agents. This ticket will document investigation and strategy for shipping without a cloud agent on the azure cloud platform.

See also #41 for a discussion of how to ship cloud specific bits using ignition.

[arithx]

So far the only required thing we know of is the check-in process that must be done every boot. Given that it's every boot this makes it unlike Packet and should not be part of Ignition. Currently looking into if it should live inside of coreos-metadata or as a separate service.

The check-in is essentially a POST call to a metadata server that's IP address can be found in DHCP option 245. With a modification to /var/lib/dracut/modules.d/40network/dhclient.conf to change the request to not specify options we can parse out option unknown-245 from /run/initramfs/state/var/lib/dhclient/dhclient-<uuid>-eth0.lease and then parse that into the ip address of the metadata server.

I need to test the POST call next to change the state of the machine. It looks like it should just require a POST call to /machine?comp=health.

Once all of this is tested & working we can decide whether we want to continue with state file parsing or switch to a different method like directly parsing DHCP broadcasts.

[dustymabe]

thanks @arithx for the info!

[arithx]

Here's a bash script & an example systemd unit to run it on every boot that can do the check-in process: https://gist.github.com/arithx/dae948f3d9558c8863ac55cba3391eb4

The machine correctly moves from Creating to Running in Azure post-boot.

Even still there are no nameservers added to the machine despite the option domain-name-servers being populated in the DHCP lease. It does look like it was set in the initramfs resolv.conf (/run/initramfs/net.eth0.resolv.conf was populated w/ the correct nameserver), so some additional features might need to be added.

[dustymabe]

Here is where I think we are on this ticket:

1 - We've identified one gap (i.e. checkin) where not having the agent causes nodes to not run properly.
2 - This gap can be worked around temporarily using a hack
3 - This gap will be fixed longer term by coreos/afterburn#120
4 - There is one other gap, but we have decided that the functionality is not necessary right now and will wait for a feature request from users before tackling that problem

This means all gaps have been identified and related work is in open issues.

@arithx can we open a PR to the design doc to document that we plan to not ship a cloud agent for azure and list out the two gaps and how we plan to fill them?

[arithx]

@dustymabe yup, I'll open up a PR for it.

[dustymabe]

closing this out since remaining issues are tracked elsewhere and design doc PR has merged. Thanks @arithx