[OpenStack-Infra] Junior Jobs, possibly around zuul

Antoine Musso hashar at free.fr
Fri Oct 31 13:38:36 UTC 2014


Le 30/10/2014 15:14, Andrew Mason a écrit :
> Greetings all,
> I'm looking to gain some understanding of the CI infrastructure and
> thought it might help if I worked on a few junior bugs as a goal. I was
> wondering if there were any particular issues that people could suggest
> as a good starting point. Zuul looked like an interesting project as I
> am fan of Git;  If anyone has any particular gripes then I'm happy to
> head in the direction if you're willing to offer some assistance when
> you have the time.
> 
> Kind regards
> Andrew

Hello Andrew,

I have a few ideas which I never bothered filling as bugs so here they are:

Zuul client)

The Zuul client let and administrator interacts with the scheduler,
currently let you enqueue a new change, promote a change in the pipeline
queue and show the currently running jobs.

 Current usage: http://ci.openstack.org/zuul/client.html

We could use a method to for retriggering a single change. If we use
enqueue, the scheduler would not reenqueue it because it is already
present. Something like  zuul requeue :D

I would love the 'show' command to provide:

- a thin wrapper around Gearman "status" and "workers" administrative
commands. Possibly with filtering and an option to select the output
format (PrettyTable/json)
- the ability to dump the various queues (event, management..) and per
optionally per pipeline for the event one

https://review.openstack.org/#/c/68828/ implemented the show
running-jobs command. Could be a good base.


An utility that would send a manually crafted event, pass it through a
layout and yield the workflow decision that has been taken. That would
be quite useful to write integration tests of a layout workflow (for
example ensure 'recheck' on a patch that has Approval +1 is enqueued in
the gate pipeline).


Zuul webapp)

Add an administration interface that would let folks promote/enqueue
changes directly from http://status.openstack.org/zuul/ . That would let
scale out administrations tasks since a shell access would no more be
required.

A change that just has been submitted list jobs as being "queued". Could
use a next state of "merge pending" while waiting for the merger to
complete its work.


Zuul logs)

The debug logs can take a lot of disk space unfortunately
logging.handlers does not have one to compress rotate files which would
be handy.

The pipelines loggers use their class name as a key ie:

 zuul.IndependentPipelineManager:
 zuul.DependentPipelineManager:

Would be nice to replace the key with the pipeline name, possibly
something like:

  zuul.pipeline.gate
  zuul.pipeline.postmerge
  ...

When a change is received, it is passed through all the pipelines that
decides whether they are interested.  When dismissing the event, each
pipeline log at error level causing output like:


ERROR zuul.IndependentPipelineManager: Unable to find change queue for
project foo
ERROR zuul.IndependentPipelineManager: Unable to find change queue for
project foo
ERROR zuul.IndependentPipelineManager: Unable to find change queue for
project foo

Maybe such error should just be an info and an error thrown if none of
the pipeline used the event.



-- 
Antoine "hashar" Musso



More information about the OpenStack-Infra mailing list