Last modified: 2014-05-22 14:25:07 UTC
`git deploy sync` for the ocg/ocg repository in both beta and production requires the deployer to 'Continue' at least once even for a noop deploy. This is likely due to the number of submodules / size of repo. It would be nice if it was possible to tune this timeout. deployment-bastion:/srv/deployment/ocg/ocg (git wmf-deploy) bd808$ git deploy sync Repo: ocg/ocg Tag: ocg/ocg-sync-20140521-202330 0/1 minions completed fetch Continue? ([d]etailed/[C]oncise report,[y]es,[n]o,[r]etry): r Continue? ([d]etailed/[C]oncise report,[y]es,[n]o,[r]etry): d Repo: ocg/ocg Tag: ocg/ocg-sync-20140521-202330 1/1 minions completed fetch Details: Continue? ([d]etailed/[C]oncise report,[y]es,[n]o,[r]etry): y Repo: ocg/ocg Tag: ocg/ocg-sync-20140521-202330 0/1 minions completed checkout Continue? ([d]etailed/[C]oncise report,[y]es,[n]o,[r]etry): r Continue? ([d]etailed/[C]oncise report,[y]es,[n]o,[r]etry): d Repo: ocg/ocg Tag: ocg/ocg-sync-20140521-202330 1/1 minions completed checkout Details: Continue? ([d]etailed/[C]oncise report,[y]es,[n]o,[r]etry): y Deployment finished. deployment-bastion:/srv/deployment/ocg/ocg (git wmf-deploy) bd808$ git deploy report --detailed sync Repo: ocg/ocg Tag: ocg/ocg-sync-20140521-202330 1/1 minions completed fetch; 1/1 minions completed checkout Details: i-00000396.eqiad.wmflabs: fetch status: 0 [started: 0 mins ago, last-return: 0 mins ago] checkout status: 0 [started: 0 mins ago, last-return: 0 mins ago]
Thanks for reporting this. I have a similar issue with /srv/deployment/integration/slave-scripts which sync the rather small integration/jenkins.git repo to two minions (gallium and lanthanum). Do we have some kind of verbose mode to report the command output from the minions back to the master? That would help figuring out what is happeniing.
You can see what things look like from the minion's point of view by ssh'ing into the minion and running `sudo salt-call deploy.checkout 'ocg/ocg'` (replace ocg/ocg with any repo that targets the minion. I don't know if all this information ends up in redis or not. I should learn more about that part of the trebuchet stack.
The minions should always return status back to redis, assuming they got the call. I always required a continue step because during the first run (or when you add minions) you don't really know how many minions you have. It would be nice to be able to pre-populate the redis data with the minion data. We could probably fire an event on the minion when its target grain is added.
