[openstack-dev] [tripleo][ci] TripleO OVB check gates to move to third party
Ben Nemec
openstack at nemebean.com
Tue Jun 13 19:11:53 UTC 2017
On 06/13/2017 12:28 PM, Paul Belanger wrote:
> On Tue, Jun 13, 2017 at 11:12:08AM -0500, Ben Nemec wrote:
>>
>>
>> On 06/12/2017 06:19 PM, Ronelle Landy wrote:
>>> Greetings,
>>>
>>> TripleO OVB check gates are managed by upstream Zuul and executed on
>>> nodes provided by test cloud RH1. RDO Cloud is now available as a test
>>> cloud to be used when running CI jobs. To utilize to RDO Cloud, we could
>>> either:
>>>
>>> - continue to run from upstream Zuul (and spin up nodes to deploy
>>> the overcloud from RDO Cloud)
>>> - switch the TripleO OVB check gates to run as third party and
>>> manage these jobs from the Zuul instance used by Software Factory
>>>
>>> The openstack infra team advocates moving to third party.
>>> The CI team is meeting with Frederic Lepied, Alan Pevec, and other
>>> members of the Software Factory/RDO project infra tream to discuss how
>>> this move could be managed.
>>>
>>> Note: multinode jobs are not impacted - and will continue to run from
>>> upstream Zuul on nodes provided by nodepool.
>>>
>>> Since a move to third party could have significant impact, we are
>>> posting this out to gather feedback and/or concerns that TripleO
>>> developers may have.
>>
>> I'm +1 on moving to third-party...eventually. I don't think it should be
>> done at the same time as we move to a new cloud, which is a major change in
>> and of itself. I suppose we could do the third-party transition in parallel
>> with the existing rh1 jobs, but as one of the people who will probably have
>> to debug problems in RDO cloud I'd rather keep the number of variables to a
>> minimum. Once we're reasonably confident that RDO cloud is stable and
>> handling our workload well we can transition to third-party and deal with
>> the problems that will no doubt cause on their own.
>>
> This was a goal for tripleo-test-cloud-rh2, to move that to thirdparty CI,
> ensure jobs work, then migrated. As you can see, we never actually did that.
>
> My preference would be to make the move the thirdparty now, with
> tripleo-test-cloud-rh1. We now have all the pieces in place for RDO project to
> support this and in parallel set up RDO cloud to run jobs from RDO.
>
> If RDO stablility is a concern, the move to thirdparty first seems to make the
> most sense. This avoid the need to bring RDO cloud online, ensure it works, then
> move it again, and re-insure it works.
>
> Again, the move can be made seemless by turning down some of the capacity in
> nodepool.o.o and increase capacity in nodepool.rdoproject.org. And I am happy to
> help work with RDO on making this happen.
I'm good with doing the third-party migration first too. I'm only
looking to avoid two concurrent major changes.
More information about the OpenStack-dev
mailing list