rancher v2.0 support

[sc0ttruss]

Hi, Was trying to use terraform with rancher2.0. Seems they have added cluster as well as environment and removed the use of "cattle" orchestration. I believe cluserid is missing, and this will be something that is probably required in the terraform provider. Maybe you are aware already. The current error I receive is below:

terraform apply
rancher_environment.dev: Creating…
description: “” => "Development environment"
member.#: “” => ""
name: “” => "dev"
orchestration: “” => "cattle"
project_template_id: “” => ""
Error applying plan:

1 error(s) occurred:

    rancher_environment.dev: 1 error(s) occurred:

    rancher_environment.dev: Bad response statusCode [422]. Status [422 Unprocessable Entity]. Body: [baseType=error, code=MissingRequired, fieldName=clusterId] from [http://192.168.243.143:8080/v3/projects]

[cloudnautique]

The provider will need to be updated to support Rancher 2.0. The cluster / environment concepts have been changed quite a bit. Rancher 2.0 is still in preview, I would stick with 1.6.x for anything outside of playing.

[raphink]

Should this be a breaking change like we did from v1 to v2, or should there be new resource types for v3?

[mcanevet]

I think we should support both API for a few months. Maybe we could rename resources with _v2 and create new _v3 resources for v3 API just like what is done in OpenStack provider?

[raphink]

I think using v2 for current and v3 for next could be very confusing for users who do not know about cattle API versions. Instead, I would prefer to have rancher2_* resources to support v3, as that is what users know.

[blaggacao]

I've seen migration functions in the cloudflare repo, maybe this is a way of dealing with it? https://github.com/terraform-providers/terraform-provider-cloudflare/blob/master/cloudflare/resource_cloudflare_record_migrate.go

[gaui]

Now that Rancher 2.0 is 89% complete to GA it soon will be ready for production use. It would be awesome to be able to set up everything with Terraform. Maybe collab with @yamamoto-febc and his awesome work done here: https://github.com/yamamoto-febc/terraform-provider-rke

[gaui]

Rancher 2.0 is GA

[bluemalkin]

Hi any ETA on when this provider will support v2.0 which is now GA ? Thanks

[mcanevet]

We'll unfortunately not have time to work on this in the next few weeks, but if someone want to propose a PR, we'll have a look at it. So no ETA yet.

[cloudnautique]

@raphink @mcanevet, I'm curious on your thoughts here.

The differences between Rancher 1.x and 2.x are significant since 2.0 has a heavy K8s bias now. In looking at it, I'm good with UX where rancher2_* prefixes the new resources, but the problem is the same client can not implement rancher_* and rancher2_* essentially leading to 2 separate providers from an implementation standpoint. (The underlying client libs are separate) Which from an end user standpoint could be unfortunate as just updating credentials and the URL, would lead to a sea of errors I'm sure.

My 2 cents is that it makes sense for two separate providers to exist 'rancher' and a 'rancher2' I suppose. That way a user can manage 1.x and 2.x installations simultaneously. Since the path forward for 1.x users is a migration there is likely going to be a period of overlap where users run both. I suppose this could be mitigated with reasonable module management.

Logistically, I think it would be nice if we could keep the code bases collocated, can we have 2 providers living out of this repository? Would it muddle the docs too much?

Is there an option that I'm not aware of? Do you have other thoughts?

[mcanevet]

This provider talks to the Cattle v2-beta API, so maybe it should have been named cattle instead of rancher. I'm not sure there is still a "Cattle API" in Rancher2. Maybe a Cattle v3 or something like that that would allow to create RKE clusters or others Rancher2 concepts. If this is the case, maybe we could suffix the resources names with _v3 (meaning Cattle v3) just like what is done in other providers (OpenStack for example) to support both Cattle v2-beta and Cattle v3 APIs (and other versions in the future). For example, if there is still a concept of "stack" in Rancher2, we could have a rancher_stack_v3 resource, that creates a stack using Cattle API v3 (and maybe rename or alias rancher_stack to rancher_stack_v2. Regarding k8s objects (namespaces, roles...), I think we should use and improve the kubernetes provider.

[gaui]

He's provisioning a RKE cluster (Rancher k8s): https://github.com/yamamoto-febc/terraform-provider-rke

[olljanat]

Looks that Rancher have project of this on their repository: rancher/terraform-modules#18 rancher/terraform-modules#19 rancher/terraform-modules#21 rancher/terraform-modules#22 rancher/terraform-modules#23 rancher/terraform-modules#24 rancher/terraform-modules#25

[scarolan]

@raphink @mcanevet @cloudnautique Any thoughts on this provider? I got a request for support from a user today.

[cloudnautique]

We have started work and have an early version of the rancher 2 terraform-provider.

https://github.com/rancher/terraform-provider-rancher2

If you decide to try it out, please open issues on that repo.

[scarolan]

This is great news. Thank you @cloudnautique

[insekticid]

@cloudnautique it will be awesome!

[mihai-satmarean]

Need help here https://github.com/hashicorp/terraform/issues/16127#issuecomment-471488158 It worked when I replaced '~/.terraform.d/plugins/darwin_amd64/' with "$HOME/.terraform.d/plugins/darwin_amd64"

[WMcKibbin]

https://rancher.com/blog/2019/rancher-2-terraform-provider/