terraform-coop / terraform-provider-foreman

Terraform provider for Foreman
https://registry.terraform.io/providers/terraform-coop/foreman
Mozilla Public License 2.0
33 stars 31 forks source link

Since v0.5.x foreman_host.<name>.name is inconsistent #116

Closed togoschi closed 11 months ago

togoschi commented 1 year ago

With provider versions < 0.5.0 a reference of the foreman_host name attribute points to the short hostname. After upgrading to 0.5.x the name reference becomes inconsistent. An initial plan will still show the short name but apply will set the FQDN.

An example terraform snippet for this misbehaviour is this HashiCorp Vault PKI resource using a reference to name attribute of the foreman_host resource as common name attribute for the subject DN of the certificate

resource "vault_pki_secret_backend_cert" "dashboard" {
...
  common_name = foreman_host.osd[0].name
...
}

tf apply will lead to the following error

╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for vault_pki_secret_backend_cert.dashboard to
│ include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/vault" produced an invalid new value for
│ .common_name: was cty.StringVal("vxstocph101"), but now
│ cty.StringVal("vxstocph101.hcp-dev-infra.hanse-merkur.de").
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵
ERRO[0107] 1 error occurred:
    * exit status 1

Anyway the next tf apply will fix and create the failing resource.

But above all with 0.5.x i have to change common name attributes in all resources like above because the common name should be the FQDN in my deployment. With a version < v0.5.x the common name attribute pointed to "shortname.domain" ("${foreman_host.osd[0].name}.${data.foreman_domain.hcp-infra.name}") but after upgrading the provider i need to change the common name of these resources to foreman_host.osd[0].name as shown above because the name reference of the foreman_host resource points finally already to the FQDN

agriffit79 commented 1 year ago

I've just hit the same issue. It was introduced in 2fa9ff2 when the custom host unmashall function was removed.

It's really a bug in the Foreman API - you set one value and another is returned. But we'll have to figure out some way to handle it in the provider.

bitkeks commented 1 year ago

Hi, PR #121 introduces a possible solution to handle the name field.

It's really a bug in the Foreman API - you set one value and another is returned. But we'll have to figure out some way to handle it in the provider.

It's probably not a bug, but a feature. The setting append_domain_name_for_hosts does exactly what it says: you put in a short hostname and Foreman converts it to an FQDN. This FQDN is then returned to the provider. If you do not cut the domain part, the provider will be confused because it gave another input. This breaks if the returned value is used in the same apply workflow (Terraform uses the term "learned during apply").

bitkeks commented 11 months ago

Fixed in v0.6.0 and documented in README after merge of #132