Open msvticket opened 1 year ago
😬 Aww yea, I forgot I was going to write that. I apologize, I never got around this this. In a nutshell, all the resources from the old crd need to be removed.
There are lots of edge cases, but here is what worked for me. It wasn't as smooth as I was hoping. Namely the main issue was caused because I am using helm to install my tf resources. There is a note in the guide below about the helm plan/apply issue.
apiVersion
From v0.11 -> v0.12 the only difference in the tf resources is the apiVersion
from tf.isaaguilar.com/v1alpha2
to tf.galleybytes.com/v1beta1
.
My resources were installed via helm, so I just changed my template. I then deleted the old terraform-operator following the Removal Guide.
The helm template change was easy, but the aftermath really sucked for the following reason:
To fix, I had to remove the helm history on all my old resources. Not a huge deal but a caveat to watch out for.
1. Stop/Remove the Controller
I highly recommend deleting the terraform-operator controller
# Via helm
helm delete --namespace tf-system terraform-operator
# Via kubectl
kubectl delete deployment -n tf-system terraform-operator
kubectl delete serviceaccount -n tf-system terraform-operator
kubectl delete clusterrole -n tf-system terraform-operator
kubectl delete clusterrolebinding -n tf-system terraform-operator
2. Delete the crd and all the resources
As long as there is no controller, no terraform workflows will be executed, which makes deleting the tf resources safe without threatening to run terraform on accident
kubectl delete crd terraforms.tf.isaaguilar.com # If this hangs, press ctrl+c and then run the next two commands
kubectl patch crd terraforms.tf.isaaguilar.com -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl delete crd terraforms.tf.isaaguilar.com
After everything is removed, the reinstallation is straight forward. See http://tf.galleybytes.com/docs/getting-started/installation/ for instructions. Note that the current installation is past v0.12 and more changes have been introduced. The changes should be harmless.
Use terraform-operator the same as before. Resources that have remote backends (which should be all of them) will not see changes to state since the only thing that was changed was the apiVersion
.
I'll write this up in the docs page soon and close out this ticket.
That is good information, but how about the changes in the API? In our particular case we rely a lot on postrunScript, which doesn't exist any more.
An equivalent to postrunScript
is now accessible via taskOptions.
spec:
taskOptions:
- for:
- postapply
script:
inline: |
#!/bin/bash
echo hello post apply
This idea is extendable into any pre/post task. http://tf.galleybytes.com/docs/architecture/tasks/#tasks-by-name-and-order-of-execution
postrunScript
This is quite old. Check out the references page for APIs available @ releases. http://tf.galleybytes.com/docs/references/
There will be lots of changes to make in your case and I don't have a diff to give.
In the release notes of v0.12.0 and v0.12.1 there is a link to a migration guide: https://tf.galleybytes.com/blog/migrate-crd-from-tfv1alpha2-to-v1beta1/
This link is broken. tf.galleybytes.com doesn't respond to https and changing to http yields a 404. On http://tf.galleybytes.com/blog/ no post on migration in shown.