datastax / zdm-proxy-automation

An Ansible-based automation suite to deploy and manage the Zero Downtime Migration Proxy
https://docs.datastax.com/en/astra-serverless/docs/migrate/introduction.html
Apache License 2.0
60 stars 5 forks source link

Make the tf_latest_vars.txt be in key=value format #32

Open sync-by-unito[bot] opened 1 year ago

sync-by-unito[bot] commented 1 year ago

This issue was originaly reported by a customer with whom we did C* to Astra migration.

The run_terraform_cloudgate.sh script seems to create tf_latest_vars.txt which is simply a string of commandline arguments provided to terraform to set the vars. This makes destroying the terraform stack a bit annoying, because one has to supply the same vars to destroy it, so you have to copy the contents of tf_latest_vars.txt and append it to the terraform destroy command. As far as I know, Terraform comes with a -var-file option, so if you create tf_latest_vars.txt as a simple key=value file (like a .env file), you can just pass the argument "-var-file tf_latest_vars.txt" to terraform directly.

┆Issue is synchronized with this Jira Task by Unito ┆Components: Automation ┆Priority: Major

sync-by-unito[bot] commented 1 year ago

➤ Radovan Zvoncek commented:

I have another update from the customer. He made us a patch.

I've attached a patch below. This changes the way the vars are passed to terraform by the script (creates a tfvars file[1]). I've also modified the networking-aws submodule to accept the proxy_instance_type variable so it can do a look up on AZs where the instance type is available. Note that the Terraform script picks the AZ from the returned list, and it is a count loop, so at present you cannot specify a greater proxy instance count than there are AZs in the given region, as it will fail on the subnet creation. I didn't have time to handle this issue, but I'd probably end up doing something gross like availability_zone = sort(data.aws_ec2_instance_type_offerings.azs.locations)[count.index % length(data.aws_ec2_instance_type_offerings.azs.locations)]

you could also just not provide the AZ in the aws_subnet resource at all, and AWS will choose one at random[2] - this is probably not ideal, as there is no guarantee that it will spread them evenly.

Note that I haven't tested the changes very stringently, so I don't recommend just merging this in without testing.

[1] https://www.terraform.io/language/values/variables#assigning-values-to-root-module-variables ( https://urldefense.com/v3/__https://www.terraform.io/language/values/variables*assigning-values-to-root-module-variables__;Iw!!PbtH5S7Ebw!YpdlcFF5ZSzUGiWFWep0QGwsRDpf0nfdpbVN-hLkGFmnmZRE4JbCB7yKoXKgAZpWCkl-ghhGWtTR7syNVFePtvd5TQWBjyoe_w$ ) [2] https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSubnet.html ( https://urldefense.com/v3/__https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSubnet.html__;!!PbtH5S7Ebw!YpdlcFF5ZSzUGiWFWep0QGwsRDpf0nfdpbVN-hLkGFmnmZRE4JbCB7yKoXKgAZpWCkl-ghhGWtTR7syNVFePtvd5TQVhiXI7ag$ )