Open zeffron opened 1 year ago
Also, it appears the workaround documented to close #1987 is incomplete. In addition to using terraform rm
on the newrelic_synthetics_monitor_script
resource, it also needs to be applied to the associated newrelic_synthetics_monitor
resource.
I also agree that the manual migration is not really practical when there are dozens of monitors in place. Each one of us will need to come up with their own scripted solution to this problem eventually.
Here is the script I'm using to do migration, in case it helps anyone else (it takes the Terraform workspace as its only argument):
#!/bin/bash
set -ue -o pipefail
# Get all of the terraform monitor names
export TF_WORKSPACE=$1
IFS=$'\n' read -r -d '' -a resources < <(terraform state list | grep ^newrelic_synthetics_monitor_script\\. && printf '\0' )
guids=( )
git switch --detach <commit of v2 configuration> 2> /dev/null
terraform init -upgrade > /dev/null
for resource in "${resources[@]}"
do
monitor=$( sed 's/newrelic_synthetics_monitor_script/newrelic_synthetics_monitor/' <<< ${resource} )
name=$( terraform state show ${monitor} | grep name | awk '{ $1=""; $2=""; print }' | sed 's/ "\(.*\)\"/\1/' )
guids+=( $(newrelic entity search --name "${name}" --type MONITOR --format text --fields-filter guid | tail -n 1) )
echo "Removing ${resource}"
terraform state rm ${resource} > /dev/null
echo "Removing ${monitor}"
terraform state rm ${monitor} > /dev/null
done
git switch <branch of v3 configuration> 2> /dev/null
terraform init -upgrade > /dev/null
for i in "${!resources[@]}"
do
new_resource=$( sed 's/newrelic_synthetics_monitor_script/newrelic_synthetics_script_monitor/' <<< ${resources[${i}]} )
echo "Importing ${new_resource}"
terraform import -var-file ${TF_WORKSPACE}.json ${new_resource} "${guids[${i}]}" > /dev/null
done
@zeffron Are you open to updating the v3 migration guide with your script in case others find it helpful?
@mbazhlekova I have no issue with that, but it's not tested outside of my specific use case, and doesn't have safeguards in case of errors or anything. So I'm not sure I'd really recommend it as an official solution to a problem of this magnitude. There really ought to be a real upgrade path from 2.x to 3.x. Do manual things and run random bash scripts is not a real upgrade path. I'm kinda concerned about what happens with the upgrade from 3.x to 4.x, now.
This is essentially a reopening of #1987, but more targeted in scope. While #1987 was closed with a workaround, manual migration path, that migration path is not really feasible for deployments with many (we have >50) affected synthetics. There really needs to be a more automatic migration for existing resources between major versions of the provider.