Ops Mgr upgrade has risk of loosing ops mgr settings. about pcf-pipelines HOT 5 CLOSED

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.

from pcf-pipelines.

We should add some example operations files for this purpose. @haydonryan if you were able to contribute that it would be appreciated.

We'd want to add a new resource and then add a new task to the job that does the export of settings to put it elsewhere.

I'm not sure how we'd manage that resource, though, because each time the pipeline runs we'd be adding multiple GB of data to that S3 store. Maybe we consider that out of scope and just put a warning that the S3 storage used by the export will need to be groomed via some mechanism.

from pcf-pipelines.

I'm not sure you'd lose the settings as the old ops man VM isn't usually trashed, it's just shut down. a pipeline failure would require a manual shutdown of the new/incomplete ops man and restart of the old one.

but otherwise, +1 if anything to speed up the pipeline after export , not requiring the 10 minute+ wait for to rerun the export every time during a debug cycle where the upgrade isn't working as planned

perhaps you'd do a "check" on that cached resource to see if it exists for the version we want and at the sha1 we want (which we would know from Pivnet).

from pcf-pipelines.

@svrc-pivotal Turns out you are correct. I took this as an issue from the customer. We can close it, if everyone wants. I still like the idea of persisting the settings, so that if an ops mgr does fail to come up, it's just a case of re-running the job vs manual intervention.

from pcf-pipelines.

I also like the idea of persisting settings, but it'd need to be done via yaml-patch ops files. I'll close this for now but if you'd like to do a PR for some ops files that do this that would be great.

from pcf-pipelines.