r10k puppet deployment

Ewoud Kohl van Wijngaarden ewoud+ovirt at kohlvanwijngaarden.nl
Fri Sep 13 19:24:24 UTC 2013


On Fri, Sep 13, 2013 at 11:00:27AM +0200, David Caro wrote:
> On Wed 11 Sep 2013 04:09:17 PM CEST, Ewoud Kohl van Wijngaarden wrote:
> > For https://fedorahosted.org/ovirt/ticket/71 I submitted
> > http://gerrit.ovirt.org/19141 to use r10k for module deployment.
> >
> > I do have some concerns for further deployment. Until now I've assumed
> > that we want jenkins to build on new git versions (possibly via the
> > jenkins patch merged trigger) and then push that to foreman.ovirt.org.
> > However, that means we give jenkins implicit root on all of our infra
> > which is a bad thing.
> >
> > Some solutions I can think of:
> >
> > 1. Set up a cronjob on foreman to poll git
> > 1.1. Run make as the current patch
> > 1.2. Change the patch and switch to dynamic environment support[1]
> > 2. Set up an infra jenkins to automate this
> 
> We can also restrict the ssh commands that the user can run, and 
> restrict it to the script that updates the manifests. That will avoid 
> having to give root access to the puppetmaster, that said, the 
> manifests that will be applied have implicit root access everywhere 
> too, but if we want automatic deployments that's what you get (only 
> maintainers should have merge access, meaning that anything that goes 
> through has been reviewed, so what we are really doing is reducing the 
> manual steps to one, when the reviewer merges the patch).

I like this solution. It would remove the polling from foreman and give
us logging in jenkins. I'd prefer if foreman retrieves the sources
straight from gerrit so jenkins is more like a glorified cron. I think
that's less insecure ;)

> >
> > I'm leaning to 1.2, but maybe I'm missing some other solutions.
> >
> > [1]: https://github.com/adrienthebo/r10k#dynamic-environment-support



More information about the Infra mailing list