Closed vdice closed 7 years ago
If it wasn't clear: this issue occurs when azure is used as object storage for postgres (via installing Workflow with global.storage=azure
and relevant details to the azure block...)
Even so, this is a blocker for v2.15. Or, if not fixed, the latest commit we can tag of this repo for v2.15 would be https://github.com/deis/postgres/commit/4d55b4e5b93d06c3efb9045ed0dccf0a67c9bf12 (though I believe if we build the docker image with --no-cache
at release time, we would hit the build failure that https://github.com/deis/postgres/commit/536a652a04fb64de1f86e9cd9f8e3b040c088972 was added to fix; hence a bit of a catch-22)
A recent PR bumping the Postgres version (necessary as previous artifact was no longer being hosted) also updated an azure storage API call, from
BlobService
(azure.storage 0.20.0) toBlockBlobService
(azure.storage 0.30.0). Here was the error frommake test-functional
:(See also https://stackoverflow.com/questions/35558463/how-to-import-azure-blobservice-in-python)
Yet, the
wal-e
dependency still usesBlobService
so errors out with same above, presumably because it is still on azure.storage 0.20.0, thus disabling postgres from running.Is there a way to use one version locally (for our script above) but maintain the other for the
wal-e
dependency? Or, other solutions to resolve this discrepency? cc @mboersma @bacongobbler