providers: add initial hetzner cloud support

[dedene]

Along with:

• providers: add support for hetzner cloud afterburn#125
• coreos-base/oem-hcloud: add hetzner cloud support coreos-overlay#3490
• image_to_vm: add initial hetzner cloud support scripts#859
• platforms: add initial hetzner cloud support container-linux-config-transpiler#164
• dracut: add hetzner cloud support bootengine#150

This will greatly enhance working with CoreOS on the Hetzner Cloud.

[coreosbot]

Can one of the admins verify this patch?

[dedene]

@LKaemmerling Would you mind taking a look at this from the Hetzner Cloud team? Feel free to suggest changes.

[ajeddeloh]

This LGTM at first glance except maybe change the key from hcloud to hetznercloud or hetzner since there may be other h* clouds out there. I don't have a hetzner cloud account to actually test any of it however.

[LorbusChris]

While I personally very much appreciate the Hetzner Cloud offerings, I'm not sure Ignition should add support for arbitrary providers (i.e. those that aren't of systemic relevance, which is a compromise we are trying to mitigate anyways). AFAIK Hetzner is OpenStack-based. Could this be abstracted in any way?
(Sorry @dedene for my ignorance, this is just a strong opinion I hold loosely; completely open for discussion :)

[dedene]

Thanks for the feedback. I did quite a lot of testing on their cloud and it seems to work very good.

@LorbusChris No worries, it's always good to have an open debate about these kind of things. The Hetzner Cloud is unfortunately not OpenStack based. If it would have, it could absolutely be using the current openstack support in Ignition. It's something proprietary based on KVM I believe (i.e. https://twitter.com/hetzner_online/status/958982561644072961). But there metadata service is rather EC2-ish:

• Most of it at the endpoint http://169.254.169.254/2009-04-04/<...> behaves the same, except for the public-keys: where the EC2 returns a list of users and next you need to fetch each ssh-key for the users, the Hetzner Cloud implementation simply returns an array of ssh keys.
• There is also another endpoint at http://169.254.169.254/hetzner/v1/userdata and http://169.254.169.254/hetzner/v1/metadata but these return a YAML-version of all metadata, for which there is currently no oem-id I could configure to read this.

Although to support their metadata service, most relevant changes are in coreos-metadata. But I thought it would be nice to have full support.

About the hcloud oem id, I chose this as in most of their other integrations they are referred to as hcloud: Terraform (https://www.terraform.io/docs/providers/hcloud/index.html), Packer (https://www.packer.io/docs/builders/hetzner-cloud.html), the CLI-tool, all their Go-libraries, etc. But I feel fine if you'd like me to change this to hetznercloud. Should I change it or can it remain at hcloud?

[ajeddeloh]

Ah, if hcloud is in use in other projects then that's fine.

@LorbusChris I don't have any qualms adding misc cloud support to Ignition especially if

• Someone else does the work to implement it
• It's a small an non-invasive addition

This LGTM.

@dedene Are you able to test these changes?

[dedene]

@ajeddeloh I did some initial tests already on the Hetzner Cloud, but I'll do some further testing over the weekend and let you know.

stale

[dedene]

I did some further testing and seems to work fine.

However, see coreos/afterburn#125 (comment): unfortunately the Hetzner Team can't or won't confirm which of the existing user-data endpoints (the EC2-ish http://169.254.169.254/2009-04-04/user-data endpoint or the Hetzner Cloud-specific http://169.254.169.254/hetzner/v1/userdata) will be stable (although I think removing either one of them will lead to many customers having to change their automation scripts) in the near future. So maybe it is best to wait for merging this until we have confirmation which endpoint can be used for the user-data (and the meta-data needed for coreos-metadata).

I hope we will get more information soon.

[ajeddeloh]

@dedene did you ever here back on a stable API to use?

[bgilbert]

@ajeddeloh coreos/afterburn#125 (comment) confirms that several metadata endpoints are now stable, but the userdata endpoint isn't mentioned.

@thcyron Is there now a stable endpoint for instance userdata?

[thcyron]

I would suggest you use the same endpoints our coud-init data source uses. That won’t change because it would break existing setups.

[ajeddeloh]

@dedene This LGTM. If you want to change it to the same endpoint that cloudinit uses and rebase, I can merge it.

[dedene]

Awesome, I'll look at it asap!

[LKaemmerling]

@dedene we have the metadata endpoints now documented: https://docs.hetzner.cloud/#overview-server-metadata

[zerodayyy]

@dedene @bgilbert @ajeddeloh can we get this merged? All the missing documentation is present now. This PR has not seen activity since April.

[ajeddeloh]

Needs a rebase, otherwise LGTM

[LKaemmerling]

@dedene any way we could get this ready :)? I can't get in touch with you, so hopefully, this ping helps :)

[mstarostik]

Any chance to get this resolved and reviewed? Would be great to get this in.
And to complement this, @LKaemmerling would be nice if hcloud supported creating servers with an initially blank boot volume and provisioning via custom iPXE script/URL (e.g. matchbox)...

[flokli]

I'm also very interested in this.

@dedene could you give this a rebase? Also, happy to take this over if you don't want to pursue this any further.

[bgilbert]

xref #1262

[travier]

Thanks for opening this PR. This should be fixed with #1707. Feel free to re-open if something is missing. Thanks!