[1/7] SchemaProcessor: integer/v0

[daltonmatos]

No description provided.

[lukerops]

Aqui você seguiu um caminho diferente do que eu tinha imaginado como evolução. Meu plano inicial era tornar a criação de CustomResourceDefintions dinâmica e sendo feita completamente através de parâmetros. Isso quer dizer que adicionar uma versão nova consistiria apenas em adicionar algo do tipo no arquivo CustomResourceDefinition/main.tf:

module "v1alpha2" {
  source = "./module"
  count  = split("/", var.manifest.apiVersion)[1] == "v1alpha2" ? 1 : 0

  path     = var.path
  manifest = var.manifest

  type_versions = {
    integer        = "v1"
    string         = "v1"
    bool           = "v1"
    array          = "v0"
    reduced_array  = "v0"
    object         = "v0"
    reduced_object = "v0"
    root_object    = "v0"
  }
}

Isso quer dizer a chamada interna dos módulos do schemaProcessor não podem ser feitas com source ../../../schemaProcessor/integer/v0/processor, mas sim com ../../../schemaProcessor/integer.

Isso também quer dizer que os módulos presentes no schemaProcessor/XXXX precisarão identificar quando o que está sendo chamado é para cair no processor ou no validator. Hoje, a interface de comunicação interna (definida no PR) é dada por:

object({
  type        = string     # tipo do elemento
  version     = string     # versão do validador utilizado para o elemento
  validations = object({}) # objeto contento as configurações extras de validação de cada tipo
  subItem     = object({}) # instância do mesmo objeto com informações do subItem 
})

Essa interface já não nos atende mais, portanto, sugiro a adição de um campo novo, ficando:

object({
  action      = string     # ação a ser tomada pelo schemaProcessor (schemaValidation / schemaGeneration)
  type        = string     # tipo do elemento
  version     = string     # versão do validador utilizado para o elemento
  validations = object({}) # objeto contento as configurações extras de validação de cada tipo
  subItem     = object({}) # instância do mesmo objeto com informações do subItem 
})

Essa interface nos abre a possibilidade de criação de novas ações no futuro, caso se mostre viável.

[daltonmatos]

Interessante! Mas tenho uma dúvida:
Em um código como esse:

module "v1alpha2" {
  source = "./module"
  count  = split("/", var.manifest.apiVersion)[1] == "v1alpha2" ? 1 : 0

  path     = var.path
  manifest = var.manifest

  type_versions = {
    integer        = "v1"
    string         = "v1"
    bool           = "v1"
    array          = "v0"
    reduced_array  = "v0"
    object         = "v0"
    reduced_object = "v0"
    root_object    = "v0"
  }
}

O código do module, que estará em ./module faria algo nessa linha?

module "integer" {
  source  = ".././schemaProcessor/integer/${var.type_versions.integer}/"

  action = "processor"
  path = var.path
  manifest = var.manifest
}

e com isso, internamente, o módule .././schemaProcessor/integer/v1/ olharia o var.action e instanciaria o sub-modulo correto?

Seria algo assim o caminho?

[lukerops]

Minha ideia consiste em:

O CustomResource seria:

module "v1alpha2" {
  source = "./module"
  count  = split("/", var.manifest.apiVersion)[1] == "v1alpha2" ? 1 : 0

  path     = var.path
  manifest = var.manifest

  type_versions = {
    integer        = "v1"
    string         = "v1"
    bool           = "v1"
    array          = "v0"
    reduced_array  = "v0"
    object         = "v0"
    reduced_object = "v0"
    root_object    = "v0"
  }
}

O ./module seria:

module "integer" {
  source  = "../../schemaProcessor/integer"

  action   = "processor"
  path     = var.path
  manifest = var.manifest
  ...
}

O schemaProcessor/integer seria:

module "v0" {
  source = "./v0"
  count  = var.schema.version == "v0" ? 1 : 0

  action   = var.action
  path     = var.path
  manifest = var.manifest
  ...
}

só então chegaria no schemaProcessor/integer/v0:

module "processor" {
  source = "./processor"
  count  = var.action == "processor" ? 1 : 0

  path     = var.path
  manifest = var.manifest
  ...
}

---

O que estou pensando agora é que eu falei besteira. O schemaValidation atual tem a interface:

variable "metadata_name" {
  type = string
}

variable "path" {
  type = string
}

variable "field_path" {
  type = string
}

variable "manifest" {
  type = any
}

variable "schema" {
  type = any
}

O que eu mandei antes contempla apenas o schema.

Acredito que para o schemaProcessor teremos que repensar essa interface e como é a comunicação interna entre os módulos 🤔

[daltonmatos]

Dúvida: Acha que a ideia do schemaProcessor que está nesse PR pode servir de passo intermedíario até chegarmos nessa ideia final de CRD versions mais dinâmicas e mais simples de implementar?

[lukerops]

Acho sim. Podemos usar dessa chamada direta do módulo como tu fez para fazer a transição até chegar na versão dinâmica final. Só tem que ir pensando nas interfaces e ir tentando chegar em uma interface estável para os módulos.