[OpenStack-Infra] ZUUL query: instead of layout.yaml, parameter-function can be use to control job flow ?

Bhavik Bavishi bhavikdbavishi at gmail.com
Fri Oct 7 05:54:26 UTC 2016


On 10/7/16 4:16 AM, James E. Blair wrote:
> Bhavik Bavishi <bhavikdbavishi at gmail.com> writes:
>
<snip>
>
> Hi,
>
> The parameter function is used to alter the run-time parameters for a
> job that Zuul has already decided to run.  I don't believe it can be
> used to decide not to run a job.
>
> You can control what jobs run on what branches for given projects using
> the "jobs" section in layout.yaml.
>
>   http://docs.openstack.org/infra/zuul/zuul.html#jobs
>
> In our setup in OpenStack, our job names are based on git repos (so we
> have "gate-nova-python27" and "gate-keystone-python27" as job names).
> That means we can write:
>
>   jobs:
>     name: gate-nova-python27
>     branch: master
>
> To indicate that the python27 job for nova should only run on the master
> branch.
>
> The branch specifier can be a regular expression:
>
>   jobs:
>     name: gate-nova-python27
>     branch: ^(?!stable/(liberty|mitaka)).*$
>
> Which says: run the nova python27 job on any branch except
> stable/liberty or stable/mitaka.
>
> Even the job name can be a regex:
>
>   jobs:
>     name: ^gate-.*-python27$
>     branch: ^(?!stable/(liberty|mitaka)).*$
>
> (Run all python27 jobs on any branch except stable/liberty or
> stable/mitaka.)
>
> The inability to match by project (only implicitly by including the
> project name in the job name) is a limitation.  We are going to fix that
> in Zuul v3 and make this sort of thing much easier to specify.  However,
> the ability to use regular expressions in those fields does give a lot
> of flexibility, and with a little bit of planning, very sophisticated
> conditionals are possible today.
>
> I hope that helps, and I'm happy to help with more detailed plans if
> that isn't sufficient.
>
> -Jim
>

Hi Jim,

Thank you for reply, we then added regular expression + skip-if to 
control job flow.

One off-topic query, is there any tool/script to display DAG of 
layout.yaml in GUI ? so that one can see for any modifications how job 
process flow would look like, before push it to live production. We do 
check exit status of "zuul-server -l /etc/zuul/layout.yaml -t" before 
deploy 'layout.yaml' .

I understand that, we need to check and refactor our job process and 
other stuffs, below is reference scenario in our current process part, 
we have 3 stacks which has nearly 45 components and STACK1 consists of 
30 components.

(1) our ex. project templates are as below ...
project-templates:
   - name: STACK1
     check:
         - STACK1_BUILD_JOB:
            # below is common job for STACK1 and STACK2
            - STACK_PACKAGE_JOB:
              # below is common job for all stacks
              - STACK_TEST_JOB
     gate:
- STACK1_DEPLOY_JOB
   - name: STACK2
     check:
         - STACK2_BUILD_JOB:
            # below is common job for STACK1 and STACK2
            - STACK_PACKAGE_JOB:
              # below is common job for all stacks
              - STACK_TEST_JOB
     gate:
- COMMON_DEPLOY_JOB
   - name: THIRDPARTY
     check:
         - THIRDPARTY_PACKAGE_JOB:
              # below is common job for all stacks
            - STACK_TEST_JOB
     gate:
- COMMON_DEPLOY_JOB

STACK1 =
--------------+--------------------+--------------------
  COMP         | BRANCHES           |
--------------+--------------------+--------------------
  component A  | rel1, maint, next  | no change
  component B  | rel1, maint        | removed in 'next'
  component C  | rel1, next         | added in 'next'
--------------+--------------------+--------------------
(2) build jobs are dedicated for each stack, since we have ZUUL_PROJECT 
which refer to component name which is name of git repo, we are good.
(3) build jobs are again common across the branch, but for maint and 
next branches have same stack name but different set of components, few 
are removed and few added and mostly remains same.
(4) as you can see above 'STACK_TEST_JOB' common across all stacks.
(5) 'STACK_PACKAGE_JOB' is shared b/w STACK1 and STACK2, here we hit the 
issue as it get more of regular expressions and skip-if blocks, as few 
of components in STACK1 for given branch nothing perform.

While searching I found some what near implantation of 
'paramter-function' at 
https://phabricator.wikimedia.org/diffusion/CICF/browse/master/zuul/parameter_functions.py 
using this idea wanted to check if ZUUL can be dynamic about job 
configuration that for given STACK and BRANCH some predefined hierarchy 
because for given STACK most of component inter-dependent and few are 
independent.

I agree that every tool/project has its own world to get thing work.

- Bhavik




More information about the OpenStack-Infra mailing list