Closed rkoster closed 6 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/153023757
The labels on this github issue will be updated when the story is started.
Hi @rkoster, if I properly got your scenario, you have used the bosh db to host the concourse database and so you cannot apply the path suggested by concourse team to transition to the postgres-release, since they managed the one-shot data directory change and upgrade in their own job before deprecating it.
Consider that there are various properties that are currently calculated from the old data directory name. And also all these directories must have the proper ownership and permissions. Moreover depending on the PostgreSQL version you are coming from, the binaries required for the upgrade could be missing so it would be in any case necessary to limit the number of possible upgrade paths.
Another approach could be to make the bootstrap of the initial data directory customizable; currently it is done using PostgreSQL initdb function. A new property could be added to the manifest to provide in input the commands to intialize the data directory in a different way. In this case you may write your own steps to upgrade and rename bosh db data directory; the right PostgreSQL binaries would still be missing.
Anyway I have concerns with both approaches: I'm not sure that tests can adequately cover all the scenarios to guarantee not to break something when doing a change.
Maybe the best would be to use in bucc an approach similar to concourse.
if we can update bosh-deployment to use 9.5 our problem would be solved https://github.com/cloudfoundry/bosh-deployment/issues/164
@ramonskie Let's close this issue. Please reopen if that does not solve your problem.
I'm looking for a way to migrate to postgres-release from postgres-9.4, which ships with bosh.
Would a PR, which would make
postgres-previous
configurable through a property, be the right direction for addressing this use case?