The current process for deploying is kinda tiresome: git push, deploy.sh, puppet apply on the affected nodes.
We want at least a little bit more automation than that, still avoiding cron-based under-your-feet deployments. But it's not clear how far we can go.
Description
Related Objects
Event Timeline
(21:34:47) olasd: right now when you push a repo in the puppet environment you need to run deploy.sh by hand
(21:34:56) olasd: which is boring
(21:35:44) olasd: but I don't think we can do much better
(21:36:35) olasd: except having an http service we can trigger from phabricator and running as root on the other end
(21:36:37) olasd: which doesn't look very appealing
(21:37:50) olasd: we should probably be able to make the puppet manifests modifiable to the puppet user only but that's still root equivalent in the end
(21:38:30) olasd: you can paste that to the ticket if you'd like; I'm away from forge credentials
Not there yet, but rSENV5c4dfd036344 added a bin/deploy-on helper script in the puppet-environment repo that goes through the hoops of 1) deploying the recipes on puppet master, 2) doing a test run on the given node, 3) ask for confirmation, 4) do a real deployment on the node if user confirmed.
Note that it will work fully on all machines only after the /usr/local/sbin/swh-puppet-* have been created there. So a manual puppet agent --test might still be required on a number of machines during the transition.
As added helping benefit, we might want to allow members of some group (adm?) to sudo /usr/local/sbin/swh-puppet-* without password.
With the recent improvents to bin/deploy/on (see rSENVa8c34dda11d1), this is probably as addressed as it could with the current setup. See also the recommended semi-automated deployment workflow.
After fiddling with the Puppet recipes, a single command can be used to deploy on the puppetmaster and one or several machines, without needing interaction aside from confirming the proposed diff (if requested).