Open Stack

Greetings,

I wanted to propose a work item, that I am happy to spearhead, about setting up
a 3rd party CI system for tripleo project. The work I am proposing, wouldn't
actually affect anything today about tripleo-ci but provider a working example
of how 3rd party CI will work and potential migration path.

This is just one example of how it would work, obviously everything is open for
discussions but I think you'll find the plan to be workable. Additionally, this
topic would only apply to OVB jobs, existing jobs already running on cloud
providers from openstack-infra would not be affected.

What I am proposing is we move tripleo-test-cloud-rh2 (currently disabled) from
openstack-infra (nodepool) to rdoproject (nodepool).  This give us a cloud we
can use for OVB; we know it works because OVB jobs have run on it before.

There is a few issues we'd first need to work on, specifically since
rdoproject.org is currently using SoftwareFactory[1] we'd need to have them
adding support for nodepool-builder. This is needed so we can use the existing
DIB elements that openstack-infra does to create centos-7 images (which tripleo
uses today). We have 2 options, wait for SF team to add support for this (I
don't know how long that is, but they know of the request) or we manually setup
a external nodepool-builder instance for rdoproject.org, which connects to
nodepool.rdoproject.org via gearman (I suggest we do this).

Once that issue is solved, things are a little easier.  It would just be a
matter of porting upstream CI configuration to rdoproject.org and validating
images, JJB jobs and test validation. Cloud credentials removed from
openstack-infra and added to rdoproject.org.

I'd basically need help from rdoproject (eg: dmsimard) with some of the admin
tasks, a long with a VM for nodepool-builder. We already have the 3rdparty CI
bits setup in rdoproject.org, we are actually running DLRN builds on
python-tripleoclient / python-openstackclient upstream patches.

I think the biggest step is getting nodepool-builder working with Software
Factory, but once that is done, it should be straightforward work.

Now, if SoftwareFactory is the long term home for this system is open for
debate.  Obviously, rdoproject has the majority of this infrastructure in plan,
so it makes for a good place to run tripleo-ci OVB jobs.  Other wise, if there
are issue, then tripleo would have to stand up their own jenkins/nodepool/zuul
infrastructure and maintain it. 

I'm happy to answer questions,
Paul

[1] http://softwarefactory-project.io/