You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 18, 2024. It is now read-only.
Hi,
I was trying to use this template (with OCI Resource Manager) to deploy a CDH cluster on an existing VCN but the plan fails showing network errors:
worker in modules/worker
Initializing provider plugins...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
*provider.local: version = "> 1.2"
*provider.null: version = "> 2.1"
*provider.oci: version = "> 3.86"
*provider.tls: version = "> 2.0"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
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.worker.data.null_data_source.hostname_labels[2]: Refreshing state...
module.worker.data.null_data_source.hostname_labels[0]: Refreshing state...
data.null_data_source.vpus: Refreshing state...
module.worker.data.null_data_source.hostname_labels[3]: Refreshing state...
module.worker.data.null_data_source.hostname_labels[1]: Refreshing state...
data.oci_identity_availability_domains.ADs: Refreshing state...
data.oci_core_subnet.bastion_subnet: Refreshing state...
data.oci_core_vcn.vcn_info: Refreshing state...
data.oci_core_subnet.utility_subnet: Refreshing state...
data.oci_identity_regions.filtered_regions: Refreshing state...
data.oci_core_subnet.cluster_subnet: Refreshing state...
data.null_data_source.values: Refreshing state...
Error: Invalid index
on modules/network/outputs.tf line 2, in output "vcn-id"
2: value = "${oci_core_vcn.cloudera_vcn.0.id}"
|----------------
| oci_core_vcn.cloudera_vcn is empty tuple
The given key does not identify an element in this collection value.
============== PLAN-JOB LOG ===========================================
From the plan-job variables I see that all variables are correctly instantiated.
Have you came across this issue? Is there a way to debug this process to get more meaningful information?
If I use the same template but instead configuring the template to create the VCN during the the deploy, the new VCN is created and the cluster is correctly deplyed on the new VCN.
Many thx,
Rgds,
Nelson
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
I was trying to use this template (with OCI Resource Manager) to deploy a CDH cluster on an existing VCN but the plan fails showing network errors:
============== PLAN-JOB LOG ===========================================
Initializing modules...
Initializing provider plugins...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
*provider.local: version = "
> 1.2"> 2.1"*provider.null: version = "
*provider.oci: version = "
> 3.86"> 2.0"*provider.tls: version = "
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
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.worker.data.null_data_source.hostname_labels[2]: Refreshing state...
module.worker.data.null_data_source.hostname_labels[0]: Refreshing state...
data.null_data_source.vpus: Refreshing state...
module.worker.data.null_data_source.hostname_labels[3]: Refreshing state...
module.worker.data.null_data_source.hostname_labels[1]: Refreshing state...
data.oci_identity_availability_domains.ADs: Refreshing state...
data.oci_core_subnet.bastion_subnet: Refreshing state...
data.oci_core_vcn.vcn_info: Refreshing state...
data.oci_core_subnet.utility_subnet: Refreshing state...
data.oci_identity_regions.filtered_regions: Refreshing state...
data.oci_core_subnet.cluster_subnet: Refreshing state...
data.null_data_source.values: Refreshing state...
Error: Invalid index
on modules/network/outputs.tf line 2, in output "vcn-id"
2: value = "${oci_core_vcn.cloudera_vcn.0.id}"
|----------------
| oci_core_vcn.cloudera_vcn is empty tuple
The given key does not identify an element in this collection value.
============== PLAN-JOB LOG ===========================================
From the plan-job variables I see that all variables are correctly instantiated.
Have you came across this issue? Is there a way to debug this process to get more meaningful information?
If I use the same template but instead configuring the template to create the VCN during the the deploy, the new VCN is created and the cluster is correctly deplyed on the new VCN.
Many thx,
Rgds,
Nelson
The text was updated successfully, but these errors were encountered: