On Tue, Oct 11, 2016 at 05:37:54PM +0100, Derek Higgins wrote:
> On 7 October 2016 at 14:03, Paul Belanger <pabelan...@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 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
> >  http://softwarefactory-project.io/
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)