Open Stack

+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 <trown at redhat.com> 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev