Open Stack

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
>