- Zuul-discuss - lists.opendev.org

ansible version for linting?
by Andreas Jaeger 23 May '19

23 May '19

Which ansible version should we use for linting in repos like openstack/project-config, openstack/openstack-zuul-jobs and zuul/zuul-jobs? OpenDev runs ansible 2.7 which is the default for Zuul - but Zuul supports 2.5 (as deprecated) and 2.6 and soon 2.8 as well... So, do we lint with the oldest version? The newest? The default? right now we use ansible 2.5.x for linting. I proposed the first changes to go to 2.7 - but then thought further and wrote this email: https://review.opendev.org/#/c/659810/ https://review.opendev.org/#/c/659811/ Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 1

Ansible 2.8 support
by Paul Belanger 13 May '19

13 May '19

Greetings, Hopefully this week ansible 2.8.0 will be released, yay. As a results, Tobias as already done most of the work[1] to get Zuul ready to support it. I'd like to ask for humans to review the patch, the main change here for zuul is to our console stream plugin. Ansible 2.8 now includes rescued / ignored in the results output. Also, facts are now disabled by default when using gather_facts. I think it would be awesome if we could land and do a zuul release just after ansible 2.8 was released. Would go well with out story of cross project collaboration. [1] https://review.opendev.org/631933

1 1

Zuul's Roadmap and Backlog
by Tristan Cacqueray 12 May '19

12 May '19

Hello folks, I don't know if this subject has been discussed at the last PTG, so here is a thread about it. There is a growing backlog of bug fixes and features, and it's a bit frustrating not knowing when or if a patch is going to be approved. For the 3.0 release, there was a board with the list of stories and this was very helpful in communicating what was going to be included and what should have been reviewed. Would it be possible to use such board for the next releases? As an example, here is a not exhaustive list of features with unknown status. Wouldn't it help to pin them to a release so that reviewer/contributor could help efficiently? * topic:github-review-reporter * topic:zubbi-integration * topic:pagure-driver * topic:web-openapi * topic:zuul_admin_web * topic:scale-out-scheduler * topic:freeze_job Regards, -Tristan

5 9

Job doesn't enter the gate pipeline
by Vitaliy Lotorev 11 May '19

11 May '19

Hi, I'm trying to setup Zuul with in-house Gerrit. check jobs from independent pipeline are started in predictable way (on new PS and 'recheck' comment). The issue is I can't start jobs in buildroot_gate (dependent) pipeline. I simplified pipeline to this one: - pipeline: name: buildroot_gate manager: dependent require: gerrit: open: true trigger: gerrit: - event: comment-added comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*gate success: gerrit: Verified: 1 mysql: failure: gerrit: Verified: -1 mysql: I.e. for debug purpose I'd like buildroot_gate pipeline to get started on 'gate' comment. Once I add 'gate' comment to PS Zuul on Gerrit Scheduler successfully detects this and reports the as follows: scheduler_1 | 'url': ' https://mycompanygerrit/c/production/vip1-boards/sd-fc/+/12134'}] scheduler_1 | 2019-05-09 20:53:58,502 DEBUG zuul.Scheduler: Change <Change 0x7f18e2104c50 production/vip1-boards/sd-fc 12$ 34,12> has been updated, clearing dependent change caches scheduler_1 | 2019-05-09 20:53:58,502 DEBUG zuul.GerritConnection: Scheduling event from gerrit: <GerritTriggerEvent comm$ nt-added mycompanygerrit/production/vip1-boards/sd-fc master 12134,12 Verified:0, Code-Review:1> scheduler_1 | 2019-05-09 20:53:58,502 DEBUG zuul.Scheduler: Run handler awake scheduler_1 | 2019-05-09 20:53:58,502 DEBUG zuul.Scheduler: Fetching trigger event scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Scheduler: Processing trigger event <GerritTriggerEvent comment-added ge$ rit.elvees.com/production/vip1-boards/sd-fc master 12134,12 Verified:0, Code-Review:1> scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Pipeline.nto7.buildroot_gate: Event <GerritTriggerEvent comment-added ge$ rit.elvees.com/production/vip1-boards/sd-fc master 12134,12 Verified:0, Code-Review:1> for change <Change 0x7f18e2104c50 p$ oduction/vip1-boards/sd-fc 12134,12> matched <GerritEventFilter types: comment-added ignore_deletes: True comments: (?i)^($ atch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*gate> in pipeline <DependentPipelineManager buildroot_gate> scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Pipeline.nto7.buildroot_gate: Considering adding change <Change 0x7f18e2$ 04c50 production/vip1-boards/sd-fc 12134,12> scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Pipeline.nto7.buildroot_gate: Change <Change 0x7f18e2104c50 production/v$ p1-boards/sd-fc 12134,12> can not merge, ignoring scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Pipeline.nto7.buildroot_gate: Change <Change 0x7f18e2104c50 production/v$ p1-boards/sd-fc 12134,12> is not ready to be enqueued, ignoring scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Pipeline.nto7.check: Starting queue processor: check scheduler_1 | 2019-05-09 20:53:58,503 DEBUG zuul.Pipeline.nto7.check: Finished queue processor: check (changed: False) scheduler_1 | 2019-05-09 20:53:58,504 DEBUG zuul.Pipeline.nto7.gate: Starting queue processor: gate scheduler_1 | 2019-05-09 20:53:58,504 DEBUG zuul.Pipeline.nto7.gate: Finished queue processor: gate (changed: False) scheduler_1 | 2019-05-09 20:53:58,504 DEBUG zuul.Pipeline.nto7.buildroot_gate: Starting queue processor: buildroot_gate scheduler_1 | 2019-05-09 20:53:58,504 DEBUG zuul.Pipeline.nto7.buildroot_gate: Finished queue processor: buildroot_gate (c hanged: False) Please, note Scheduler logs "can not merge, ignoring", "is not ready to be enqueued, ignoring". How could I understand the reason why it can't be merged? This PS it definitely mergable manually: I could vote +2 and Sumbit the PS. -- Regards, Vitaliy

2 2

Correct way to trigger a periodic job manually
by Ian Wienand 07 May '19

07 May '19

Hello, The manual says to trigger a periodic job against master you'd do [1] $ zuul enqueue-ref --tenant openstack --trigger timer --pipeline periodic --project openstack/example_project --ref refs/heads/master Which looks about right to me, but this sets a newrev of 00..000 which is not correct; e.g. [2]. Tracing back that job to find the cause of the RETRY_LIMIT on ze06 I see: --- 2019-05-06 07:20:50,875 DEBUG zuul.AnsibleJob: [build: b1387c9741134f83a6f11e1cad0386f0] Checking out master 2019-05-06 07:20:50,877 ERROR zuul.AnsibleJob: [build: b1387c9741134f83a6f11e1cad0386f0] Exception while executing job Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/git/refs/symbolic.py", line 305, in set_reference obj = self.repo.rev_parse(ref + "^{}") # optionally deref tags File "/usr/local/lib/python3.5/dist-packages/git/repo/fun.py", line 213, in rev_parse obj = name_to_object(repo, rev[:start]) File "/usr/local/lib/python3.5/dist-packages/git/repo/fun.py", line 147, in name_to_object raise BadName(name) gitdb.exc.BadName: Ref 'master' did not resolve to an object During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/zuul/executor/server.py", line 790, in execute self._execute() File "/usr/local/lib/python3.5/dist-packages/zuul/executor/server.py", line 914, in _execute repo.checkout(selected_ref) File "/usr/local/lib/python3.5/dist-packages/zuul/merger/merger.py", line 369, in checkout File "/usr/local/lib/python3.5/dist-packages/git/refs/symbolic.py", line 308, in set_reference raise ValueError("Could not extract object from %s" % ref) ValueError: Could not extract object from master --- I set newref manually to the git master HEAD change-id, and it did work -- but it looks different to jobs actually triggered by the periodic driver itself. For example [3] is the job I triggered, and [4] is one from the periodic driver -- [4] does not have a newref. I feel like this used to work, probably because when I look back I wrote that bit of documentation [5] ;) I guess something changed; perhaps it is the client setting newref to 0000.000 by default instead of something like None? Any tips on what should I update the instructions to say now? -i [1] https://zuul-ci.org/docs/zuul/admin/client.html#manual-enqueue-examples [2] http://zuul.openstack.org/build/b1387c9741134f83a6f11e1cad0386f0 [3] http://zuul.openstack.org/build/8781cd38097b437d90ba5a9a5505633c [4] http://zuul.openstack.org/build/d30f960f7ca04b33af1eb5b7513b1b66 [5] https://review.opendev.org/#/c/518662/

2 2

exclude-unprotected-branches equivalent for Gerrit connection
by Brendan Jackman 07 May '19

07 May '19

Hi all, In my org's Gerrit setup, refs under personal/$username/ are a free-for-all. I have seen the same in other organisations too. This leads to the problem that is solved for Github by exclude-protected-branches; those branches eventually end up with broken Zuul configs (actually case that brought this to my attention is that I cannot delete a job that is no longer used, because the config in a personal/ branch refers to it). It seems like a simple solution would be to add an option under tenant.untrusted-projects.<project> that can be used to filter the branches considered by Zuul, by their name. I think the most obvious interface for that would be like job.files & job.irrelevant-files, i.e. a regex or list thereof, with a negative complement option alongside it. I think it could then behave much like exclude-unprotected-branches in that it works at the source connection level. Although I've mentioned Gerrit, I don't see why it shouldn't be independent of the actual source connection driver. This seems suspiciously obvious so I suspect I may be rather naive in suggesting it! Has it been discussed before, does it present more complications than I can see? I'm not too sure how this would related to tags. What does Zuul do with those? I didn't give the proposed option a name because I don't know if what I really want is a ref filter or a branch filter. In fact, I face a certain degree of pain because a couple the projects my Zuul deployment checks out have a lot of tags[1] so maybe this could kill two birds with one stone. Cheers, Brendan [1] $ git ls-remote --tags --refs git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git | wc -l 2763 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed (‘intended recipient’). Accordingly the dissemination, distribution, copying or other use of this email or any of its content by any person other than the intended recipient may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the intended recipient, please let us know as soon as possible and remove this email from your system. Company Reg No: 06855929 | Blu Wireless Technology Ltd, 5th Floor, 1 Temple Way, Bristol, BS2 0BY | Registered in England & Wales

2 2

Inheritance confusion, docs needed?
by Michael Johnson 06 May '19

06 May '19

As a developer creating Zuul jobs, one of the areas i find confusing is the inheritance of variables. I am not sure if this is an enhancement style request or just a missing section in the documentation. When you use host-vars, the top level variables are "merged" with the parent job variables, however the nested variables, such as "devstack_localrc" are not merged, they are "replaced". As an example is the opendev Zuul jobs (I think this applies to non-OpenStack jobs as well): When you use host-vars, the top level variables are "merged" with the parent job variables, however the nested variables, such as "devstack_localrc" are not merged, they are "replaced". host-vars: controller: devstack_localrc: DATABASE_USER: a-user In this example snippet, the variables at the devstack_localrc level are "merged", but the variables at the "DATABASE_USER" level are replaced and not inherited from the parent. Should Zuul be recursively "merging" all the way down or should we document how/which variables are inherited from the parent and which are not? The reason I'm asking is as our job definitions get more complicated (multi-node), I find myself copying variables from the parent jobs that I would really like to just inherit. Michael

2 1

Zuul working group session at OpenInfra Summit
by corvus＠inaugust.com 29 Apr '19

29 Apr '19

Hi, If you're at the OpenInfra Summit and would like to discuss what is or isn't working about sharing jobs between Zuul installations, please join the working group session on Tuesday: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23736/z… -Jim

1 0

Celebrating Zuul's OSF Top Level Project Confirmation
by Clark Boylan 28 Apr '19

28 Apr '19

Zuul was confirmed by the OSF board as a top level OSF project today in Denver. To celebrate we'd like to meetup for arcade games, drinks, and food at FTW Denver Monday night. This is doubling as the OpenDev Infra team gathering, but considering the overlap between Zuul and Infra I figure that won't be an issue. If you'd like to join us we will be gathering at 6:45pm Monday in front of the big blue bear statue at the convention center. If it is raining, we'll likely meet up just inside the convention center building next to the statue to stay dry. Hope to see you there and congratulations Zuul! Clark

1 0

Tagging beta / rc releases
by Paul Belanger 24 Apr '19

24 Apr '19

Greetings, I wanted to raise the topic of maybe using beta / rc tags to publish pre-release versions of zuul / nodepool to pypi. Currently, before each official release we usually select a git SHA to be installed onto zuul.opendev.org, to ensure we can run a scale without any issues. Then a few days later, if things are well we tag a new release or work to address the problem. Then restart the process until things look good. I really like this approach, as currently there is no larger zuul and helps to catch any issues before our users install the released version. However, I would like to propose we make a minor change, is when we select to git SHA, is to also tag it using a pre-release version number (eg: beta / rc). By having it pre-release, (eg: pip install --pre zuul) would allow my current tooling (today we only installed from pypi, not git) to pick up the change and also provide some feedback. Our deployment tooling is setup to only use releases from pypi (wheels) in an effort to try not to carry any patches downstream. We could also switch to pip install via git, however this would add some extra overhead to production servers to compile wheels. - Paul

3 8