-
Notifications
You must be signed in to change notification settings - Fork 966
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
Provider 1.11.0 fails to initialize #759
Comments
The error message I was seeing was
|
Can you please post provider configuration blocks here? |
tf aws provider version : 2.48.0
|
got the same error like @bowczarek with Terraform v0.11.14
|
Yeah, nothing special:
|
@bowczarek Does setting |
Also, what's the reason for using both a |
I am using |
@alexsomesan seems like adding Still need to test applying some fake changes to see if it works there as well. |
I have the same issue, mine will initialize, but the plan fails with file cannot be found in the config dir. I have many clusters and use Here is my provider:
|
@dubb-b see my previous remark |
I'm having the same issue. In fact this broke my live demo 😄
|
i tried with but now i get this error: module.components.provider.kubernetes: Failed to initialize config: invalid configuration: no configuration has been provided Again my provider, i use tf version v0.11.14
|
I'm looking into the EKS case. @ruizink Sorry about your live demo. Pinning provider versions to known good configurations is a best practice we encourage users to adopt. It would help avoid situations like this from happening in the future. |
I just confirmed the following configuration to be valid and working, using minikube.
Please double-check that your interpolation expressions are resolving to valid values. |
@immae1 I tested above configuration with TF 0.11.14 against minikube.
|
it seems that this PR #690 broke config init (initializeConfiguration) |
Example of broken config: (terraform-aws-eks) |
logs:
|
Started having this issue today also. Error: Failed to initialize config: invalid configuration: no configuration has been provided
on modules/beta-private-cluster/auth.tf line 29, in provider "kubernetes":
29: provider "kubernetes" { Configuration looks like this: provider "kubernetes" {
load_config_file = false
host = "https://${local.cluster_endpoint}"
token = data.google_client_config.default.access_token
cluster_ca_certificate = base64decode(local.cluster_ca_certificate)
} |
Having the same Issue with GKE:
|
guys, don't spam) Use version pinning: version = "1.10.0". # Stable version
|
Pinning to v1.10 works for me, but it's not a solution. A minor release should not introduce breaking changes (not to imply it was intended). |
I'm having the same issue, I locked to 1.10.0 and works now. This is my config: data "aws_eks_cluster_auth" "cluster" { provider "kubernetes" { provider "helm" { |
@alexsomesan sure, here you go:
|
Thanks! If you set an output with the value of
|
@alexsomesan yes, that's correct: the output of
is
Essentially we first create an Azure AKS cluster using TF and then use the output of it (like the host name) to configure the K8S provider. |
@hazcod Thanks for the confirmation. @alecor191 I'll be trying to reproduce your case, but I'm baffled by one thing: if you wrap your cluster provisioning resources in a module, why is your |
@alexsomesan sorry for the delay and not being more precise. I used TF v0.12.20. Essentially what we have is setting up AKS cluster + assigning roles in a shared module that is being used by 3 "environments". In short, we have this setup:
And then we have a shared
with outputs.tf as follows (some of them you can see being used in
I'm new to TF, so I may miss something obvious; like if it is an issue to reference outputs of the "shared-module main.tf" in our "environment-specific main.tf" |
The 1.11.1 release notes specifically mention this issue as fixed, but it's still open? Do I miss something? |
@Comradin you didn’t miss anything. I’m just keeping the issue open for a while to collect confirmations from users who reported here. This issue was only manifesting in peculiar setups which I cannot reproduce all of. |
I tested this with an existing cluster (and existing Terraform state) as well as on a new cluster (with no Terraform state) and it all appears to be working as it did before. Thanks @alexsomesan! For reference, this is my provider config:
Also, I don't think it should matter for this issue, but I also have a local-exec provisioner on my cluster resource to wait for the k8s API:
|
* Add node_count variable definition to gke/variables.tf * Pin kubernetes provider version to 1.10.0 Workaround for hashicorp/terraform-provider-kubernetes#759 Signed-by: Chris and Victor
Moving to 1.11, fixed the issue.
|
Looks like I use terraform-aws-eks, conditionally creating all k8s resources via a variable (the ones managed by aforementioned module + some others). Similar to this example. So new clusters I roll out in 2 steps (one Terraform project). First pass creates just the cluster without 'touching' anything related to kubernetes provider. Second pass sets up de |
Sounds like this issue has been fixed. Does anyone have further reports of this still being an issue? |
@aareet unfortunately I still have a 100% repro. I have an AKS cluster created with TF. I used If I now just change the provider version to Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
module.appgateway.module.appgateway-frontoffice-api.data.azurerm_key_vault_secret.backend_https_certificate: Refreshing state...
module.appgateway.module.appgateway-backoffice-api.data.azurerm_key_vault_secret.backend_https_certificate: Refreshing state...
module.appgateway.module.appgateway-corporate-api.data.azurerm_key_vault_secret.backend_https_certificate: Refreshing state...
module.appgateway.module.appgateway-customer-api.data.azurerm_key_vault_secret.backend_https_certificate: Refreshing state...
azurerm_resource_group.aks: Refreshing state...
module.appgateway.module.appgateway-customer-api.azurerm_public_ip.ag_public_ip: Refreshing state...
module.cluster.azurerm_role_assignment.aks_rg_access: Refreshing state...
module.appgateway.module.appgateway-frontoffice-api.azurerm_public_ip.ag_public_ip: Refreshing state...
module.vnet.azurerm_virtual_network.cluster_net: Refreshing state...
module.appgateway.module.appgateway-backoffice-api.azurerm_public_ip.ag_public_ip: Refreshing state...
module.appgateway.module.appgateway-corporate-api.azurerm_public_ip.ag_public_ip: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_corporate_api_ag: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_k8s_pods_worker: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_k8s_pods_default: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_backoffice_ag: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_frontoffice_ag: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_customer_api_ag: Refreshing state...
module.vnet.azurerm_subnet.cluster_net_lb: Refreshing state...
module.cluster.azurerm_kubernetes_cluster.aks: Refreshing state...
module.appgateway.module.appgateway-frontoffice-api.azurerm_application_gateway.ag: Refreshing state...
module.appgateway.module.appgateway-backoffice-api.azurerm_application_gateway.ag: Refreshing state...
module.appgateway.module.appgateway-customer-api.azurerm_application_gateway.ag: Refreshing state...
module.cluster.azurerm_kubernetes_cluster_node_pool.aks_worker_node_pool: Refreshing state...
module.cluster.kubernetes_cluster_role_binding.admins: Refreshing state...
module.appgateway.module.appgateway-corporate-api.azurerm_application_gateway.ag: Refreshing state...
Error: serializer for text/html; charset=utf-8 doesn't exist Is there any way for me to provide some sort of diagnostic logs? |
@alecor191 That's a weird error message. Can you do the same operation with the env var TF_LOG=TRACE set and share the output? It will be a quite hefty log so maybe put it in a gist instead of pasting. |
@alexsomesan thanks for the hint. I re-ran From what I see the issue is that we're getting redirected as the request is unauthorized ( For context: I'm running the TF command as part of a CI pipeline in Azure DevOps Pipelines. Update: I also ran Both runs were executed on the same CI pipeline. The only difference between the two runs is the TF Kubernetes provider version. Right before that K8S API call, I noticed this diff between 1.10.0 and 1.11.1:
As a workaround, I tried to create the kube config file as part of the CI pipeline and re-ran using 1.11.1. This time it worked. However, it was OK because the AKS cluster already existed and I knew what to put in kube config. But what if I create the cluster from scratch using TF: before running TF there is no kube config I can set, as the cluster doesn't exist yet. My understanding is that the Kubernetes provider should pick up the kube config from the AKS module (in my case):
However, from the logs above it seems the K8S provider wasn't really able to use those creds. I may be missing something obvious here, so I would be grateful for any pointer you can provide. |
Having the same issue with kubernetes version 1.11.0. I cannot rollback to 1.10.0 because that version does not recognize resource type "kubernetes_priority_class" |
Error: Invalid resource type |
@Mahendrasiddappa this issue was filed against 1.11.0, and resolved in 1.11.1 - can you retry with 1.11.1? |
I'm running terraform in a docker container via Docker Desktop on Windows. Restarting docker itself by restarting Docker Desktop fixed my issue, similar to the one from dubb_b Edit for more info: I usually run my terraform container detached, and let it live across laptop hibernation. |
I used to encounter this issue and had to resort to v1.10. Just tried again in a new project, the issue seems to be fixed. See
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks! |
Hi there, like 40ty minutes ago provider has been updated and I started getting issues during its initialization:
Downgrading provider to 1.10.0 fixes that issue.
Using newest TF, which is 0.12.20
The text was updated successfully, but these errors were encountered: