Uso de outra interface para o CustomResourceDefinition

[lukerops]

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.

[lukerops]

Após remover alguns campos que não fazem sentido no contexto do projeto, cheguei ao seguinte schema:

apiVersion: tf-gapi.lukerops.com/v1alpha1
kind: CustomResourceDefinition
metadata:
  name: <lowercase-kind>.<group>
spec:
  group: string
  kind: CamelCasedKind
  versions:
    - name: v1alpha1
      enabled: true
      deprecated: false
      specSchema:
        type: object
        properties:
          string:
            type: string
            minLength: 0
            maxLength: 50
            # O campo "pattern" foi removido da versão inicial do schema,
            # mas será implementado em versões futuras.
            # pattern: regex
          integer:
            type: integer
            minimum: 0
            maximum: 50
          bool:
            type: bool
          array:
            type: array
            minItems: 0
            maxItems: 10
            items:
              type: string | integer | object
          object:
            type: object
            properties:
              property:
                type: string | integer
          commonParams:
            description: string
            externalDocs: string

Nessa proposta, temos o campo deprecated que indicará quando uma versão foi depreciada, e com isso, quando for utilizada, um alerta será mostrado no plan, mas sem causar erro. Apenas o uso de versões desabilitadas (enabled: false) ocasionarão em um erro.

[daltonmatos]

Ficou massa! Mais simples e com mais campos que de fato serão usados. Eu ainda tiraria campos que não possuem implementação, tipo o pattern do tipo string. Acho que quanto mais simples melhor para quem terá que escrever um CRD.

Dúvida: Existe o conceito de campo opcional? Ou atualmente todos os campos que estão presentes no schema precisam receber algum valor explicitamente?

[lukerops]

Vou manter como v1alpha1 apenas os campos que serão implementados agora. Para agilizar a versão alpha do projeto, também vou remover algumas opções, então, a princípio, não existirão campos opcionais e valores padrão. A ideia é ir evoluindo e complementando essa proposta inicial com essas opções em versões futuras desse schema.

Eu ainda tiraria campos que não possuem implementação, tipo o pattern do tipo string

Expliquei a cima qual a ideia desse schema inicial, então, faz sentido essa remoção, já que não será implementado agora.

[daltonmatos]

Perfeito! 👍🏼🎉🎉