Open Stack

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