Enhancing std-ci for deployment (std-cd)

[David Caro Estevez]

----- Original Message -----
> From: "Barak Korren" <bkorren at redhat.com>
> To: "David Caro Estevez" <dcaroest at redhat.com>
> Cc: "infra" <infra at ovirt.org>
> Sent: Tuesday, June 7, 2016 11:31:17 AM
> Subject: Re: Enhancing std-ci for deployment (std-cd)
> 
> >
> > I'd go a 4th way:
> >
> > * For the non-merged patches, use lago or similar instead of deploying into
> > prod foreman, though it might be a bit cumbersome to generate the env, for
> > most cases, it's way more flexible, and a lot less risky
> 
> This would probably mean all tests would need to be automated, while a
> worthy goal, this is not practical in the short term IMO.
> 

I don't think we should invest time in automating any other solution, that would mean not just not working on that one, but actually burying it under extra effort to adapt whatever 'temporary short term' solution was used instead.

> > * For the merged patches, I'd use a 'passive' deployment, where the scripts
> > with the deploy logic reside on foreman and are activated by jenkins (for
> > example, by ssh to the slave, similar to how we deploy there today). That
> > puts the deploy logic on the server where it should be deployed. Most
> > probably using the same or very similar script on the non-merged checks to
> > deploy to the virtual environment. This leaves a clean yaml, keeps a
> > strict security (only a specific ssh user with the correct private key can
> > do it, and it can only run that script and nothing else), and maintain the
> > infra config details out of the source code.
> >
> 
> While I agree that infra details should be kept outside the source
> repo. This seems to create the situation where all deployment logic
> will also permanently reside outside of it. I want the deployment
> logic to be self-contained and movable. I'm actually looking at this
> right now because I want to deploy the Puppet code on the DS Sat6 and
> not the US foreman.

I don't think you should use the same deploy procedure on upstream foreman and ds satellite, each env has it's own particularities, and unless you want to deploy the whole env (like deploying full vms, or containers) it's no worth imo try to keep such a generic deploy script, given into account all the limitations and maintenance that genericness requires.

> I can see the security benefits of the keyed ssh commands, but I'm not
> sure those are required in all cases and outweigh the lack of
> transparency in the logic and the probable need for manual
> maintenance.
> 

I don't think the manual maintenance will be that high, the deploy scripts can be easily puppetized themselves. And imo, upstream the ssh command are more than required, they should be a bare minimum.

> 
> --
> Barak Korren
> bkorren at redhat.com
> RHEV-CI Team
>