Add rancher_host resource type

[raphink]

Add rancher_host resource type

This adds a rancher_host resource type.
For now, the goal is to detect if the host already exists,
so that it can be purged cleanly when the host is deprovisioned.

The typical use is to create both an instance (e.g. aws_instance)
and a rancher_host resources with the same hostname. The rancher_host
resource will detect when the agent has registered itself.

When removing the host, both the instance and the rancher_host
resources can be removed, ensuring the host is purged from Rancher.

In future versions, this could support creating hosts as well.

[raphink]

/cc @johnrengelman any take on this?

[johnrengelman]

Hmm, I see what you're trying to do here, but personally I wouldn't use TF to manage these things because I think the experience would be frustrating with TF not creating the host. You're effectively using the Create function to do an Import which seems like it would lead to potential issues.

[johnrengelman]

I think the if we were to implement this resource, then the only appropriate way to do it would be to call the host provisioning APIs in Rancher and manage the host that way.

[johnrengelman]

I think this is going to lead us into the conversation about supporting the v2-beta api though because hosts creation is quite a bit different in the 2 api version. Which I'd be interested in @stack72's opinion on how that should be supported in TF.

1. Create a new rancher-v2 provider
2. Create resources that specify the version - i.e. rancher_stack_v2.foo vs rancher_stack.foo
3. Provide a configuration option on which API version to use and then only allow some resources to be created with the v2 API.
4. Try to transparently detect the API version under the covers - i.e. try the v2-beta api and use it if it works.

[cpoole]

@johnrengelman I vote for for option 3.

The only issue I see there is if you change the api version from v1 to v2 upgrade logic would need to be created (I assume that would require logic for destroying a v1 host and creating a new v2 host).

[johnrengelman]

@cpoole I don't believe that's the case in Rancher. A Host created in Rancher is available under either the v1 or the v2-beta api. It's just changing the API to do those things (the JSON definition and such).

[raphink]

Pretty sure of that, too (re v2). By the way, while the v2 API is marked beta, it is finalized and will not move (confirmed from Rancher employee).

@johnrengelman I do want to manage hosts in Terraform though, so that I can autoscale some environments cleanly, which is not possible if I can't remove hosts from Rancher when I shut down nodes. And using rancher hosts to create them is not a good option imo, as it will dynamically create security groups and such, which won't be purgeable in Terraform, so I'd rather control how things are done cleanly, using Terraform.

[johnrengelman]

@raphink that's How I manage hosts as well...Use TF to create a Launch Configuration and ASG so when the instance launches it joins in.

In this case, TF would never come into play with the hosts and I image an out-of-band process to reap hosts would be a better solution than using TF to do (just IMO). I've been looking at this - https://github.com/ampedandwired/rancher-reaper but haven't tried it out yet.

[cpoole]

I agree with @johnrengelman. We have a lambda function that does this here at Daqri. I'll try and opensource it by end of next week.

[mcanevet]

A rancher_host resource would not only allow to purge it from the Rancher API on instance removal, but also allow to manage host labels from TF which would be cool.
So I think this resource is a good idea.

[stack72]

@raphink / @johnrengelman

Is this ready to merge? If so, please can it be rebased?

[raphink]

@stack72 I'll have a look to see what's missing (and rebase)

[raphink]

Just fixed and rebased.

[raphink]

Example usage:

resource rancher_host "wrk8" {
  name           = "wrk8"
  description    = "my fabulous machine"
  environment_id = "1a113948"
  hostname       = "wrk8.example.com"
}

[stack72]

@raphink still failing i'm afraid ;)

[raphink]

Ok I'll need to check. I'll also add support for host labels.

[raphink]

@stack72 I added host labels support. I've kept it (so far) as two patches, because there's a little hack linked to rancher/rancher#8165. Ideally, I'm hoping Rancher Labs will store their computed labels in another API so we don't need to filter these ro_labels, but in the meanwhile I see no other way of managing them idempotently.

Also, build is now 💚

[stack72]

Thanks for all the work here @raphink :)

[raphink]

Thanks for merging!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.