Open Stack

On 08/06/2016 07:17 PM, Paul Belanger wrote:
> 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.

I was always in favor of going third-party, so +1 to that option.  If we
still insist on staying integrated then I think it's totally fair to say
we need to start running other jobs too though.

Long term we'd still like to get away from needing to run on a custom
cloud, but until OVB support is available in more of the regular infra
clouds I think we're stuck with our custom one.

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