equinix / terraform-equinix-metal-anthos-on-vsphere

[Deprecated] Automated Anthos Installation via Terraform for Equinix Metal with vSphere
https://registry.terraform.io/modules/equinix/anthos-on-vsphere/metal/latest
Apache License 2.0
62 stars 41 forks source link

Update to Terraform 0.13 and validate terraform scripts in PRs #95

Closed displague closed 3 years ago

displague commented 4 years ago

Minimum Terraform is bumped to 0.13 and the Packet provider is bumped to 3.0.1.

This also introduces Github workflows as the CI/CD tool and provides basic Terraform validation for PRs. This is step 0 on the way towards https://github.com/packet-labs/google-anthos/issues/91

displague commented 4 years ago

terraform apply succeeded, but it looks like I have some errors in this deploy.

null_resource.anthos_deploy_workstation[0] (remote-exec): Setting up OS image as a VM template in vSphere...
null_resource.anthos_deploy_workstation[0] (remote-exec): Exit with error:
null_resource.anthos_deploy_workstation[0] (remote-exec): Failed to create and prepare admin workstation: failed to prepare admin workstation: failed to create VM Template for OS image "admin-appliance/1.4.0-gke.13/gke-on-prem-admin-appliance-vsphere-1.4.0-gke.13.ova" from bucket "gke-on-prem-release": datastore 'vsanDatastore' not found
null_resource.anthos_deploy_workstation[0] (remote-exec): *************************************************************************
null_resource.anthos_deploy_workstation[0] (remote-exec): ** Errors in the above section related to enabling APIs and creating   **
null_resource.anthos_deploy_workstation[0] (remote-exec): ** IAM roles are expected and can safely be ignored                    **
null_resource.anthos_deploy_workstation[0] (remote-exec): *************************************************************************

This seems to stem from

null_resource.vsan_claim[0]: Provisioning with 'remote-exec'...
null_resource.vsan_claim[0] (remote-exec): Connecting to remote host via SSH...
null_resource.vsan_claim[0] (remote-exec):   Host: 147.75.53.23
null_resource.vsan_claim[0] (remote-exec):   User: root
null_resource.vsan_claim[0] (remote-exec):   Password: false
null_resource.vsan_claim[0] (remote-exec):   Private key: true
null_resource.vsan_claim[0] (remote-exec):   Certificate: false
null_resource.vsan_claim[0] (remote-exec):   SSH Agent: true
null_resource.vsan_claim[0] (remote-exec):   Checking Host Key: false
null_resource.vsan_claim[0] (remote-exec): Connected!
null_resource.vsan_claim[0] (remote-exec): Traceback (most recent call last):
null_resource.vsan_claim[0] (remote-exec):   File "/root/vsan_claim.py", line 95, in <module>
null_resource.vsan_claim[0] (remote-exec):     smallerSize = min([disk.capacity.block * disk.capacity.blockSize for disk in ssds])
null_resource.vsan_claim[0] (remote-exec): ValueError: min() arg is an empty sequence
displague commented 4 years ago

I also got null_resource.anthos_deploy_cluster[0] (remote-exec): Error: timeout - last error: dial tcp 172.16.0.3:22: connect: no route to host 🤔

displague commented 4 years ago

I started going down the rabbit hole of converting the anthos/ directory to Terraform 0.13 also.

I would like to find a pattern/solution where the terraform deployed scripts on the provisioner node are not templated, rather, we could sync the module as simple .tf files (no .tf.tpl templating) and then add a terraform-vars.sh (full of shell environment variables TF_VAR_name=value), python scripts (if we still need them) could use these same environment variables (these variable names are special to terraform and provide values for each TF variable).

A templated terraform.tfvars file on the provisioner node (we already have one, so maybe we just need more variables defined) could substitute a terraform-vars.sh on the provisioner node if Python scripts are no longer needed.

dfong commented 3 years ago

just a suggestion, it might be cleaner to make these 2 changes in 2 separate PRs.

displague commented 3 years ago

I'm closing this in favor of #113 moving forward first. We can revisit these changes when the vSphere module is independent (which will reduce the changes needed here and avoid duplication of effort).