- Zuul-discuss - lists.opendev.org

Can me migrate zuul-jobs towards being an Ansible collection?
by Sorin Sbarnea 22 Jul '20

22 Jul '20

As I really like the quality and reusability of roles present in zuul-jobs, I would like to have bit more flexibility regarding installing them, basically being able to package them and install them as a collection. Can we agree on going into the direction of publishing it as collection in galaxy? The only major issue we have is that galaxy requires all roles not to use dashes, underlines being accepted. I think it may be possible to perform a slow transition by creating symlinks, maybe even combined with a rename of only those that are generic enough, like ensure ones. The idea is that is impossible to publish a collection that contains roles with underlines and this is not going to change. Still, it is possible to package only a set of directories in your collection, ignoring others. The second issue I am aware of is related to documentation. Galaxy expects documentation as markdown and also the meta file. That is not such a big deal as Sphinx can build documentation from both using myst-parser extension. If we agree that we want to go this path, probably it would make sense to start with a one role collection and slowly migrate others. Cheers Sorin Sbarnea

2 1

Moving zuul UI preferences in a single location
by Sorin Sbarnea 06 Jul '20

06 Jul '20

As the number of configurable user preferences seems to be growing (see list below), I think is time to put them in a single place, instead of scattering them in various places in the UI, as this would only clutter it. Also it does not scale well. - timezone config (now on top nav bar) - ability to configure log wrapping on/off (requested) - ability to enable/disable ANSI support (also requested due to performance concerns) - auto-reload on status page - other future options I proposed adding a config icon that popup a dialog where we can put these configurations. https://sbarnea.com/ss/Screen-Shot-2020-07-06-13-43-58.png https://review.opendev.org/#/c/739482/1 - adds the config dialog, dialog is now empty bu the goal was to demonstrate how it would work first. I also proposed removal of cookies and replacement with localStorage, which allowed us to simplify the code and also avoid the GDPR legal issues https://review.opendev.org/#/c/739454/ Regarding enabling ANSI support, there are two alternatives proposed (each using a different react ANSI library) https://review.opendev.org/#/c/739444/ -- via react-ansi (more terminal like, with line numbers) https://review.opendev.org/#/c/716251/ -- via ansi-to-react If we consolidate user configurable preferences into a single screen and make use of localStore it may be much easier to gradually introduce changes in zuul, as we can make them opt-ins. What do you think? Cheers Sorin

2 1

Making yum errors visible by default in zuul
by Sorin Sbarnea 05 Jul '20

05 Jul '20

Few weeks back I proposed a change that would expose the "failures" list of errors in zuul UI when a module returns it, similar to stdout and stderr. The change got in limbo after @corvus remarked that this is not a standard way to return errors for modules. He mentioned that they could get to the full output by pressing the failed button (which is another UX issue by itself because is presented as a label, only few people would guess that this is clickable). The reality more ugly than this, and finding the error for a non-veteran zuul user is a real adventure: * Once landed on the "summary" page the user would see only the "Failed to install some of the specified packages", yep **some**, not the list. * There is no butten user can press from summary page to open full return list. * Hopefully user will decide to pick "console" tab instead of "logs" which would likely confuse him more * Once landed on console page, at least he would see the failed task as red, but still w/o required details * Now he would have to guess that the red [FAILED] block is clickable * After he clicks it, he would finally get to the "failures" list. https://review.opendev.org/#/c/734833/ Returning failures was the behavior of yum module for a very long time and there are no plans to change it from Ansible side (see linked bug). Yum module is one of the most used ones, also a core plugin. Considering that my proposal was to make the field visible in summary and preview happens only when a task failed and contains that field, why do we prefer to cripple the user experience for all users? Even if Ansible would decide to magically make the msg from yum module better, this will not help us for many years. Such a change would not lang sooner than 2.11, which means that at least two more years until we will display friendly errors. I know that likely most, if not all members of zuul-discuss have a good knowledge of Zuul, so you are likely to already know stuff that is not obvious. I encourage you to step back and consider what a first-time contributor, that never used Zuul, would see and do when it gets his first CI failure. The reason why I am writing this is that I am aware of several other UX issues with zuul and I personally faced some less then pleasant feedback from first time users over the last year, especially after I helped enabling Zuul CI on Ansible molecule and ansible-lint projects. I would be very happy if you would join me in my quest for improving Zuul user experience, especially from the browser point of view. Thanks Sorin Sbarnea

2 1

[Diversity] Diversity & Inclusion WG Meeting 7/6
by Amy Marrich 02 Jul '20

02 Jul '20

The Diversity & Inclusion WG invites members of all OSF projects to our next meeting Monday, July 6th, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity -wg-agenda. We will be discussing changing our Wiki page to reflect the broader OSF projects and communities so that the page reflects our mission. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

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 28 Jun '20

28 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 26 Jun '20

26 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 18 Jun '20

18 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 18 Jun '20

18 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

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

15 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 09 Jun '20

09 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 09 Jun '20

09 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 02 Jun '20

02 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 31 May '20

31 May '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 29 May '20

29 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 19 May '20

19 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

retire x/pbrx
by Andreas Jaeger 11 May '20

11 May '20

I'll start the retiring process for the repo x/pbrx, it was created as tools for pbrx but is not used anymore, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

2 2

Feedback on StarlingX pilot project
by Ildiko Vancsa 06 May '20

06 May '20

Hi Zuul Community, I’m reaching out to you about the StarlingX project as they will start their confirmation process with the OSF staff and Board of Directors next week with a few pre-review and early feedback calls to prepare for their confirmation review on the next Board meeting in early June. A draft of the slide deck[1] they plan to present is available for reference. Per the confirmation guidelines[2], the OSF Board of directors will take into account the feedback from representative bodies of existing confirmed Open Infrastructure Projects (Airship, Kata, OpenStack and Zuul) when evaluating StarlingX for confirmation. You may recall this process from when the Zuul Community went through it last year. Particularly worth calling out, guideline #4 "Open collaboration” asserts the following: Project behaves as a good neighbor to other confirmed and pilot projects. If you have any observations/interactions with the StarlingX project which could serve as useful examples for how this project does or does not meet this and other guidelines, please provide them on the etherpad[3] ASAP. If possible, include a citation with links to substantiate your feedback. I'll assemble this feedback and send it to the Board (via the public foundation mailing list) for consideration before their meeting next week. If you could give your feedback till the end of this week that would be highly appreciated. Thanks and Best Regards, Ildikó Váncsa [1] https://drive.google.com/file/d/16FPqzLT_3UH5AbZQJGg5Y9g4CN6AsRmx/view?usp=… [2] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [3] https://etherpad.opendev.org/p/zuul-community-starlingx-confirmation-feedba…

1 1

Fwd: [openstack-community] OpenDev Events Update - we need your feedback!
by Jimmy McArthur 05 May '20

05 May '20

Check it! -------- Forwarded Message -------- Subject: [openstack-community] OpenDev Events Update - we need your feedback! Date: Tue, 5 May 2020 12:35:07 -0500 From: Ashlee Ferguson <ashlee(a)openstack.org> To: community(a)lists.openstack.org, foundation(a)lists.openstack.org Hi everyone, Thanks so much for your feedback that’s continually helping us shape these virtual OpenDev events[1]. Keep reading this email for some important updates on all three events! 1. OpenDev: Large-scale Usage of Open Infrastructure SoftwareJune 29 - * July 1 (1300 - 1600 UTC each day) * Registration is open[2]! * High-level schedule coming soon; Find a brief topic summary and more information here[1] 2. OpenDev: Hardware Automation * July 20 - 22 * Help us pick a time - visit this etherpad[3] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. 3. OpenDev: Containers in Production * August 10 - 12 * Help us pick a time - visit this etherpad[4] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. Find more information and updates on all of these events here[1]. [1] https://www.openstack.org/events/opendev-2020 [2] https://opendev_largescale.eventbrite.com [3] https://etherpad.opendev.org/p/OpenDev_HardwareAutomation [4] https://etherpad.opendev.org/p/OpenDev_ContainersInProduction Thanks! Ashlee Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 0

Consider dropping support for python 3.5 in v4
by Monty Taylor 05 May '20

05 May '20

Hey all, I’d like to propose that we drop support for python 3.5 as part of Zuul v4. With the Python 2.7 EOL, more people are dropping support for 3.5 as well, since one of the main benefits of python3.5 was that it was easier to write code compatible between 2.7 and 3.5. OpenStack in particular, as part of its EOL of python 2.7 support chose python 3.6 as the new minimum. We use OpenStackSDK and keystoneauth from OpenStack in Nodepool - so I’ve made sure OpenStackSDK and keystoneauth retain 3.5 support … but I get the impression it’s only going to be a matter of time before more and more of our dependencies start dropping 3.5 support. Since we have a v4 coming up, I was thinking it would be a good time to raise our minimum as well. Our docker images are currently being built with python 3.8. Ubuntu Bionic (old-its) has python 3.6 and python 3.7 Ubuntu Focal (new-its) has python 3.8 Centos 8 has 3.6 Debian Buster has 3.7 The argument for keeping 3.6 support would be to keep support for CentOS without needing additional repos - but since zookeeper isn’t in CentOS people have to add repos anyway. I believe our Software Factory friends are running on CentOS and are running either 3.7 or 3.8 already? BUT - BMW are running in containers and are running on 3.6 - so while I *would* suggest dropping 3.6 too and just jumping straight to 3.7 as a minimum, I think until BMW are not on 3.6 we should consider that a non-starter. As another impact, we currently have to consider the old version of git that’s in Xenial when doing things, and if we drop 3.5 we will be effectively dropping Xenial which means our min git version we have to consider would also be more recent. We could also wait for v5 - which would be closer to the Xenial’s April 2021 End of Standard Support time. And maybe by then we could also drop 3.6? Or maybe we drop 3.5 for v4 and drop 3.6 for v5 - but we still people about both now so that they can work on getting ready for it? What do people think? Monty

3 3

Fwd: [all][PTL][TC] PTG Signup Last Call
by Kendall Nelson 04 May '20

04 May '20

Hello! In an effort to get a schedule set and posted on the website and so that you can all block your calendars for the event, we ask that *teams finish signing up for time by Sunday, May 10th at 7:00 UTC*. We have done some consolidation to save room resources (as we will have to set up/pay for rooms ahead of time) so if you are in the list below, please note that your room may have changed, but the timing should be the same. Also note, some teams may be set to switch rooms throughout the week. Currently Signed Up Teams: Airship Automation SIG Cinder Edge Computing Group First Contact SIG Interop WG Ironic Glance Heat Horizon Kata Containers Kolla Manila Monasca Multi-Arch SIG Neutron Nova Octavia OpenDev OpenStackAnsible OpenStackAnsibleModules OpenStack-Helm Oslo QA Scientific SIG Security SIG Tacker TripleO Thanks! -The Kendalls(diablo_rojo & wendallkaters)

1 0

Fwd: [all] Virtual PTG Tooling Requirements & Suggestions
by Kendall Nelson 27 Apr '20

27 Apr '20

Hello Everyone :) We want to get your input on tooling for the PTG. We have a general idea of what we have for requirements, but wanted to get the community's input- i.e. make sure we aren't missing any. Here is the list of requirements we have right now[1]. Also, if anyone has suggestions of tools that meet these criteria, we would love to hear them! We are gathering and vetting options for the event and want to make sure nothing gets overlooked. -the Kendalls (diablo_rojo & wendallkaters) [1] https://etherpad.opendev.org/p/virt-ptg-requirements

1 0

Fwd: [all] [PTL][TC] PTG Signup Reminder & PTG Registration
by Kendall Nelson 22 Apr '20

22 Apr '20

Hello! ==Virtual PTG Signup== Wanted to take a second to remind teams about the process for signing up for virtual PTG slots. 0. Look at the slots available and talk to your contributors and team members to find out the best times to signup for. 1. Sign up in the ethercalc [1] for the time slots your team needs. You can sign up for up to 4 hours/day and 16 hours/ the week (restrictions in place until *April 28th at 7:00 UTC*). If you are a SIG or WG, try to keep your conversations at the start of the week wherever possible. Vertical teams, try to focus your conversations towards the latter part of the week (Wednesday-Friday). *AND* 2. Fill out the survey [2] to give us the other team information we need to help facilitate the event. We NEED you to do both steps! I can see a number of teams that have signed up for time, but haven't filled out the survey so please do so ASAP. There are still a lot of slots left! Original thread[3]. ==Registration== After a lot of discussion, we have decided to have registration. It is free but its still extremely important that you register as this is primarily so we have a way to contact attendees with information about the event as we figure the rest of the details out. We will have the registration live next week. -the Kendalls (diablo_rojo & wendallkaters) [1] Ethercalc:https://ethercalc.openstack.org/126u8ek25noy [2] Survey: https://openstackfoundation.formstack.com/forms/june2020_virtual_ptg_survey [3] PTG Layout & Signup Thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht…

1 0

Virtual PTG Layout & Signup
by Kendall Nelson 14 Apr '20

14 Apr '20

Greetings! I am sure you have all been anxiously awaiting more details on how we are going to virtualize the PTG :) After the community meetings we had last week/the week before to understand the key challenges and ideate on solutions, we have a plan! The virtual event will be held from Monday June 1 to Friday June 5. We set up available times in 3 different time windows where each window is a cross over time between at least 2 regions (Window A - Americas/Europe, Window B - Europe/APAC, and Window C - APAC/Americas). Here is an ethercalc[1]. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions in with 4 rules/guidelines. 1. Cross project discussions (i.e. SIGs and horizonal teams), try to schedule yourselves towards the start of the week so that any discussions that might shape those of vertical teams might happen first. 2. Vertical teams (ex. Nova, Cyborg, Manila) should wait till April 6th at 7:00 UTC to start signing up for slots to help prioritize the scheduling of cross project conversations. 3. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 4 hours per UTC day to help keep participants actively engaged. 4. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 16 hours across all time slots to avoid burning out our contributors and to enable participation in multiple teams discussions. Once every team has had a chance to sign up (lets say two weeks from today April 28th at 7:00 UTC) if signing up for more time makes sense, it will be possible. We want to encourage ANY team to sign up, even those that had originally said no to the initial outreach when the PTG was supposed to be in person. The more the merrier! Once you have signed up for time slots, please also fill out this survey[2] with your team information. We need this additional information to help shape other decisions down the road and coordinate other details closer to the event. If you have any issues with signing up your team, due to conflict or otherwise, please let me know! While we are trying to empower you to make your own decisions as to when you meet and for how long (after all, you know your needs and teams timezones better than we do), we are here to help! Continue to check back for updates at openstack.org/ptg. -the Kendalls (diablo_rojo & wendallkaters) [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://openstackfoundation.formstack.com/forms/june2020_virtual_ptg_survey

1 0

Code coverage testing
by Jan Kundrát 14 Apr '20

14 Apr '20

Hi, I'm looking at possible ways of showing how a change in Gerrit affects code coverage. In the end, I would like to show this info for two kinds of projects: - a Python project that is already using the stock tox-py* jobs, - our custom C++ jobs which just call a simple playbok that includes a role which uses Ansible's `command` for execution [1] (and we're only using the existing jobs for basic preparation and log upload). Note that "difference of coverage" is something else than "coverage of the actual diff". Coverage of the diff can be generated by e.g. diff_cover [2]. It shows which lines of the change (patch) were executed. This won't catch this example where all diff lines are covered, but suddenly there's nothing left to execute other_func(): def my_func(): return 666 def other_func(x): return 123 def test_foo(): assert(my_func() == 666) - assert(other_func() == 123) It looks to me that pycobertura [3] can catch this by comparing "previous" and "current" coverage. The catch is that this comparison requires building and running the test suite twice -- once in the usual manner, and then once more for the "previous version". How to determine the previous version? It might not be HEAD~1 because of Zuul's merges into the target branch. Is there a Zuul ref that I can rely on from a context of a job? I think I can use something like HEAD^1 + plus a merge of that into the target branch, but it would be awesome if I could get it from Zuul and not have to duplicate its merge settings in my job. Here's how a simple ad-hoc job which handles my use case for our "custom C++ jobs" might look like: # original content goes here ... git-new-workdir ... pushd workdir-of-previous-version git reset --hard HEAD^1 git merge {{ zuul.branch }} make all make test popd pycobertura diff \ coverage.xml workdir-of-previous-version/coverage.xml \ --source1 . --source2 workdir-of-previous-version However, this is something that is totally non-reusable. Given that I'm already using standard tox-* jobs for our Python jobs, I would prefer to create a reusable job for coverage changes. Ideally, this job would run after my "main" build job, so I think I'm looking for a child job [4]. This job can look at two different artifacts, "previous-coverage" and "current-coverage", run a comparison, generate a nice HTML report, and (possibly) fail if a certain threshold is not met. However, I am not sure if current Zuul artifacts really fully get me there. If this is a "first change in the check pipeline with no parents", i.e., head of the queue, there's no previous change to fetch the results from, so I have to consult some external artifact provider for "latest thing that got merged" version of "coverage". This brings some requirements: - Use of the "gate" pipeline. When there's no "gate", just "check", there's no guarantee that the current state of my destination branch was built as-is. (Possible workaround: a fast-forward-only merge policy in Gerrit and a "promote" pipeline which picks the latest jobs results from "check", see [5] and [6] for how it might look in a slightly different use case...) - A custom artifact registry, or a well-known naming scheme for artifact naming, or Zuul keeping artifact locations persistent when a change merges. Since I don't want to maintain ad-hoc code, I don't want to run my custom image registry per site. Let the gate job upload artifacts with storage URLs such as: /t/{{ zuul.tenant }}/artifacts/{{ zuul.project }}/{{ zuul.newrev }} Suppose my "check" job has no preceding items (no Depends-On, and it's based on something that has been already merged into the target branch). The job.artifacts[] variable is therefore empty, so I have to infer my artifact location. The easieast way is just looking at the current SHA1 of the destination branch, and wget that. Alternative: let Zuul pass artifact location from the "promote" pipeline to "gate" jobs, somehow. That's not all. There are two proposed changes, #2 depends on #1. The child job of #2 depends on the build job of #2, and is correctly executed only after #2's build job succeeds. However, #2's child job also has to wait for artifacts from #1's build job. Can I hold a child job of the second change until not only its parent job completes, but also for the duration of the parent job of the preceding change in the queue? With kind regards, Jan [1] https://gerrit.cesnet.cz/plugins/gitiles/ci/zuul-jobs-cesnet/+/refs/heads/m… [2] https://github.com/Bachmann1234/diff_cover [3] https://pypi.org/project/pycobertura/#command-diff [4] https://zuul-ci.org/docs/zuul/reference/jobs.html#var-zuul.child_jobs [5] https://gerrit.cesnet.cz/plugins/gitiles/ci/zuul-jobs-cesnet/+/refs/heads/m… [6] https://gerrit.cesnet.cz/plugins/gitiles/CzechLight/netconf-cli/+/refs/head…

4 7

Etherpad and Gerrit maintenance on 2020-04-10
by corvus＠inaugust.com 09 Apr '20

09 Apr '20

Hi, Tomorrow, April 10, 2020, the OpenDev team will be performing minor updates to two services. * Gerrit restart for https://review.opendev.org/ at 16:00 UTC. This should be a momentary outage to restart the service in a container. We will maintain the same version in the same configuration; this is a preparatory step in order to perform future version upgrades more easily. Other than a short outage of about a minute, there should be no service impact or visible changes, but since the environment is changing, we wanted to announce this in case any problems are detected. * Etherpad migration and domain change at 17:00 UTC. We will migrate the data currently hosted on etherpad.openstack.org to a new server, also running in a container, on etherpad.opendev.org. We will set up redirects so that on completion of the migration, all etherpad.openstack.org URLs will redirect to the same pages on etherpad.opendev.org. https://etherpad.opendev.org/ will become the new canonical service URL. This also includes an upgrade to the latest release of Etherpad Lite (1.8.0). This involves a database migration as well. The service will be unavailable for the duration of this migration (expected to be about 30 minutes). Please report any issues in #opendev on Freenode or to the service-discuss(a)lists.opendev.org mailing list. Note that this message is being sent to service-announce and several other lists. Future announcements of this type will only be sent to service-announce, so please sign up[1] for that list if you haven't already. [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce -Jim

1 0

Prepare workspace roles
by corvus＠inaugust.com 09 Apr '20

09 Apr '20

Hi, Related to that thread we were pulling on in IRC this morning, I think there's some refactoring we can do for setting up git repos on remote nodes. We currently have the following roles: * mirror-workspace-git-repos Uses git over ssh or kubectl to push repos onto remote vms or containers. No support for cached repos. Trusted playbooks only. * prepare-workspace Starts the Zuul console daemon. Uses synchronize to push the repos onto remote vms. No support for cached repos. Can run in untrusted playbooks. * prepare-workspace-git Clones cached repos into place. Includes mirror-workspace-git-repos role to use git over ssh or kubectl to push repos onto remote vms or containers. Trusted playbooks only. OpenDev is using this role. * prepare-workspace-openshift Uses "oc rsync" to push repos onto remote containers. No support for cached repos. Can run in untrusted playbooks. It seems to me that if we set aside the requirement to be able to run in untrusted playbooks, then we effectively already have a single role that can perform the necessary tasks in all conditions. My understanding is that the untrusted forms are used to support a split base job construction, where a tenant's default parent job is actually defined in an untrusted repo and performs many setup tasks in that job, inheriting very few (or no) tasks from a parent in a trusted repo. That makes it easier to test changes to the default parent job speculatively. The question I have for the community is whether at this point that is still worth the trade off in complexity of using rsync to set up git repos? We now have much better testing of changes to roles used in base jobs, including a test which currently covers prepare-workspace-git[1]. Also, these roles change a lot less often than they used to. If we're okay dropping that requirement, I'd like to suggest that we incorporate 'mirror-workspace-git-repos' into 'prepare-workspace-git', and then deprecate all the other roles, and eventually remove them. That would mean we could have a very clear suggested base job, and we'd all be using the same role. What do folks think about that? [1] https://opendev.org/zuul/zuul-jobs/src/branch/master/zuul-tests.d/general-r… -Jim

2 1

Synchronizing to containers
by corvus＠inaugust.com 09 Apr '20

09 Apr '20

Hi, Earlier today in IRC several of us started pulling on a thread related to base pre- and post-run playbooks and containers. In short, we use the synchronize module a lot, and it only works on VMs. The fetch-output role is designed to address this partially, by reducing the number of indepedent synchronize tasks, but in order to synchronize files from a remote container, it needs to run "oc rsync" on the executor, which means that trick will only work in a trusted playbook. That may be okay for that role, but it still leaves any other role or playbook that needs to synchronize something without an important tool. We came up with a plan to improve the situation which should fit within the following constraints: * Not a Zuul-specific solution (playbooks can still run outside of Zuul). * Usable in untrusted playbooks. * Makes VM or container transparent to the role (works the same on both). The general idea is to make a new Ansible module using the collections framework which behaves the same as the current 'synchronize' module, but transparently supports containers by using "oc rsync". This module will be available automatically in Zuul, and users will be able to install the module on their own, external to Zuul, using the Ansible collections feature. Here are the steps to achieve this: 1) Create a new module in Zuul which is a fork of synchronize[1] with Tristan's oc rsync patch[2]. This module will be named "zuul.posix.synchronize" to indicate that it is related to the upstream "ansible.posix.synchronize" module. 2) Start using that in zuul-jobs roles that use synchronize. 3) Create a new repo named "zuul/ansible-collection-posix" and copy the module into that. 4) Publish that repo as an Ansible collection. 5) Install that collection in the Zuul Ansible virtualenvs for versions which support collections and use that in favor of the built-in module. 6) When all Zuul Ansible versions support collections, remove the built-in module. I don't think it's our job to make *everything* about VMs and containers transparent in Zuul, but for something so basic as getting data to and from remote nodes, I think it should be easy to handle both cases, and will make it easier for us to keep a lot of roles simple. How does this sound to folks? [1] https://github.com/ansible-collections/ansible.posix/blob/master/plugins/mo… [2] https://review.opendev.org/681553 -Jim P.S. Monty also suggests that we can similarly move the Zuul-specific modules such as zuul-console and zuul-return into standalone collections repo. That seems like a good idea too, as it may aid local development and testing of playbooks.

1 0

[OSF Community Meeting] Community Meeting Recap
by Jimmy McArthur 06 Apr '20

06 Apr '20

Hi everyone, Thank you to those who attended any of the community meetings last week! If you missed one of the calls last week, below are links to the presentation [1], recording in English [2], and recording in Mandarin [3]. A lot of links were discussed and you can find those in the meeting section of the notes as well as the chat from the recordings. We are planning to do this format with project and community updates and OSF event updates quarterly. Stay tuned for the next meeting, and let me know if you have any questions in the meantime. In addition to the quarterly meetings, we would like to hear from the project communities on topics you would like to cover in community meetings or have covered. If you have an idea you would like to share, please drop it in this etherpad [4]. If you see a topic already shared that you would like to collaborate on, please share your name, email and IRC nick next to the topic. Cheers, Jimmy [1] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… [3] https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b… [4] https://etherpad.openstack.org/p/OSF_Community_Meetings

1 0

New OpenDev Communication Channels
by Clark Boylan 06 Apr '20

06 Apr '20

Hello All, Recently, we've transitioned to using #opendev on Freenode for our synchronous IRC communications. Since then we've spun up a new service-discuss(a)lists.opendev.org mailing list [1] where we'll plan changes to services, notify of meetings, answer questions about services and usage, and otherwise communicate about OpenDev. service-announce(a)lists.opendev.org [2] will remain for important announcements. If you're interested in the developer infrastructure we run please join us on these mailing lists. We encourage every developer to at least subscribe to the service-announce[2] list. It will be very low traffic, and used only for important announcements with wide impact. We are also going to start having our weekly team meeting in #opendev-meeting. The time will continue to be 19:00 UTC Tuesdays. See you there, Clark [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-discuss [2] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce

1 0

Renaming install-$foo roles to ensure-$foo
by albin vass 03 Apr '20

03 Apr '20

Hi, There were some discussion on irc yesterday about getting some better role name consistency, more specific the install-$foo vs ensure-$foo. The idea is to be more consistent when naming roles that makes sure some software is installed on a node. A question from me was if there could be any difference between the install-$foo vs ensure-$foo, my guess is that there isn't since they should be idempotent. I've pushed a couple of changes with the topic role-naming-consistency that renames all roles to the ensure-$foo naming standard and should mostly work by now. https://review.opendev.org/#/q/status:open+project:zuul/zuul -jobs+branch:master+topic:role-naming-consistency At the moment the old install-$foo roles are kept and include the new ensure-$roles to make sure nothing breaks. Regards Albin

2 1

Fwd: OpenStack Foundation Community Meetings
by Allison Price 02 Apr '20

02 Apr '20

Hi everyone - In case you didn’t see the post on the Foundation mailing list, we have a community meeting tomorrow where we will be talking about updates to OSF events as well as OSF project updates. One meeting will be in English and one in Mandarin. Bring your questions and see you then! Cheers, Allison > Begin forwarded message: > > From: Allison Price <allison(a)openstack.org> > Subject: OpenStack Foundation Community Meetings > Date: March 26, 2020 at 10:21:15 AM CDT > To: foundation(a)lists.openstack.org > > Hi everyone, > > Next week we are going to have two community meetings to discuss the OpenStack 10th anniversary planning, current community projects, and an update on OSF events. Please join if you would like to hear updates or if you have questions for the OpenStack Foundation team. > > Join us: > Thursday, April 2 at 10am CT / 1500 UTC <https://zoom.us/j/913456204> > Friday, April 3 in Mandarin at 10am China Standard Time <https://zoom.us/j/389363434> > > If you are unable to join one of the above times, I will share a recording to the mailing list after the meetings. > > Cheers, > Allison > > > Allison Price > OpenStack Foundation > allison(a)openstack.org <mailto:allison@openstack.org> > > > >

1 1

[Zuul Community] Virtual OpenDev Update
by Jimmy McArthur 31 Mar '20

31 Mar '20

Hi everyone, As we continue to gather feedback and discuss what a virtual OpenDev will look like, we wanted to provide you with an update around the event. While we are still attempting to solve some of the riddles of virtual event world, we did come up with some decisions that give us something to build on, which are based on input and experience from members of the Programming Committee. Decisions: - OpenDev will happen after the Virtual PTG (exact format and timing TBD) - Will not be simultaneous/parallel Tracks so everyone has the opportunity to participate in more than one - 3 Tracks, each on different date: - Hardware Automation - Large Scale Ops - Containers in Production We also discussed the original intent and goals of OpenDev to make sure we’re still heading in a direction that’s beneficial for the community, especially since it will no longer directly precede the upcoming PTG. Similar to past OpenDev events, the goal is to identify the questions we don’t have the answers for, and to use that time to dive in and determine the work ahead of us, working together, sharing use cases, and learning from other people asking those same questions. High-level decisions, goals, and some areas we’re looking for feedback are in the etherpad below. As you continue to experience this new amazing world of virtual events, please add any feedback or ideas to the etherpad below. We’re looking forward to creating virtual OpenDev with you all! https://etherpad.openstack.org/p/Virtual_OpenDev_Planning Ashlee Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 0

Keeping linear Git history for Zuul-gated projects
by Vitaliy Lotorev 31 Mar '20

31 Mar '20

Hi, I'm evaluating Zuul for project gating. Currently my team is using Fast Forward Only submit strategy [1] with Gerrit Autosubmitter plugin [2]. Code-Review labels are copied if change is rebased trivially (no code change). We use Fast Forward to keep Git history without merges and I wouldn't like to loose this feature while switching to Zuul. I see that all projects gated with Zuul (e.g. Zuul itself, OpenStack) are using Merge If Necessary strategy. My confusion is: Gerrit has six different merge strategies and Zuul is responsible for merging all the code. Is there any combination of Gerrit/Zuul settings to preserve linear Git history? I'm trying to understand what is wrong with Rebase If Necessary and Cherry Pick strategies. Why these strategies are not preferred for Zuul-gated projects? Will Zuul fetch random commits from A-B-C chain while using Cherry Pick or it will try to preserve the order? [1] https://gerrit-review.googlesource.com/Documentation/concept-changes.html#s… [2] https://gerrit.googlesource.com/plugins/autosubmitter/ Regards, Vitaliy

5 6

Fwd: [all] Virtualized PTG Brainstorming Community Meetings
by Kendall Nelson 30 Mar '20

30 Mar '20

Hello Everyone! So! After Marks initial email[1] that announced we would be virtualizing the PTG and collected volunteers[2] to help brainstorm the best way to hold the PTG virtually, we polled the volunteers for the best times to meet. In trying to be the most inclusive we have settled on three meetings to brainstorm together as a community. They are as follows: - April 2nd at 12:00 UTC - April 6th at 17:00 UTC - April 7th at 2:00 UTC We will be using my zoom[3] and continue using the same etherpad [2] that we collected volunteers in for all the notes from all three meetings. All are welcome! And if you can attend more than one meeting, please do! The more overlap we have the more cohesive discussions we will have. Hope to see you all there! -Kendall Nelson (diablo_rojo) [1] http://lists.openstack.org/pipermail/foundation/2020-March/002854.html [2] https://etherpad.openstack.org/p/Virtual_PTG_Planning [3] https://zoom.us/my/diablorojo

1 0

User Survey for Zuul
by Jimmy McArthur 27 Mar '20

27 Mar '20

The OSF would like to help put together a User Survey with the Zuul Community to see if we can find out how your users are using Zuul in production. This would be an anonymized survey, but would hopefully give the project greater insight into ways that people are using the software and how to make improvements/changes moving forward. If this sounds like something people are interested in, let me know and I'll start an etherpad with some basic questions. If you'd like to see an example of a survey we worked with the Kata community on, you can take a look at a PDF here: https://drive.google.com/file/d/1gZd2rh2jG2IkKBmhBeqFyB-KZCBrHLni/view?usp=… If this seems like a horrible idea, please don't hesitate to tell me that as well :) Cheers, Jimmy

8 26

How & Where to Contribute Zuul Content
by Allison Price 26 Mar '20

26 Mar '20

Hi everyone, As more users start telling their stories about running Zuul in production and accompanied by the amount of events that have been transformed to virtual experiences, I wanted to reach out to the community to make sure everyone was aware of the community channels we have available to share case studies / tutorials / project news as well as increasing the visibility of software updates and release features. As of yesterday, we had an OpenStack user reach out about how to find bug fix updates online more easily, and I think that this could happen for Zuul very soon too. Since Zuul doesn’t have a blog, I would love to discuss where software updates and bug fixes could live beyond the mailing list so that it’s a bit more discoverable for newbies. One option would be putting a Blog section up on Zuul's website. Another could be choosing an open source blogging platform that we could link to (ideally under a Zuul subdomain). Thoughts? Another place the Zuul Community can contribute is Superuser <https://superuser.openstack.org/>. Here's what kind of content you can share and how to contribute: Superuser has evolved to cover the open infrastructure landscape covering different use cases and open source projects. Whether it’s a video or an article, this content is typically more in depth than what you would see on a project blog and includes things like hands on tutorials, case studies, thought leadership articles, Q&As with open source community leaders, and updates and highlights from open source events around the world. If you have an idea you would like to share, fill out this form <https://superuser.openstack.org/contribute/> and the editorial team will reach out. If you have questions about whether your topic is the right fit, email editor(a)openstack.org <mailto:editor@openstack.org>. You can also attend the OSF community meeting <http://lists.openstack.org/pipermail/foundation/2020-March/002856.html>next week to learn more about how you can get involved and contribute! Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org

1 0

Farewell Zuulers
by David Shrewsbury 26 Mar '20

26 Mar '20

Hi fellow Zuulers, It turns out that burnout is a real thing, and all the nastiness that comes along with it. Having been in the OpenStack/Zuul world for 8 years (wow), I feel like it's time for me to move on to new things. Effective this week, I'm giving up my core status on all-the-things, but I absolutely know that I'm leaving it all in awesomely capable hands. I'll miss working with you all, and it has been my absolute pleasure to have worked with you. You've each made me better in some way, and I appreciate it. Happy Zuuling, Shrews

3 2

Take the Zuul User Survey
by Jimmy McArthur 24 Mar '20

24 Mar '20

Are you a Zuul user? Please take a few moments to fill out the Zuul User Survey to provide feedback and information around your deployment. All information is confidential to the OpenStack Foundation and Zuul community leaders, unless you designate it can be made public. We use this valuable information to help shape the future of the software and provide much needed feedback to our development community. Thanks! Jimmy

1 1

Fwd: [OpenStack Foundation] Update on OpenDev + PTG (Vancouver)
by Jimmy McArthur 18 Mar '20

18 Mar '20

Hi all - Please have a look at this from OSF re: upcoming events: > *From:* Mark Collier <mark(a)openstack.org> > *Date:* March 18, 2020 at 3:33 PM > *To:* foundation(a)lists.openstack.org > *Subject:* [OpenStack Foundation] Update on OpenDev + PTG (Vancouver) > Hi everyone, > > Based on the input from the community, board, and the latest information available from the health experts, we've made the decision not to hold the OpenDev + PTG in Vancouver this June. Instead, we're exploring ways to turn it into a virtual event and would love the help of everyone in the community. > > We will be reaching out to participants who have already registered to issue full refunds. > > We have always aimed to produce events "of the community, by the community," and this change for OpenDev + PTG is no exception. We would like to virtualize the PTG, since it is critical to producing the next release, targeting the same timeframe. We would like to recruit community volunteers to form a Virtual PTG Organization Team to collaborate with the OSF staff to incorporate best practices and ensure the event continues to meet the goals of the upstream community. We will need to begin pulling this plan together soon, so please add your name ot this etherpad if you are interested in helping: https://etherpad.openstack.org/p/Virtual_PTG_Planning. > > For OpenDev, discussions are also meant to be collaborative and free-flowing but are less time bound by the release schedule, so rather than trying to recreate that during a single virtual event at the same time as the virtual PTG, we are thinking about other ways to accomplish the same goals. We've already assembled an awesome team of Program Committee volunteers who have received proposals for moderated discussions, and we will be working with them on some ideas on the best way to move forward. > > For the time being, we are continuing with the plan for the Open Infrastructure Summit in Berlin October 19-23. For updates on OpenDev + PTG and the Summit, please continue to read and bookmark this status page which we will continue to update: https://www.openstack.org/events/covid-19-coronavirus-disease-updates > > Mark Collier > COO, OpenStack Foundation > > > _______________________________________________ > Foundation mailing list > Foundation(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

1 0

review.opendev.org Downtime March 20, 2020 at 1400UTC
by Clark Boylan 17 Mar '20

17 Mar '20

The OpenDev team is planning to take a short downtime March 20, 2020 from 14:00UTC to 15:00UTC. This outage will enable us to rename a few projects and redeploy Gerrit using containers. The container based deployment is an important first step in our longer term plan for upgrading Gerrit to a modern version. We recognize that this will be a disruption during an already disrupted week for many. We feel this is worthwhile as it fits into project release schedules and sets us up well for the future. Thank you for your patience. Feel free to ask us any questions you may have on this thread or in #opendev on Freenode. Clark

1 0

OpenDev now using #opendev on Freenode for Discussions
by Clark Boylan 17 Mar '20

17 Mar '20

Hello all, We are now using #opendev on Freenode to discuss the OpenDev Infrastructure. We hope this gives you all a more friendly neutral location to discuss the tools we use to develop our software. Feel free to join us and bring your ideas and questions. Hope to see you there, Clark

1 0