Modificar o agrupamento dos recursos

[lukerops]

Hoje o mapeamento leva em consideração apenas o apiGroup e kind, porém, para fazer a criação dos recursos é preciso fazer uma lógica para cada apiVersionName. Para facilitar essa lógica adicional, vamos mudar o agrupamento para:

resources = {
  (apiGroup) = {
    (kind) = {
      (apiVersionName) = {
        (metadata.name) = resource
      }
    }
  }
}

[daltonmatos]

Depois coloca aqui exemplos de uso desse novo agrupamento em comparação com o antigo.

Dúvida: O antigo será removido?

[lukerops]

Dúvida: O antigo será removido?

Sim. A ideia por trás do agrupamento inicial era usar o próprio manifesto como um objeto comum entre as versões, porém, isso obrigaria a ter múltiplos recursos separando a criação do recurso, já que versões diferentes podem lógicas diferentes para criação do recurso. Isso se tornou um problema devido à obrigatoriedade de um state mv sempre que houver a mudança de versão de algum recurso.

Como o recomendado agora é usar um objeto comum entre as versões, que não é mais o próprio manifesto, então, sempre vamos criar alguma lógica de mapeamento para cada versão do CRD. Devido a esse mapeamento, estou mudando o agrupamento dos manifestos, e assim, não forçar sempre o filtro por apiVersionNmae.

---

Formato de uso atual:

locals {
  resources = merge(
    {
      for name, resource in local.tf_gapi.resources["<apiGroup>"]["<kind>"] :
      name => {
        name  = name
        param = resource.spec.param
      }
      if resource.apiVersionName == "v1alpha1"
    },
    {
      for name, resource in local.tf_gapi.resources["<apiGroup>"]["<kind>"] :
      name => {
        name  = name
        param = resource.spec.enable_param ? "fixed" : null
      }
      if resource.apiVersionName == "v1alpha2"
    }
  )
}

resource "tf_resource" "example" {
  for_each = local.resources

  name  = each.value.name
  param = each.value.param
}

Formato de uso da proposta:

locals {
  resources = merge(
    {
      for name, resource in local.tf_gapi.resources["<apiGroup>"]["<kind>"]["v1alpha1"] :
      name => {
        name  = name
        param = resource.spec.param
      }
    },
    {
      for name, resource in local.tf_gapi.resources["<apiGroup>"]["<kind>"]["v1alpha2"] :
      name => {
        name  = name
        param = resource.spec.enable_param ? "fixed" : null
      }
    }
  )
}

resource "tf_resource" "example" {
  for_each = local.resources

  name  = each.value.name
  param = each.value.param
}

[daltonmatos]

Um dúvida aqui: Essa mudança é uma breaking change? Pergunto isso pois se for temos que pensar no caminho de atualização de projetos que já estão rodando. Imagina ter que ajustar um projeto, todo de uma vez, que possua uns 30 CRDs por exemplo.

Se podermos fazer algo nessa linha:

locals {
  resources = merge(
    {
      for name, resource in local.tf_gapi.resources["<apiGroup>"]["<kind>"][*] :
      name => {
        name  = name
        param = # Aqui vai um código que suporta as duas versions
      }
    }
  )
}

resource "tf_resource" "example" {
  for_each = local.resources

  name  = each.value.name
  param = each.value.param
}

Se quisermos ignorar as versions, tudo bem. Se não pudermos fazer acho que o ideal seria criar um segundo output para dar tempo para os projetos atualizarem.

Nesse caso os projetos poderiam ir, progressivamente, usando o output novo e depois de um tempo podemos de fato remover o output antigo e deixar apenas o novo. O que acha?

[lukerops]

Acho válido, só pensar em um nome que faça sentido para esse output novo