Greetings, 5 months ago fungi posted:
[tripleo] becoming third party CI (was: enabling third party CI)[1] About having the discussion whether the existing TripleO CI should itself follow our third-party integration model instead of the current implementation relying on our main community Zuul/Nodepool/Jenkins servers. The result of the thread had some pros and cons, which I encourge people to re-read. At the Austin summit we continued the topic of moving tripleo-ci into 3rd party CI. Again, consensus could not be reached however we made some progress. I would take on the responsibility to help bring tripleo-test-cloud-rh1 more inline with openstack-infra tooling. That includes, but is not limited to: - Initial support for centos-7 jenkins slave (tripleo-ci) https://review.openstack.org/#/c/312725/ - Add centos-7 to tripleo cloud (project-config) https://review.openstack.org/#/c/311721/ - Revert "Revert "Migrate tripleo to centos-7"" (project-config) https://review.openstack.org/#/c/327425/ - Revert "Disable tripleo-test-cloud-rh1 until we have AFS mirrors" (project-config) https://review.openstack.org/#/c/349659/ - Add tripleo-test-cloud grafana dashboard https://review.openstack.org/#/c/351251/ And various other reviews adding AFS mirrors for centos / epel. Updates to tripleo-ci using our openstack-infra AFS mirrors along with providing general support for both tripleo-test-cloud-rh1 and tripleo-test-cloud-rh2. In a short amount of time, we've made great progress with tripleo-test-cloud-rh1, helping bring it more inline with openstack-infra tooling. While we are not finished, there is still some private infrastrucuture that tripleo-ci is depending on. I am confident in the next 3 months we should have that all replaced and using openstack community infrastruture. However on Friday[2], we started talking about tripleo-test-cloud-rh1 again in #openstack-infra and found ourselves revisiting the original email. It is all driven from the current effort from tripleo to start using move community clouds for running tripleo-ci jobs. Today, 3 different type of tripleo-ci jobs are now run across all our clouds, for example there is a centos-7-2-node jobs. However, tripleo-test-cloud-rh1 is only today setup to accept only tripleo-ci jobs. This job does not run on tripleo-test-cloud-rh1. jeblair posted the following statement: It feels like the tripleo cloud has been grandfathered in its current state for a while. I'd just like to make sure we're being fair to everyone. So if tripleo wants to run tripleo jobs, then i think we should move it to 3rd party ci. I think that's a fine choice and we can continue to work together (please!) but with better division of reponsibilities. Or, if we want to revise the idea of a multi-provider hardware platform that's available for all openstack projects, i'm game for that. It would be great, but more work. Should we continue the push to move tripleo-test-cloud-rh1 to 3rd party CI (removing from nodepool.o.o) or do we start enabling more jobs on tripleo-test-cloud-rh1 bringing the cloud even more into openstack-infra? My personal thoughts, as somebody who's been working on it for the last 4 months, I still feel tripleo-test-cloud-rh1 should move to 3rd party CI. However, with the work done in the last 4 months, I believe tripleo-test-cloud-rh1 _could_ start running additional jobs based on the work above. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088988.html [2] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-08-05.log.html#t2016-08-05T23:07:35 __________________________________________________________________________ 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