flux_install generates namespace manifest

[velkovb]

In the examples flux-system namespace is created via the kubernetes terraform provider. However, flux_install data resources generates a manifest for the flux-system namespace as well which leads to conflicts when destroying the resources.

If you remove the creation with the kubernetes terraform provider it leads to issues when creating the resources as it is async. I have left the namespace creation only in the kubernetes provided and amended the example like this:

locals {
  install = [for v in data.kubectl_file_documents.install.documents : {
    data : yamldecode(v)
    content : v
    }
    if yamldecode(v).kind != "Namespace"
  ]
  sync = [for v in data.kubectl_file_documents.sync.documents : {
    data : yamldecode(v)
    content : v
    }
  ]
}

terraform-provider-flux - 0.1.3 flux version - v0.13.1

[phillebaba]

The issue of removing the flux-system namespace is generally not related to the provider but more to the fact that Terraform will remove resources in the wrong order causing finalizers to reamin, blocking any deletion.

[bashims]

@velkovb this is interesting I will give it a try. We too struggle when doing a terraform destroy with the example provided. It leads to the classic "terminating namespace" issue. I noticed in the flux2 code the finalizers are handled as part of flux uninstall, so I am not entirely sure if this provider requires such a feature.

[bashims]

@velkovb filtering out the namespace creation seems to make things a bit better, but unfortunately destroying the kubectl_file_documents.apply resource still leaves orphaned finalizers. The following finalizers are consistently orphaned:

• kustomizations.kustomize.toolkit.fluxcd.io
• gitrepositories.source.toolkit.fluxcd.io

Running kubectl patch -n flux-system -p '{"metadata":{"finalizers":[]}}' --type=merge kustomizations.kustomize.toolkit.fluxcd.io/flux-system gitrepositories.source.toolkit.fluxcd.io/flux-system allows for the namespace to properly garbage collected.

I wonder of this provider should be be interacting with the kubernetes API like the flux command line tool does? e.g. uninstall.go This could be done by providing a Terraform resource instead of an integration layer with the terraform-provider-kubectl