Re: [openstack-dev] [tripleo] use mitaka CI tested repo

[Dan Prince]

On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote:
> Hi,
> 
> I'm wondering why don't we use Mitaka CI tested repository [1].
> IIRC, TripleO is currently using a snapshot which is updated
> asynchronously by TripleO CI folks.
> The problem is that we're not consistent with what RDO CI is testing.
> In
> my memory and tell me if I'm wrong but it happens we're using an old
> snapshot of packages which is older that is actually tested &
> verified
> by RDO CI.
> 
> The benefit of using this tested repo would be:
> * this repository is already gated by Weirdo [2] which is running the
> same jobs as Puppet OpenStack CI.
> * you would not have less jobs failures, because RDO CI would have
> detected bugs before.
> * tripleo folks could focus a bit more on features & bugfixes in
> TripleO
> itself, rather than debugging CI issues and slowing down the review
> process.
> * Puppet OpenStack CI became really stable since we're using this
> repository. We have a very few number of issues since then.
> 
> Though, something I don't like in my proposal:
> * tripleo would not bring short feedback to RDO folks if something is
> broken
> 
> But is TripleO supposed to debug other projects in the same time?
> Don't
> we have enough challenges in our project?
> 
> This would be a temporary solution I think, until TripleO would be
> part
> of other upstream project gate (nova, etc) maybe one day.
> But at this time, I honestly think TripleO (which is an installer)
> folks, spend too much time at debugging CI for some reasons that are
> related to projects outside tripleo (puppet modules, openstack bugs,
> packaging issues, etc).
> 
> This is just a proposal and an idea to help TripleO folks to focus on
> their review process, instead of debugging CI failures every week.

The problem I think is largly due to the fact that the RDO CI doesn't
test the same things we do in the TripleO CI. It is essentially a
different CI system.

Because the CI systems are different different breakages happen when
you try to update one component vs. another. This is why we have to
maintain 'current-tripleo' separately between RDO and TripleO.

I agree it would be nice if we could consolidate on a single repository
across these projects. It would allow us to focus on review more...
(less CI fixing).

Perhaps a test matrix comparing the two CI systems would help us get
them closer to parity with what is covered. Even better would be just
simply contributing to the same CI systems and scripts.

Dan

> 
> 
> Thanks for reading so far.
> Your feedback and comments are more than welcome.
> 
> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re
> po
> [2] https://github.com/redhat-openstack/weirdo
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] use mitaka CI tested repo

[Emilien Macchi]

Hi,

I'm wondering why don't we use Mitaka CI tested repository [1].
IIRC, TripleO is currently using a snapshot which is updated
asynchronously by TripleO CI folks.
The problem is that we're not consistent with what RDO CI is testing. In
my memory and tell me if I'm wrong but it happens we're using an old
snapshot of packages which is older that is actually tested & verified
by RDO CI.

The benefit of using this tested repo would be:
* this repository is already gated by Weirdo [2] which is running the
same jobs as Puppet OpenStack CI.
* you would not have less jobs failures, because RDO CI would have
detected bugs before.
* tripleo folks could focus a bit more on features & bugfixes in TripleO
itself, rather than debugging CI issues and slowing down the review process.
* Puppet OpenStack CI became really stable since we're using this
repository. We have a very few number of issues since then.

Though, something I don't like in my proposal:
* tripleo would not bring short feedback to RDO folks if something is broken

But is TripleO supposed to debug other projects in the same time? Don't
we have enough challenges in our project?

This would be a temporary solution I think, until TripleO would be part
of other upstream project gate (nova, etc) maybe one day.
But at this time, I honestly think TripleO (which is an installer)
folks, spend too much time at debugging CI for some reasons that are
related to projects outside tripleo (puppet modules, openstack bugs,
packaging issues, etc).

This is just a proposal and an idea to help TripleO folks to focus on
their review process, instead of debugging CI failures every week.


Thanks for reading so far.
Your feedback and comments are more than welcome.

[1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.repo
[2] https://github.com/redhat-openstack/weirdo
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] use mitaka CI tested repo

[John Trowbridge]

On 01/29/2016 09:40 AM, Dan Prince wrote:
> On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote:
>> Hi,
>>
>> I'm wondering why don't we use Mitaka CI tested repository [1].
>> IIRC, TripleO is currently using a snapshot which is updated
>> asynchronously by TripleO CI folks.
>> The problem is that we're not consistent with what RDO CI is testing.
>> In
>> my memory and tell me if I'm wrong but it happens we're using an old
>> snapshot of packages which is older that is actually tested &
>> verified
>> by RDO CI.
>>
>> The benefit of using this tested repo would be:
>> * this repository is already gated by Weirdo [2] which is running the
>> same jobs as Puppet OpenStack CI.
>> * you would not have less jobs failures, because RDO CI would have
>> detected bugs before.
>> * tripleo folks could focus a bit more on features & bugfixes in
>> TripleO
>> itself, rather than debugging CI issues and slowing down the review
>> process.
>> * Puppet OpenStack CI became really stable since we're using this
>> repository. We have a very few number of issues since then.
>>
>> Though, something I don't like in my proposal:
>> * tripleo would not bring short feedback to RDO folks if something is
>> broken
>>
>> But is TripleO supposed to debug other projects in the same time?
>> Don't
>> we have enough challenges in our project?
>>
>> This would be a temporary solution I think, until TripleO would be
>> part
>> of other upstream project gate (nova, etc) maybe one day.
>> But at this time, I honestly think TripleO (which is an installer)
>> folks, spend too much time at debugging CI for some reasons that are
>> related to projects outside tripleo (puppet modules, openstack bugs,
>> packaging issues, etc).
>>
>> This is just a proposal and an idea to help TripleO folks to focus on
>> their review process, instead of debugging CI failures every week.
> 
> The problem I think is largly due to the fact that the RDO CI doesn't
> test the same things we do in the TripleO CI. It is essentially a
> different CI system.
> 
> Because the CI systems are different different breakages happen when
> you try to update one component vs. another. This is why we have to
> maintain 'current-tripleo' separately between RDO and TripleO.
> 
> I agree it would be nice if we could consolidate on a single repository
> across these projects. It would allow us to focus on review more...
> (less CI fixing).
> 
> Perhaps a test matrix comparing the two CI systems would help us get
> them closer to parity with what is covered. Even better would be just
> simply contributing to the same CI systems and scripts.
>

I think contributing to the same scripts would be a big win. From the
'undercloud install' on, it is totally feasible for both CI systems to
use the same script right now.

I am working on using tripleo.sh in rdoci, which modulo the different
environment setups, would get us to the above goal.

If we could then get tripleoci consuming the same pre-built
undercloud.qcow2 that rdoci is using[1], I think the environment
differences would be negligible.

[1]
https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2

> Dan
> 
>>
>>
>> Thanks for reading so far.
>> Your feedback and comments are more than welcome.
>>
>> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re
>> po
>> [2] https://github.com/redhat-openstack/weirdo
>> _
>> _
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [tripleo] use mitaka CI tested repo

[David Moreau Simard]

+1 for aligning efforts between Triple-O and RDO Manager around CI.

There's been a *lot* of work (trown++) towards RDO Manager CI and it'd
be great if Triple O could benefit from that.
Like Emilien said, our test coverage for promoting a set of packages
to "current-passed-ci" is huge already and will keep on improving.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Fri, Jan 29, 2016 at 10:42 AM, John Trowbridge  wrote:
>
>
> On 01/29/2016 09:40 AM, Dan Prince wrote:
>> On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote:
>>> Hi,
>>>
>>> I'm wondering why don't we use Mitaka CI tested repository [1].
>>> IIRC, TripleO is currently using a snapshot which is updated
>>> asynchronously by TripleO CI folks.
>>> The problem is that we're not consistent with what RDO CI is testing.
>>> In
>>> my memory and tell me if I'm wrong but it happens we're using an old
>>> snapshot of packages which is older that is actually tested &
>>> verified
>>> by RDO CI.
>>>
>>> The benefit of using this tested repo would be:
>>> * this repository is already gated by Weirdo [2] which is running the
>>> same jobs as Puppet OpenStack CI.
>>> * you would not have less jobs failures, because RDO CI would have
>>> detected bugs before.
>>> * tripleo folks could focus a bit more on features & bugfixes in
>>> TripleO
>>> itself, rather than debugging CI issues and slowing down the review
>>> process.
>>> * Puppet OpenStack CI became really stable since we're using this
>>> repository. We have a very few number of issues since then.
>>>
>>> Though, something I don't like in my proposal:
>>> * tripleo would not bring short feedback to RDO folks if something is
>>> broken
>>>
>>> But is TripleO supposed to debug other projects in the same time?
>>> Don't
>>> we have enough challenges in our project?
>>>
>>> This would be a temporary solution I think, until TripleO would be
>>> part
>>> of other upstream project gate (nova, etc) maybe one day.
>>> But at this time, I honestly think TripleO (which is an installer)
>>> folks, spend too much time at debugging CI for some reasons that are
>>> related to projects outside tripleo (puppet modules, openstack bugs,
>>> packaging issues, etc).
>>>
>>> This is just a proposal and an idea to help TripleO folks to focus on
>>> their review process, instead of debugging CI failures every week.
>>
>> The problem I think is largly due to the fact that the RDO CI doesn't
>> test the same things we do in the TripleO CI. It is essentially a
>> different CI system.
>>
>> Because the CI systems are different different breakages happen when
>> you try to update one component vs. another. This is why we have to
>> maintain 'current-tripleo' separately between RDO and TripleO.
>>
>> I agree it would be nice if we could consolidate on a single repository
>> across these projects. It would allow us to focus on review more...
>> (less CI fixing).
>>
>> Perhaps a test matrix comparing the two CI systems would help us get
>> them closer to parity with what is covered. Even better would be just
>> simply contributing to the same CI systems and scripts.
>>
>
> I think contributing to the same scripts would be a big win. From the
> 'undercloud install' on, it is totally feasible for both CI systems to
> use the same script right now.
>
> I am working on using tripleo.sh in rdoci, which modulo the different
> environment setups, would get us to the above goal.
>
> If we could then get tripleoci consuming the same pre-built
> undercloud.qcow2 that rdoci is using[1], I think the environment
> differences would be negligible.
>
> [1]
> https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2
>
>> Dan
>>
>>>
>>>
>>> Thanks for reading so far.
>>> Your feedback and comments are more than welcome.
>>>
>>> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re
>>> po
>>> [2] https://github.com/redhat-openstack/weirdo
>>> _
>>> _
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>>> cribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage