Open Stack

On 30/11/15 22:18, Steven Hardy wrote:
> On Mon, Nov 30, 2015 at 12:51:53PM -0500, Ruby Loo wrote:
>>     On 30 November 2015 at 10:19, Derek Higgins <derekh at redhat.com> wrote:
>>
>>       Hi All,
>>
>>       Â  Â  A few months tripleo switch from its devtest based CI to one that
>>       was based on instack. Before doing this we anticipated disruption in the
>>       ci jobs and removed them from non tripleo projects.
>>
>>       Â  Â  We'd like to investigate adding it back to heat and ironic as
>>       these are the two projects where we find our ci provides the most value.
>>       But we can only do this if the results from the job are treated as
>>       voting.
>>
>>     What does this mean? That the tripleo job could vote and do a -1 and block
>>     ironic's gate?
>
> I believe it means they would be non voting, but cores should be careful
> not to ignore them, e.g if a patch isn't passing tripleo CI it should be
> investigated before merging said patch.

Exactly, this is pretty much the situation in tripleo and has worked 
quit well.

>
>>       Â  Â  In the past most of the non tripleo projects tended to ignore the
>>       results from the tripleo job as it wasn't unusual for the job to broken
>>       for days at a time. The thing is, ignoring the results of the job is the
>>       reason (the majority of the time) it was broken in the first place.
>>       Â  Â  To decrease the number of breakages we are now no longer running
>>       master code for everything (for the non tripleo projects we bump the
>>       versions we use periodically if they are working). I believe with this
>>       model the CI jobs we run have become a lot more reliable, there are
>>       still breakages but far less frequently.
>>
>>       What I proposing is we add at least one of our tripleo jobs back to both
>>       heat and ironic (and other projects associated with them e.g. clients,
>>       ironicinspector etc..), tripleo will switch to running latest master of
>>       those repositories and the cores approving on those projects should wait
>>       for a passing CI jobs before hitting approve. So how do people feel
>>       about doing this? can we give it a go? A couple of people have already
>>       expressed an interest in doing this but I'd like to make sure were all
>>       in agreement before switching it on.
>>
>>     This seems to indicate that the tripleo jobs are non-voting, or at least
>>     won't block the gate -- so I'm fine with adding tripleo jobs to ironic.
>>     But if you want cores to wait/make sure they pass, then shouldn't they be
>>     voting? (Guess I'm a bit confused.)
>
> The subtext here is that automated testing of OpenStack deployments is
> hard, and TripleO CI sometimes experiences breakage for various reasons
> including regressions in any one of the OpenStack projects it uses.
>
> For example, TripleO CI has been broken for the last day or two due to a
> nodepool regression - in this scenario it's probably best for Ironic and
> Heat cores to maintain the ability to land patches, even if we may decide
> it's unwise to land larger and/or more risky changes until they can be
> validated against TripleO CI.
>
> Steve
>
> __________________________________________________________________________
> 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
>