lukerops / tf-gapi Goto Github PK

Hoje apenas os CRDs que possuem manifestos de recursos aparecem no agrupamento do output. Isso obriga quem está usando o módulo a fazer o acesso usando o try para garantir que o código não quebre.

Um comportamento melhor seria todos os CRDs estarem nesse output e caso não exista nenhum manifesto desse CRD, adicionar apenas um objeto vazio.

Exemplo do uso atual:

locals {
  v1alpha1 = {
    for name, resource in try(module.tf_gapi.resources["<apiGroup>"]["<kind>"], {}) : name => resource
    if resource.apiVersionName == "v1alpha1"
  }
}

Hoje o projeto usa a mesmo interface do Kubernetes para o CustomResourceDefinition, porém, chegamos aos seguintes problemas:

• Vários campos não são suportados;
• Por questões de limitação do HCL, o schema é mais limitado, não sendo tão poderoso quanto ao do Kubernetes;
• Alguns campos possuem valores/nomes que não fazem sentido no contexto desse projeto (ex: scope: Cluster).

Devido a esses pontos é melhor criar um schema novo para o CustomResourceDefinition.

Com a modificação do projeto os exemplos de uso precisam ser corrigidos.

Após a tarefa (#1) o formato de saída da validação dos CustomResourcesDefinitions foi alterado. Portanto, a validação dos recursos precisa ser alterada também.

Depende de:

• #5

O output do projeto precisa ser modificado para agrupar os recursos, assim, gerando um map na seguinte ordem:

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

O módulo de validação, e o próprio projeto, vão retornar uma lista de recursos, porém, é necessário definir o formato do objeto terraform que será exportado.

Contexto:

O processamento dos manifestos é separado em 2 fluxos diferentes:

1 - O processamento dos CustomResourceDefinitions

Consiste na leitura do manifesto, verificando a estrutura do mesmo e gerando o schema que será utilizado na validação de outros manifestos.

2 - O processamento dos manifestos de recursos

Consiste na validação do manifesto utilizando as regras presentes nos schemas gerados no passo anterior.

Como se é percebido, o resultado de um passo está completamente acoplado com o próximo, o que torna necessário o casamento dos dados entre eles, porém, da forma que está sendo implementado pelo PR #14, as regras dos dois fluxos ficarão separadas, deixando a manutenção desses códigos mais complicada.

Proposta

A ideia proposta nessa issue é a adição de um novo conceito chamado de Schema Processor. O Schema Processor será um bloco de código, único para cada tipo de dado, que terá a função de ler as regras do CustomResourceDefinition, gerar um schema e depois validar se um manifesto cumpre as regras do schema gerado.

Como antes, isso ocorrerá em 2 etapas, como descrito no diagrama:

O que a proposta resolve?

Essa proposta resolve o espalhamento das regras de validação pelo código, além de tornar possível a reutilização do código de processamento do CustomResourceDefinition, tornando a criação de uma nova versão da interface YAML mais rápida, simples e fácil, evitando um "copia e cola" de vários arquivos.

A ideia é podermos definir um valor default para um campo qualquer. Essa possibilidade habilitará o uso de campo opcionais em um manifesto. Muitas vezes facilitando a escrita desse yaml.

Proposta

apiVersion: tf-gapi.lukerops.com/v1alpha1
kind: CustomResourceDefinition
metadata:
  name: serviceaccount.gcp.iam.stone.co
spec:
  group: gcp.iam.stone.co
  kind: ServiceAccount
  versions:
    - name: v1alpha1
      specSchema:
        type: object
        properties:
          id:
            type: string
          create:
            type: bool
            default: false

Acima uma proposta de como esse valor pode ser definido. Junto com o campo type: teríamos o campo default: com o valor padrão para esse campo.

Pontos de atenção

• Se tiver sido definido o campo default: ele precisa ter um valor. Não podemos definir um default vazio;
• Validar para confirmar que o valor default é compatível com o campo recebendo esse default. Por ex: Não podemos definir default: true para um campo type: integer;
• Avaliar se faz sentido ter valor default para type: object e type: array. Talvez array até seja comum ter default: [], talvez seja mais comum do que defaul: {} para type: object.
  • Um exemplo de defualt para array é a definição de uma role sem permissões adicionais. Nesse caso o campo de permissões poderia ser default: [].

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
      }
    }
  }
}