Enhancing std-ci for deployment (std-cd)

[David Caro Estevez]

----- Original Message -----
> From: "Barak Korren" <bkorren at redhat.com>
> To: "infra" <infra at ovirt.org>
> Sent: Tuesday, June 7, 2016 10:45:06 AM
> Subject: Enhancing std-ci for deployment (std-cd)
> 
> Hi all,
> 
> I'm contemplating the best way to enable including deployment logic in
> standard-CI scripts.
> 

I'm working on a first POC of something similar to that right now, deploying engine rpms to an 'experimental' repo on build-artifacts success

> Case to the point - embedding the deployment logic of our infra-puppet
> repo. One thing to note about this, is that deployment in this
> scenario can happen either post-merge (Like it does today) or
> pre-merge (Create a per-patch puppet env to enable easy testing)
> 
> I can think of a few ways to go about this:
> 
> 1. Copy the full generated puppet configuration into
> 'exported-artifacts' and add logic to the YAML to copy it to the
> foreman server.
> 
> The main shortcoming of this is that we will have to maintain quite a
> bit of custom logic in the YAML. This beats the purpose of embedding
> the logic in the source repo in the 1st place.
> 
> 2. Mount the '/etc/puppet' directory into the chrrot
> 
> This will require having the foreman be a Jenkins slave and some
> custom YAML to ensure the jobs run on it (not a big deal IMO)
> 
> The shortcoming is that running tests locally with mock_runner would
> be cumbersome (It will touch your local /etc/puppet directory and
> probably fail). Another issue is that we will have to find a way to
> figure out Gerrit patch information from inside mock. Possibly we
> could use the commit message or git hash for that.
> 
> 3. Invent some kind of a new deploy_*.sh script
> 
> This makes it possible to run the checking code locally without the
> deployment code. The YAML changes for this could be quite generic and
> shared with other projects. We could possibly also invent a
> 'deploy_*.target' to specify where to run the deploy script (E.g. a
> Jenkins label).
> 
> We could even consider not running the script inside mock, though I
> think mock's benefits outweigh the limits it imposes on accessing the
> outside system (which can be mostly bypassed anyway with bind mounts).
> 
> So,
> WDYT?
> 

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

> --
> Barak Korren
> bkorren at redhat.com
> RHEV-CI Team
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>