- Zuul-discuss - lists.opendev.org

OSF Community Meeting - June 25 & 26
by Allison Price 16 Jun '20

16 Jun '20

Hi everyone, On June 25 (1300 UTC) and June 26 (0200 UTC) , we will be holding the quarterly OSF community [1] that will cover project updates from all OSF-supported projects and events. The Zuul community is encouraged to prepare a slide and present a 3-5 minute update on the project and community’s progress. The update should cover updates that have occurred since the last community meeting on April 2. If you would like to volunteer to present the Zuul update for one meeting (or both!) please sign up here [1]. We are aiming to finalize the content by Friday, June 19. If you missed the Q1 community meeting, you can see how the upcoming meeting will be structured in this recording [2] and this slide deck [3]. If you have any questions, please let me know. Thanks! Allison [1] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…>

2 1

Fwd: Re: Odd behaviour regarding missing job parent
by Radosław Piliszek 10 Jun '20

10 Jun '20

Forwarding my reply to ml because I forgot to cc. -yoctozepto -------- Forwarded Message -------- Subject: Re: Odd behaviour regarding missing job parent Date: Wed, 10 Jun 2020 08:48:00 +0200 From: Radosław Piliszek <radoslaw.piliszek(a)gmail.com> To: Clark Boylan <cboylan(a)sapwetik.org> On 2020-06-10 00:27, Clark Boylan wrote: > Is your example something like this: > > # Add job foo with undefined parent to branch stable/whatever > - job: > name: foo > parent: exists-only-on-master > > - project: > check: > jobs: > foo > > # Add job foo with undefined parent to branch master > - job: > name: exists-only-on-master > > - job: > name: foo > parent: exists-only-on-master > > - project: > check: > jobs: > foo > > And the job runs properly against the master branch but is silently ignored on the stable/whatever branch? If that is the case I think that may be a subtle but important behavior of variant matching in Zuul. Basically this allows you to retire testing for projects without needing to update every single project to pull jobs out of the project pipeline config. In an OpenStack context this allows us to disable grenade testing on the oldest supported stable branch simply by removing the underlying job parent(s). That's exactly the case! I thought it might have some usage. Thanks for confirming that. > As do its docs, https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.branches, which say: "If there is no job definition for a given job which matches the branch of an item, then that job is not run for the item." Aye, but it gets confusing when you consider inheritance and this paragraph does not discuss it. It seems it can be extended to "not defined or having any undefined ancestor", i.e. I would not be surprised in case like: # Add undefined job foo - project: check: jobs: foo as this is easier to spot and documented there exactly. > I do think that if no branches defined that parent job then you would have received an error, but because the job is only defined on particular branches it is assumed that you only want to run those jobs on those branches. Yeah, that makes sense. Only the inheritance part made it confuse me. -yoctozepto

1 0

Odd behaviour regarding missing job parent
by Radosław Piliszek 10 Jun '20

10 Jun '20

Hiya Zuulers! I am writing to ask about a curious behaviour of Zuul that I observed in the Kolla project. [1] So I noticed some defined-and-added-to-pipelines jobs are not being run and was curious what is going on. It turns out we mistakenly forgot to add the parent jobs definitions. However, Zuul did not protest and simply ignored these jobs (which easily went unnoticed). I find it a bit confusing considering how easy it is to displease Zuul otherwise. :-) Do you consider it a bug? Or is it this way by design? Happy to report a bug. [1] https://review.opendev.org/734685 -yoctozepto

2 1

Zuul Glossary
by helena＠openstack.org 10 Jun '20

10 Jun '20

Greetings Zuul Community! We are on a mission to create a glossary of Zuul related terms and want your help! As the community grows and new contributors want to get involved, we hope to have a consistent definition to help familiarize them with the project. Similarly, having a glossary of terms has proven to be a good SEO tactic to gain more web traffic; by creating this glossary, we are hoping to have greater visibility to potential contributors, users, and supporting organizations. This is where you come in! We need your help to define the terms that we can use to educate future contributors Below is an etherpad link. We ask that you add, edit, review, and collaborate on this etherpad to help us make the Zuul community more accessible and understandable. If you think of more terms to add to the list, please do! As always, feel free to reach out with any questions. Cheers, Helena Zuul: [ https://etherpad.opendev.org/p/Zuul_Glossary ]( https://etherpad.opendev.org/p/Zuul_Glossary )

2 2

Zuul contribs could help shaping the future of ansible-lint
by Sorin Sbarnea 05 Jun '20

05 Jun '20

As I observed that few complains about ansible-lint being buggy or not very useful, it may be a good time to advertise that the project is looking to increase its number of core contribs. Shortly, if you want to make it more relevant now you have the opportunity to mention your interest on: https://github.com/ansible/ansible-lint/issues/815 I will personally support any zuul core that wants to help. IMHO, this means you know python, ansible and how to follow a review process, exactly that the linter needs too. ~zbr

1 0

[diversity] Hour of Healing
by Amy Marrich 03 Jun '20

03 Jun '20

The OSF Diversity and Inclusion Working Group recognizes that this is a trying time for our communities and colleagues. We would like to invite you to 'An Hour of Healing' on Thursday (June 4th at 17:30 - 18:30 UTC) where you can talk to others in a safe place. We invite you to use this time to express your feelings, or to just be able to talk to others without being judged. This session will adhere to the OSF Code of Conduct <https://www.openstack.org/legal/community-code-of-conduct/>and zero tolerance for harassment policy, which means we will not be judging or condemning others (individuals or groups) inside OR outside of our immediate community. We will come together to heal, in mutually respectful dialogue, keeping in mind that while there are many different individual viewpoints, we all share pain collectively and can heal together. We will be using https://meetpad.opendev.org/PTGDiversityAndInclusion for this gathering. The OSF Diversity and Inclusion WG

1 0

RFP: making .sh files browsable instead of downloadable on collected logs.
by Sorin Sbarnea 01 Jun '20

01 Jun '20

Several colleagues told me that since Zuul moved to swift storage, the .sh files are no longer browsable. I agreed with them, so I propose enforcing plain/text mime type for this file extension via: https://review.opendev.org/#/c/731795/ Some argues that doing this may affect other users that may have different expectations, like to download the file and run it locally instead. One such example is the `download-logs.sh` script, which is unlikely that we want to "browse" it (even if running code from the internet without looking at it may count as a real security risk). Usually when I download something, I copy link and user curl to download it to specific location, so I do not feel myself affected. In many cases the script I want to run has to run on another remote machine, so the copy url seems more flexible. Even if we make all .sh files browsable by default, we do not really prevent anyone from triggering the download action from the browser. There are 3 directions we can take here: a) change mime/type to plain/text for .sh files (approve CR) b) keep the current mime/type which triggers download (reject CR) c) add custom exception for download-logs.sh to keep it downloadable (extra work/complexity/where to keep exceptions/...) I hope that c) would not be required because it adds extra complexity at multiple levels, especially as we have multiple storage backends. So please think about it and cast your vote, that is one place where we need a lot of feedback in order to decide which UX is optimal. Thanks Sorin Sbarnea

2 1

Re: Dropping python2.7 from diskimage-builder
by Ian Wienand 30 May '20

30 May '20

On Tue, May 19, 2020 at 08:13:26AM +0100, Mark Goddard wrote: > I would urge caution over dropping Python 2 from branchless projects. > We tried it for Tenks, and within weeks had created a branch from the > last release supporting Python 2 for bug fixes. I certainly get that but it has to happen one day. The gate is broken because we do use requirements from OpenStack and they have moved on to be Python 3 only. Since dib is currently on version 2, perhaps we should tag as version 3 and then leave ourselves the option of a branch from that point, if we find we actually need it? [1] https://review.opendev.org/728889

1 2

Dropping python2.7 from diskimage-builder
by Monty Taylor 20 May '20

20 May '20

Heya, I just pushed up: https://review.opendev.org/728889 Drop support for python2 Which drops support for installing diskimage-builder using python2. It doesn’t drop support for in-image python2, that would be a whole different story. It seems that since the two largest DIB users, OpenStack and Zuul, are both now python3 only, it’s a safe move to make. IBM PowerKVM CI is running third-party CI with python2-based tests. We should probably either update those or just drop it? Thoughts? Monty

3 2

x/gearman-plugin maintenance
by Antoine Musso 15 May '20

15 May '20

Hello, Zuul v2 used Jenkins as a job execution system. The jobs were exposed as Gearman functions through a Jenkins plugin (x/gearman-plugin in Gerrit). I am still using the plugin at Wikimedia and two other persons proposed changes in the last six months but the plugin is an abandoned state. Is there any interest in maintaining the plugin on the opendev infrastructure or should I migrate the changes to github and have the maintenance to occur there? In the end it might be beneficial to maintain it under the Jenkins github organization where it could theoretically receive shared maintenance by other Jenkins authors. Pending changes: * https://review.opendev.org/#/q/status:open+project:x/gearman-plugin Obsolete Jenkins fork: * https://github.com/jenkinsci/gearman-plugin -- Antoine "hashar" Musso

3 3