[openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job
shardy at redhat.com
Tue Dec 1 11:01:49 UTC 2015
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.)
> 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 ;)
More information about the OpenStack-dev