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[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-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 > 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev