Closed aegershman closed 5 years ago
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.
The labels on this github issue will be updated when the story is started.
Closing this as I imagine Pivotal is aware of the problems presented here && that it's a pretty complicated problem. I just wanted to point it out. Thanks!
Sorry your issue slipped through the cracks. We are working on some solutions for upgrading Ops Manager. There are some open questions, but the Ops Manager VM won't be handled by Terraform. We added a variable to skip creation of the Ops Manager VM to support this.
No worries at all. I just wanted to point it out. Thanks for your time.
Opsmgr comes packaged as an AMI defined within terraform.
But when it comes time to upgrade the version of opsmgr, things get tricky. You have to...
This is a stateful operation; terraform doesn't know anything about what's actually running on the EC2 instance. It'll gladly blow it away and replace it with a new EC2 instance without any regard for running processes, persistent volumes, etc. So I, as an operator, am responsible for maintaining/backing up/restoring the state of opsmgr. This sounds like something BOSH is designed to do.
The
pcf-pipelines
project dealt with upgrading opsmgr by doing some funky stuff withcliaas
to replace the VM. But even that wouldn't work if your VPC was managed by terraform. If you update the opsmgr VM without terraform being aware of it, the next time terraform runs it will replace your new opsmgr VM with the old AMI.I'm curious if there's a medium/long-term solution to this problem. Specifically: does Pivotal have any plans to refactor opsmgr into a BOSH-managed resource rather than a terraform-managed resource?
Thanks for your time, I appreciate it!