Open Stack

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.

>      Â  Â  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