[openstack-dev] [tripleo] Setting up to 3rd party CI OVB jobs

Paul Belanger pabelanger at redhat.com
Wed Oct 12 17:58:11 UTC 2016


On Tue, Oct 11, 2016 at 05:37:54PM +0100, Derek Higgins wrote:
> 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?
> 
yes, this is possible but will require somebody to step up to do the work. For
me, the easier path was getting nodepool-builder going.

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



More information about the OpenStack-dev mailing list