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 <der...@redhat.com > ><mailto:der...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
