arlolra@mira:/srv/deployment/parsoid/deploy$ scap deploy
20:18:38 Started Deploy: parsoid/deploy
Entering 'src'
20:18:38
== CANARY ==
:* wtp2001.codfw.wmnet
:* wtp2002.codfw.wmnet
:* wtp1002.eqiad.wmnet
:* wtp1001.eqiad.wmnet
parsoid/deploy: fetch stage(s): 100% (ok: 4; fail: 0; left: 0)
parsoid/deploy: config_deploy stage(s): 100% (ok: 4; fail: 0; left: 0)
parsoid/deploy: promote and restart_service stage(s): 100% (ok: 4; fail: 0; left: 0)
canary deploy successful. Continue? [y]es/[n]o/[c]ontinue all groups: no
20:19:47 Finished Deploy: parsoid/deploy (duration: 01m 09s)
...
arlolra@wtp1001:~$ curl localhost:8000/_version
{"name":"parsoid","version":"0.5.1+git","sha":"63f1e1512785d31a15f97210fce14b715dfd1a95"}Similarly to T145460, I noted that wtp2019.codfw.wmnet was down, but only after having invoked scap deploy. I assumed that saying no to continuing the deploy at the canary stage would allow me to rollback and remove it from the targets. However, the deploy just finished and the canaries were confirmed to be left on the new commit.