Open Stack

On 30/11/15 12:51, Ruby Loo wrote:
>
>
> On 30 November 2015 at 10:19, Derek Higgins <derekh at redhat.com
> <mailto: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?
>
>
>          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.)

+1

I don't think it hurts to turn it on, but tbh I'm uncomfortable with the 
mental overhead of a non-voting job that I have to manually treat as a 
voting job. If it's stable enough to make it a voting job, I'd prefer we 
just make it voting. And if it's not then I'd like to see it be made 
stable enough to be a voting job and then make it voting.

- ZB