[openstack-dev] [infra][tripleo] status of tripleo-test-cloud-rh1
openstack at nemebean.com
Mon Aug 8 15:31:40 UTC 2016
On 08/06/2016 07:17 PM, Paul Belanger wrote:
> 5 months ago fungi posted:
> [tripleo] becoming third party CI (was: enabling third party CI)
> 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
> 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)
> - Add centos-7 to tripleo cloud (project-config)
> - Revert "Revert "Migrate tripleo to centos-7"" (project-config)
> - Revert "Disable tripleo-test-cloud-rh1 until we have AFS mirrors" (project-config)
> - Add tripleo-test-cloud grafana dashboard
> 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, 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
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.
>  http://lists.openstack.org/pipermail/openstack-dev/2016-March/088988.html
>  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
More information about the OpenStack-dev