Open Stack

On Tue, Jun 13, 2017 at 3:11 PM, Ben Nemec <openstack at nemebean.com> wrote:
>
>
> 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.

+1, I do agree with Ben here.

Go for it!

>
> __________________________________________________________________________
> 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



-- 
Emilien Macchi