TF aborts after performing manual changes / Rancher API return values / ???

[flypenguin]

Hi there,

Terraform Version

0.10.8

Affected Resource(s)

• rancher_environment (?)
• rancher_registration_token (?)

Terraform Configuration Files

# only the essential parts

resource "rancher_environment" "test" {
  name = "Test"

  #project_template_id = "${var.rancher_cattle_project_template_id}"
  orchestration = "cattle"
}

resource "rancher_registration_token" "compute" {
  name           = "Environment 'Cattle0' nodes"
  environment_id = "${rancher_environment.test.id}"
}

Debug Output

• https://gist.github.com/flypenguin/c6072a2baf493e10f706ec912f4eccde

Expected Behavior

Terraform should just continue, and update the environment as described in the HCL files.

Actual Behavior

Terraform aborts with this error message:

Error: Error refreshing state: 1 error(s) occurred:

* rancher_registration_token.compute: 1 error(s) occurred:

* rancher_registration_token.compute: rancher_registration_token.compute: Bad response statusCode [403]. Status [403 Forbidden]. Body: [code=Forbidden, message=Forbidden, baseType=error] from [https://rancher0.c11h-wonderwoman.de/v2-beta/projects/1a7/schemas]

Steps to Reproduce

I am not sure, honestly. This is how I would do it:

1. Create an environment in Rancher with Terraform.
2. Delete the environment manually.
3. terraform destroy

Important Factoids

The API browser gives the following behavior:

• there is no project with ID "1a7", there is only one with "1a5".
• I don't actually know why.
• If I access the link above, I also get "403", which is wrong, cause I am authenticated. I think 404 would be way more appropriate.

References

N/A

[mcanevet]

@raphink I think we must check if the env is removed in the read function like we did for rancher_stack resource for example.

[mcanevet]

@raphink it looks like it is already implemented https://github.com/terraform-providers/terraform-provider-rancher/blob/master/rancher/resource_rancher_environment.go#L155-L159 but @cryptobioz also noted this failing behavior. Any idea?