mirror of
https://github.com/GSA/notifications-api.git
synced 2026-02-04 18:31:13 -05:00
remove cf stop to try and improve deploy robustness
Rationale: Sometimes, when deploying, we've seen errors while stopping the old apps: "(psycopg2.ProgrammingError) permission denied for relation notifications". When you call cf stop, it may not be entirely synchronous. Under the hood, cloudfoundry has to do a whole bunch of things when you stop an app - it has its own internal db of what app states are, and also has to remove it from any load balancers etc, and also it has to actually stop the app. We're not sure if the `cf stop` command guarantees that your process has already terminated by the time that the command returns. In our Makefile, we call `cf stop`, followed by `cf delete`. One posisble theory is that the process is still running when `cf stop` exits, and then `cf delete` unbinds that service from the database, removing all of it's users' permissions. This isn't confirmed, however, this commit removes the `cf stop` command to see if it solves the issue. PaaS team confirmed that it's redundant - `cf delete` will carry out the same tasks under the hood.
This commit is contained in:
1
Makefile
1
Makefile
@@ -277,7 +277,6 @@ cf-deploy: ## Deploys the app to Cloud Foundry
|
||||
cf rename ${CF_APP} ${CF_APP}-rollback
|
||||
cf push ${CF_APP} -f ${CF_MANIFEST_FILE}
|
||||
cf scale -i $$(cf curl /v2/apps/$$(cf app --guid ${CF_APP}-rollback) | jq -r ".entity.instances" 2>/dev/null || echo "1") ${CF_APP}
|
||||
cf stop ${CF_APP}-rollback
|
||||
cf delete -f ${CF_APP}-rollback
|
||||
|
||||
.PHONY: cf-deploy-api-db-migration
|
||||
|
||||
Reference in New Issue
Block a user