- Zuul-discuss - lists.opendev.org

Wiki article on Zuul
by Jimmy McArthur 01 Jul '20

01 Jul '20

Hi everyone, We're still working to get the Zuul wiki article accepted by Wikipedia. The latest additions we need are: * A table of release history including the date and version of each release. Similar to what you see on the OpenStack wiki [1] * Graphics, diagrams, photos from past presentations/slide decks (preferably published at a known/trusted URL) * More frequent usage of links to other Wikipedia articles You can take a look at the current progress here [2] as well as the current set of proposed edits here [3]. If you all can chip in on any of these, please let me know :) Thank you! Jimmy [1] https://en.wikipedia.org/wiki/OpenStack [2] https://en.wikipedia.org/wiki/Draft:Zuul_(software) [3] https://docs.google.com/document/d/1HOw0weCATKrksxOQrjyIM6bZG7b6Zs_fobeNdZ0…

1 0

[summit][cfp] 2020 Open Infrastructure Summit Call for Presentations Open!
by Jimmy McArthur 01 Jul '20

01 Jul '20

Happy to pass this along from Ashlee Ferguson :)... We’re excited to announce that the Call for Presentations [1] for the 2020 Open Infrastructure Summit is now open until August 4! During the Summit, you’ll be able to join the people building and operating open infrastructure. Submit sessions featuring projects including Airship, Ansible, Ceph, Kata Containers, Kubernetes, ONAP, OpenStack, OPNFV, StarlingX and Zuul! 2020 Tracks • 5G, NFV & Edge • AI, Machine Learning & HPC • CI/CD • Container Infrastructure • Getting Started • Hands-on Workshops • Open Development • Private & Hybrid Cloud • Public Cloud • Security Types of sessions * Presentations; demos encouraged * Panel Discussions * Lightning Talks o If your talk is not selected for the official track schedule, we may reach out to have you present it as a Lightning Talk during the Summit in a shorter 10-15 minute format SUBMIT YOUR PRESENTATION [1] - Deadline August 4, 2020 Summit CFP is only for presentation, panel, and workshop submissions. The content submission process for the Forum and Project Teams Gathering (PTG) will be managed separately in the upcoming months. Programming Committee nominations are also now open. The Programming Committee helps select sessions from the CFP for the Summit schedule. Nominate yourself or or someone else for the Programming Committee [2] before July 10, 2020 and help us program the Summit! Registration and sponsorship coming soon! For sponsorship inquiries, please email kendall(a)openstack.org <mailto:kendall@openstack.org>. Please email speakersupport(a)openstack.org <mailto:speakersupport@openstack.org> with any CFP questions or feedback. Thanks, Ashlee [1] cfp.openstack.org <http://cfp.openstack.org> [2] https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum… Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 0

zuul on ubuntu with gitlab
by Michiel Piscaer 29 Jun '20

29 Jun '20

Hi, I try i install zuul on a ubuntu bionic system, where I use gitlab as git source. For this I used the following commands: https://gist.github.com/mpiscaer/2e731c8becea781c4521cc15b5cfeabe I had some issues to figure out how the cloning works with gitlab. For this it work I had to change the authentication call from "Authorization': 'Bearer %s" to PRIVATE-TOKEN': '%s' in the gitlabconnection.py and I had to specify the cloneurl variable. I'm currently figuring out the pipeline. I have copied the github pipeline, but with this I get some errors: https://gist.github.com/mpiscaer/325b15afbd94f6fff5c8a12788827481 Do I something working with this pipeline and is it compatible with gitlab? Kind regards, Michiel Piscaer

3 2

wrap vs no-wrap on zuul console and log browsing
by Sorin Sbarnea 29 Jun '20

29 Jun '20

As I personally found the log browsing experience with Zuul painful, mainly to due weird rendering, I tried to address if with several changes. Please watch this movie in order to understand the lack of wrapping issue, which is causing nausea/motion-sickness, https://sbarnea.com/ss/Screen-Recording-2020-06-18-11-59-31.mp4 IMHO, text on web pages was created to wrap, presence of horizontal scrolling is, in most cases, a sign of bad implementation. My attempt to address this and force wrapping was blocked at https://review.opendev.org/#/c/723603/ as few others Zuul core liked the current non-wrapping behavior (present in several places) and asked me to gather feedback from users regarding what would be good UX. I will try to contact some UX communities as zuul-discuss mailing list is not very active. I am really curious what an UX-designer would have to say about that, maybe it would not be bad to have a couple of them to consult us in our UI decisions. AFAIK, there is no other CI/CD that does not wrap console/log lines when browsing them (at least not on purpose). Mainly we NEED feedback from *you* because without it nothing will happen. Please reply to this thread or better on the review. Thanks Sorin Sbarnea

4 5

internationalization for the web UI
by Matthieu Huin 27 Jun '20

27 Jun '20

Hello, Here is a WIP patch that aims to add support for translating Zuul's web UI: https://review.opendev.org/737290 . After trying unsuccessfully to work with react-i18next [0] as it seems to be the most popular i18n library for react, I've had more success with react-redux-i18n [1] (i18next didn't seem to play nice with some redux things). This choice of library, however, is not perfect: Pros: - relatively painless integration with zuul-web's existing code Cons: - no new commit on the library in 2 years - All the translations are loaded in the store as the web app is initially loaded in the browser. There aren't many text strings to localize, but as more languages get supported, this might mean a lot of potentially useless data will have to be downloaded in the browser. (OTOH react-i18next can load the right locale when needed) If there any better choices of library and/or implementation, please let me know through reviews. Until then I won't work more on this, as listing the translatable strings is a bit of a chore and I'd rather make sure we're all on agreement about how to do Zuul i18n. Once this is cleared, will come the fun times of nitpicking exact translations of Zuul terms in the language of your choice. :) Cheers, [0]: https://react.i18next.com/ [1]: https://github.com/artisavotins/react-redux-i18n -- Matthieu Huin Senior Software Developer Red Hat <https://www.redhat.com> <https://red.ht/sig>

5 9

GitLab driver - gate pipeline implementation with the GitLab approval system
by Fabien Boucher 26 Jun '20

26 Jun '20

Hi, I'd like to share my plan regarding the implementation of a gate pipeline for the GitLab driver. GitLab provides a merge request approval system that we could leverage to implement it. The current status of the GitLab driver proposed into that Gerrit topic [1] is: - Support for the Push, Tag, Merge Request, and Comment events. - Support for a comment reporter. The buildset status is only reported into a merge request's comment. Thus I'd like to add an approval reporter that Zuul will use to set its approval on the Merge Request in case of buildset success. The GitLab Merge Request's approvals system allows a project owner to define multiple approval rules [2]. When a Merge Request is approved by all requested approvers then GitLab unlock the merge Merge Request API endpoint. A project's owner could define a rule for the Zuul CI where that rule's approver will be the Zuul user. The GitLab API provides an endpoint to approve and unapprove a Merge Request. To make a Merge Request enter a gate pipeline we need to listen to approval events. Approval events are sent to the web-hook system so by using this as a trigger and also by reading the approval + mergeability status as a requirement we should have the minimal needed information to make a gate pipeline configuration. I've run some initial tests by playing with the GitLab approval API and it seems that the related endpoints + events are available with the free SAS offering on gitlab.com (I was able to use the API with the free plan but note that the approvals documentation [2] specifies that the feature is only available with the starter/bronze plan). So this is something I don't get at the moment ... But before moving forward with the implementation, I'd like to get your thoughts about this. Regards Fabien Boucher [1]: https://review.opendev.org/#/q/topic:gitlab+project:zuul/zuul+status:open [2]: https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approv…

2 1

OSF Community Meeting 1 Recording & Slides
by Allison Price 25 Jun '20

25 Jun '20

Hi everyone, Thank you for joining today’s OSF Community Meeting. If you missed the meeting, you have a few options on getting updated on what was covered. You can listen to the recording [1] and check out the slides [2] that were presented this morning. I have also attached a PDF of the slides if that’s easier to access. There will be a second OSF Community Meeting covering the same material tomorrow, Friday, June 26 at 0200 UTC (today, June 25 at 7pm PT). You can find the lineup of speakers and dial-in information here [3]. Stay tuned for the next all project, quarterly update that will be held in September. Cheers, Allison [1] https://zoom.us/rec/share/vJF_FqPgxGJJQ9bntR7vaqM7N7i_X6a81yQa8vtcxU06amK9p… <https://zoom.us/rec/share/vJF_FqPgxGJJQ9bntR7vaqM7N7i_X6a81yQa8vtcxU06amK9p…> Password: 7W!T*i74 [2] https://docs.google.com/presentation/d/16V82OIYfthb3fFlVoes9jZGKMgDIJZ55F8f… [3] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

Avoiding collisions for github-mirroring job
by Thierry Carrez 22 Jun '20

22 Jun '20

Hi Zuulites, The github-mirroring job we introduced recently not being atomic, it regularly fails[1] when two changes get merged in the same repository in succession. [1] https://zuul.opendev.org/t/openstack/builds?job_name=openstack-upload-githu… It's not a critical issue, as the job is idempotent: the situation will likely be fixed at the next merge in the same repository. Still, it bothers me and I've been looking at ways to basically avoid the job running concurrently for a given repository. We can't use supercedent, as it only guarantees uniqueness for a given project-ref, and here multiple project-refs are involved. Solution A would be to make sure the mirroring job only pushes what it's supposed to push, and can run concurrently. But there are lots of corner cases (like pushing tags on releases), and that would result in losing its idempotency, which is a really nice safety net to have. Solution B would be to use a semaphore for accessing GitHub. The issue with this solution is that it would lock across all mirroring jobs for all openstack repositories, so there is risk of creating a backlog. Maybe job.semaphore.resources-first would keep it contained... Solution C would be to introduce a new feature: implicit semaphores for each repository. That would allow jobs to use a project-specific semaphore without having to define explicitly a semaphore entry for each project in Zuul. Solution D would be to introduce a new pipeline manager that would be like supercedent, but for projects instead of project-refs. Then we'd create a new pipeline using that manager, and assign the github_mirroring job to that pipeline. Thoughts on those options? Any preference? Something else I did not consider? -- Thierry Carrez (ttx)

5 6

Re: zuul-jobs: remove default 'tox_envlist: venv' from tox roles.
by corvus＠inaugust.com 19 Jun '20

19 Jun '20

albin vass <albinvass(a)gmail.com> writes: > Hey all! > > We're planning on aligning the tox roles to better mirror the > behaviour of running tox on the command line. Most of this is already > done by running the default envlist configured in tox.ini if > tox_envlist is set to an empty string, and by running all test > environments if set to 'ALL'. > > But the last step is to allow users to just run 'tox' as a job the > same way it works when it is run on the command line. To do this we > need to remove 'tox_envlist: venv' from the default configuration of > the roles. > > We will deprecate this behaviour by merging [1] with a short notice > period of one week since we believe this behaviour is not currently > being used anywhere. > > [1] - https://review.opendev.org/#/c/726830/24 After some further discussion[2], we will postpone this to 4 weeks from now: July 16, 2020. Thanks, Jim [2] http://lists.zuul-ci.org/pipermail/zuul-discuss/2020-June/001263.html

1 0

Re: zuul-jobs: remove default 'tox_envlist: venv' from tox roles.
by corvus＠inaugust.com 19 Jun '20

19 Jun '20

Paul's reply went to the announce list; I'm resending it to the discuss list: > From: Paul Belanger <pabelanger(a)redhat.com> > Subject: Re: zuul-jobs: remove default 'tox_envlist: venv' from tox roles. > To: zuul-announce(a)lists.zuul-ci.org > Date: Thu, 18 Jun 2020 12:48:31 -0400 (2 hours, 33 minutes, 5 seconds ago) > > On Thu, Jun 18, 2020 at 06:03:27PM +0200, albin vass wrote: >> Hey all! >> >> We're planning on aligning the tox roles to better mirror the >> behaviour of running tox on the command line. Most of this is already >> done by running the default envlist configured in tox.ini if >> tox_envlist is set to an empty string, and by running all test >> environments if set to 'ALL'. >> >> But the last step is to allow users to just run 'tox' as a job the >> same way it works when it is run on the command line. To do this we >> need to remove 'tox_envlist: venv' from the default configuration of >> the roles. >> >> We will deprecate this behaviour by merging [1] with a short notice >> period of one week since we believe this behaviour is not currently >> being used anywhere. >> > Based on deprecation policy[2], we are to give 2 weeks not 1. I am pretty > sure we are using it in zuul.ansible.com, but haven't had time to > validate. I expect this to be a largish change for us, I would like to > ask if there is no rush to maybe hold off for 4 weeks? > > We have a 1.0.0 release for ansible collections happening now, and head > down on that. > > Thanks for understanding. > > [2] https://zuul-ci.org/docs/zuul-jobs/policy.html#deprecation-policy >> [1] - https://review.opendev.org/#/c/726830/24 Thanks for letting us know -- one of the reasons we send out announcements like that is to make sure we're not about to break someone and give ourselves a chance to slow down or stop if necessary. It does look like there's at least some reference to the tox "venv" in the ansible-zuul-jobs repo: https://github.com/ansible/ansible-zuul-jobs/search?q=venv+tox&unscoped_q=v… One of the things we learned as part of making this change is that it's a much narrower change than it sounds like -- merely having and using a "venv" environment doesn't automatically mean the change will be breaking; most of the time it won't, which is why we felt relatively confident that no one would be using this in a way that would be broken by the change. But it's a risk that needs to be evaluated. Long story short: I agree with you that we should not rush this change and we should give time to evaluate the impact. I'm still hopeful the answer will be "nope, it doesn't affect Ansible after all". Either way is a fine outcome and time well spent. I agree under the circumstances we should at least honor the standard two-week deprecation period. Albin, is there anything else waiting on this work, or should we go ahead and bump it to one month? Once we agree on that, we'll send an updated announcement to the announce list. -Jim

2 1