Open Stack

On Mon, Nov 30, 2015 at 06:07:44PM -0500, Zane Bitter wrote:
> 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.

I don't think anyone is saying it's not ever going to be voting, it's just
an up-front recongnition that right now it sometimes isn't reliable enough
because there are significant outages, which TripleO will get blamed for,
even if it's a regression in a project (maybe one of those helpfully
ignoring non-voting jobs ;)

Steve