[tripleo][ci] TripleO OVB check gates to move to third party

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[tripleo][ci] TripleO OVB check gates to move to third party

Ronelle Landy
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.


Thanks!

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [tripleo][ci] TripleO OVB check gates to move to third party

Juan Antonio Osorio
I would really appreciate that this is done once we finish moving the TLS-everywhere job to run over oooq. This is on the works currently.

On Tue, Jun 13, 2017 at 2:19 AM, Ronelle Landy <[hidden email]> 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.


Thanks!

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Juan Antonio Osorio R.
e-mail: [hidden email]


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [tripleo][ci] TripleO OVB check gates to move to third party

Ben Nemec
In reply to this post by Ronelle Landy


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.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [tripleo][ci] TripleO OVB check gates to move to third party

Paul Belanger-2
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.

PB

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [tripleo][ci] TripleO OVB check gates to move to third party

Ben Nemec


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.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [tripleo][ci] TripleO OVB check gates to move to third party

Paul Belanger-2
On Tue, Jun 13, 2017 at 02:11:53PM -0500, Ben Nemec 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.
>
Great, I am happy to hear that :D

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [tripleo][ci] TripleO OVB check gates to move to third party

Emilien Macchi-4
In reply to this post by Ben Nemec
On Tue, Jun 13, 2017 at 3:11 PM, Ben Nemec <[hidden email]> 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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Loading...