-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create local YAML from kops_kube_config data resource #438
Comments
Hello, what version are you using ? |
Hi! That was quick :) Not on the latest now that you say so. How is it relevant? Just curious
|
You're right, i misunderstood your issue, sorry. Not sure how to implement a |
I wonder how terraform can build a plan when the cluster does not exist yet ? |
Yes, was also big surprise to me that there is no Regarding the plan when there is no cluster yet: it's probably the same when there is already a cluster, namely initiate the providers with nulls. For planning that is apparently sufficient, but how terraform manages to fill it in just-in-time (re-initiate the providers?) such that the initial apply actually works, is a mystery to me. Probably the subsequent applies would also work if it weren't for the refresh. Already tried finding some way to defer the refresh of relevant resources, but no luck |
My current hack to write the kubeconfig to a local file and use it downstream (will need to have the resource "kops_cluster_updater" "updater" {
...
provisioner "local-exec" {
command = "kops export kubeconfig '${self.cluster_name}' --state 's3://${local.state_bucket_name}' --admin --kubeconfig ${local.kops_kube_config_filename}"
}
}
provider "kubectl" {
config_path = local.kops_kube_config_filename
}
provider "helm" {
kubernetes {
config_path = local.kops_kube_config_filename
}
} ref https://kops.sigs.k8s.io/cli/kops_export_kubeconfig/ EDIT: for the helm provider this works (apparently it reads the path lazily when applying a |
Problem
The
kops_kube_config
data source example will start causing errors after the first apply, ref hashicorp/terraform#27934Concretely, using dependent providers:
Will cause errors after the first successful apply, so upon the first subsequent apply:
kubectl.kubectl_manifest
:helm.helm_release
:Workaround
Manually delete these entries from
tfstate
after each applySuggestion
It would be cool to be able to have a
yaml_body
attribute in the data source, so that we can:kops_kube_config.yaml
file from the data sourceThe text was updated successfully, but these errors were encountered: