Error: rpc error: code = Unknown desc = update dry-run for 'istio-system/demo-istiocontrolplane' failed: namespaces "istio-system" not found

[modevops]

Terraform, Provider, Kubernetes versions

Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-27T17:05:32Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.9-eks-d1db3c", GitCommit:"d1db3c46e55f95d6a7d3e5578689371318f95ff9", GitTreeState:"clean", BuildDate:"2020-10-20T22:18:07Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

Terraform version: + provider.kubernetes-alpha v0.2.1
Provider version:

+ provider.aws v3.20.0
+ provider.helm v1.3.2
+ provider.kubernetes v1.13.3
+ provider.kubernetes-alpha v0.2.1
+ provider.local v1.4.0
+ provider.null v2.1.2
+ provider.random v3.0.0
+ provider.template v2.2.0
Kubernetes version: 18.1

Affected Resource(s)

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.
I have already applied istio operator  crd's

resource "kubernetes_namespace" "istio-system" {
  metadata {
    labels = {
      name = "istio-system"
    }

    name = "istio-system"
  }

}

resource "helm_release" "helm_istio-operator" {
  name       = "istio-operator"
  repository = "${path.module}/charts"
  chart      = "istio-operator-helm"
  version    = var.chart_version
  create_namespace = true
  namespace  = "istio-operator"
  timeout    = 1200
  values = var.values



  set {
    name  = "tag"
    value = "var.istio_tag"
  }

  set {
    name  = "operatorNamespace"
    value = "istio-operator"
  }



  dynamic "set" {
    iterator = item
    for_each = var.set == null ? [] : var.set

    content {
      name  = item.value.name
      value = item.value.value
    }
  }

  dynamic "set_sensitive" {
    iterator = item
    for_each = var.set_sensitive == null ? [] : var.set_sensitive

    content {
      name = item.value.path
      value = item.value.value
    }
  }


}


resource "kubernetes_manifest" "istiooperator__istiocontrolplane" {
  provider = kubernetes-alpha
  manifest = {
    "apiVersion" = "install.istio.io/v1alpha1"
    "kind" = "IstioOperator"
    "metadata" = {
      "name" = "demo-istiocontrolplane"
      "namespace" = "istio-system"
    }
    "spec" = {
      "profile" = "demo"
    }
  }

  depends_on = [helm_release.helm_istio-operator, kubernetes_namespace.istio-system]
}

Debug Output

Panic Output

Error: rpc error: code = Unknown desc = update dry-run for 'istio-system/demo-istiocontrolplane' failed: namespaces "istio-system" not found

Steps to Reproduce

when i do a terraform plan or apply i get the above error.

Expected Behavior

What should have happened? It should act like kubernetes and helm provider and ignore namespace. I have in the config file to create the namespace. I am so disappointed in kubernetes-alpha release it does not even have the same functionality as the helm or kubernetes provider. We desperately need a solid provider like the kubernetes-alpha release but seems to be a low priority to hasicorp maybe i need to find a different tool. This processes is taking to long and would expect it would at least have the same functionality as helm or kubernetes provider. It really frustrating when you are trying to champion a vendor to be bitterly disappointed when trying to use their tool on major initiative and it sucks. Kubernetes is growing fast and terraform support is poor at best.

Actual Behavior

What actually happened? Error: rpc error: code = Unknown desc = update dry-run for 'istio-system/demo-istiocontrolplane' failed: namespaces "istio-system" not found

I do not mean to be so critical but this provider along with tfk8s has such great potential but is moving to slow. Also right now this is to me in an an unusable state and is over validating. If I have a block creating a namespace and with a dependons on block creating the namespace I should not got an error namespace not found when I do a terraform plan. This provider needs to be more dynamic. I can with helm and kubernetes provider have namespace block and apply and not get this error. Please make this provider a higher provider and get it in a usable state we really need it.

[modevops]

If i use kube_manifest namespace it works but I still get

Error: rpc error: code = Unknown desc = no matches for install.istio.io/v1alpha1, Resource=IstioOperator

but it is over validating again.

A major use case for kube_manifest is crds and if we cannot do crds then what is the use for it? Can we add a flag for crds so that it does not try to validate kind in the manifest during terraform plan? We need this provider to be more dynamic. I really need this for crds.

resource "kubernetes_manifest" "namespace_istio_system" {
  provider = kubernetes-alpha
  manifest = {
    "apiVersion" = "v1"
    "kind" = "Namespace"
    "metadata" = {
      "name" = "istio-system"
    }
  }
}


resource "helm_release" "helm_istio-operator" {
  name       = "istio-operator"
  repository = "${path.module}/charts/manifests/charts"
  chart      = "istio-operator"
  version    = var.chart_version
  #create_namespace = true
  #namespace  = "istio-operator"
  timeout    = 1200
  wait = true
  #values =  [file("${path.module}/templates/values.yaml")]


  set {
    name  = "tag"
    value = "1.8.1"
  }

  set {
    name =  "operatorNamespace"
    value = "istio-operator"
  }

  set {
    name =  "watchedNamespaces"
    value = "istio-system"
  }

  set {
    name = "hub"
    value = "docker.io/istio"
  }




  dynamic "set" {
    iterator = item
    for_each = var.set == null ? [] : var.set

    content {
      name  = item.value.name
      value = item.value.value
    }
  }

  dynamic "set_sensitive" {
    iterator = item
    for_each = var.set_sensitive == null ? [] : var.set_sensitive

    content {
      name = item.value.path
      value = item.value.value
    }
  }



}


resource "kubernetes_manifest" "istiooperator__istiocontrolplane" {
  provider = kubernetes-alpha
  manifest = {
    "apiVersion" = "install.istio.io/v1alpha1"
    "kind" = "IstioOperator"
    "metadata" = {
      "name" = "-istiocontrolplane"
      "namespace" = "istio-system"
    }
    "spec" = {
      "profile" = "demo"
    }
  }
  depends_on = [kubernetes_manifest.namespace_istio_system, helm_release.helm_istio-operator]
}

[Nainterceptor]

Same thing here for cert manager, if I deploy crd before using terraform, in the same terraform I add manifests to add ClusterIssuers that use this CRD, it results to a failure because terraform try to validate before the crd apply, without considering depends_on.

[modevops]

I already had the crd's applied and I was able to apply with kubectl but not with kube_manifest

[bluemalkin]

Same thing here for cert manager, if I deploy crd before using terraform, in the same terraform I add manifests to add ClusterIssuers that use this CRD, it results to a failure because terraform try to validate before the crd apply, without considering depends_on.

I'm getting exactly the same issue with cert-manager CRD for ClusterIssuer. Any known workarounds ?

[alexsomesan]

This is a well known limitation. The reason is that the alpha provider requires the namespace to be present AT PLAN TIME due to the way the plan is currently implemented in the provider. The next provider release will come with a different mechanism for doing this and remove the limitation.

In the mean time, the only reliable workaround is for the alpha provider resources to be applied in a different apply operation, after the namespace (and any other dependencies) have been created and are present in the state.

[imcitius]

Hi! Is there any plans or news on upcoming releases? This limitations is frustrating. :(

Thanks in advance!

[ivanov-aleksander]

This limition is real blocker. Do you have any plans to fix it?

[imcitius]

This provider does not have such limitation, and respects depends_on. https://registry.terraform.io/providers/gavinbunney/kubectl

[sveba]

We have this same problem when we try to plan/apply. I can paste some examples, but actually what matters more is, what is the future of the "alpha" provider? The last commit is from 3 months ago. We just need some information, so we can decide to use and support, as far as we can with PRs, or move away and look for other solutions.

[alexsomesan]

This class of issues should be fixed by the upcoming v0.3.0 in the next few days.

After that version is released, to establish the correct dependency between a namespace and it's corresponding resources, the name of the namespace should be passed to the resources via a resource reference. For example:

resource "kubernetes_manifest" "namespace_istio_system" {
  provider = kubernetes-alpha
  manifest = {
    "apiVersion" = "v1"
    "kind" = "Namespace"
    "metadata" = {
      "name" = "istio-system"
    }
  }
}

resource "kubernetes_manifest" "istiooperator__istiocontrolplane" {
  provider = kubernetes-alpha
  manifest = {
    "apiVersion" = "install.istio.io/v1alpha1"
    "kind" = "IstioOperator"
    "metadata" = {
      "name" = "-istiocontrolplane"
      "namespace" = kubernetes_manifest.namespace_istio_system.object.metadata.name
    }
    "spec" = {
      "profile" = "demo"
    }
  }
  depends_on = [helm_release.helm_istio-operator]
}

Note that the reference uses object and not manifest to source the value of name. This is important because the object attribute is populated after apply and instructs Terraform to correctly sequence the creation of the resources which resolves the "namespace not found" type of errors.