On Fri, Oct 7, 2016 at 9:03 AM, 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. > > 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.
+1 on this first iteration of building up our own nodepool-builder instance until Software Factory can provide one. Thanks for initiating this work, > I'm happy to answer questions, > Paul > > [1] 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 -- Emilien Macchi __________________________________________________________________________ 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