[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