Enhancing std-ci for deployment (std-cd)

[Barak Korren]

>
> 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.

> * 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 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.


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