[Gluster-infra] Zuul?

[Nigel Babu]

On Fri, Sep 02, 2016 at 03:40:39PM +0530, Sankarshan Mukhopadhyay wrote:
> On Fri, Sep 2, 2016 at 3:27 PM, Kaushal M <kshlmster at gmail.com> wrote:
> > I'd brought up Zuul a long while back. The opinion then was that,
> > while a gatekeeper is nice, we didn't want to maintain anymore infra
> > over what we had at the time. We tried to make Jenkins itself do the
> > work, which hasn't succeeded as well as we hoped.
> >
> > With you being dedicated to maintain the infra, this will be a nice
> > time to revisit/investigate Zuul again.
>
> I'd propose that concerns of maintenance/administration be separated
> from the value accrued by this move. This approach worked out well
> during the JJB task.
>
> So, a question for Nigel - when you propose Zuul - what is the flow
> and benefits that you see being available to the project? Have you
> previously worked with Zuul or, can cite situations where adoption of
> Zuul has helped?
>
>
> > On Fri, Sep 2, 2016 at 3:01 PM, Nigel Babu <nigelb at redhat.com> wrote:
> >> Hello,
> >>
> >> We've had master breaking twice in this week because we of when we run
> >> regressions and how we merge. I think it's time we officially thought of moving
> >> regressions as a gate controlld by Zuul. And Zuul will do the merge onto
> >> the correct branch.
> >>
> >> This is me throwing the idea about to hear any negative thoughts, before I do
> >> further investigation. What does everyone think about this?
> >>
> >> Note: I've purposefully not CC'd gluster-devel here because I'd rather go to
> >> the full developer team with a proper plan.
> >>
> >> --
> >> nigelb

Here's the flow as I see it:
1. Propose a review request.
2. Smoke tests run as soon as a patchset is created or updated.
3. Reviewer gives +2.
4. Zuul will run regressions in the order than patches received Code Review +2.
   If they pass regression, Zuul will merge them into the branch requested. The
   documentation[1] has a good visualization that will help.
5. If the regression fails, we can still do a retry. Zuul will retry the job on
   top of the existing patch queue rather than in isolation.

I've not worked with Zuul before, but I've talked to colleagues and friends who
work on Openstack. They've switched off Jenkins and completely moved to
Zuul[2]. The primary reason for my original conversation was to reduce friction
in how we do reviews and merge.

I see three key benefits

* Reduced friction for merging code.
* The tip of all branches will always be green.
* We'll only run regressions once the patch is final. Less wasted resources if
  the patch needs changing after code review.

[1]: http://docs.openstack.org/infra/zuul/gating.html#testing-in-parallel

--
nigelb