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. I'm happy to answer questions, Paul [1] http://softwarefactory-project.io/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
