Open Stack

On 7 October 2016 at 14:03, Paul Belanger <pabelanger at redhat.com> wrote:
> 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.

Great, if we are to transition to 3rd party CI this getting a trial up
and running first would be great to minimize down time if we are to
move jobs in future

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

+1, there are some user currently on RH2 using it as a dev
environment, but if we start small this wont be a problem and those
users should eventually be moving too a different cloud

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

As a 3rd option, is it possible to just use the centos cloud image
directly? The majority of the data cached on the DIB built image isn't
actually used by tripleo-ci?

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

Sounds good(assuming the RDO community are ok with allowing us to add
jobs over there)

>
> 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/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev