- Zuul-discuss - lists.opendev.org

Request for Wiki Assistance
by Jimmy McArthur 10 Mar '20

10 Mar '20

Hi Zuul Community! We had our recent Zuul post denied by the wikipedia community. It's not a huge surprise and it's notoriously difficult to get a "first post" up. If any of you have some Zuul expertise you could espouse in a wiki-like way, and/or some wikipedia juice/advice you could offer us, it would be greatly appreciated. https://en.wikipedia.org/wiki/Draft:Zuul_(software) You can read the bits at the top of the page about what we're doing wrong. A few things could help: * More primary sources - by this they mean high value domains or qualified news sources in the industry * A variation on authors * I'm not sure how to address their contention that the entry reads like an advertisement, but I'm open to suggestions :) Having a wiki page is a really big step towards making Zuul a more high profile open source CI and project gating alternative, so please let me know how you can help! Cheers, Jimmy

2 3

Run a job if a directory or a file exist in the source tree
by Fabien Boucher 10 Mar '20

10 Mar '20

Hi, What do you think about a job attribute a bit similar to "files", but for telling Zuul to execute the job only if one of the listed file or directory exist in the project source tree ? Use case is where I have a common set of jobs attached to a large number of repositories. But some of the repositories don't have a specific directory that contains the data used by a job. So instead of spawning a VM and run the job playbook to discover the directory is missing and skip the rest of the playbook's task, I'd like to tell Zuul to simply skip the job at all and not waste nodepool resources. Thus this new job's attribute. Another solution is to run small parent job, in a container, to discover if the directory exist and let run or not the child job. Any thoughts ? Is that new job attribute could be valuable ? Fabien

3 3

feature: display branch in zuul dashboard
by Sorin Sbarnea 06 Mar '20

06 Mar '20

Wes asked me few days ago if we could make the branch visible in zuul ui. To me it makes sense as long we do not display the master branch, mainly because I prefer an uncluttered interface. What do you think about it? Should I propose a patch or not? Cheers Sorin ---------- Forwarded message --------- From: Wesley Hayutin <whayutin(a)redhat.com> Date: Mon, 2 Mar 2020 at 15:45 Subject: future zuul ui enhancement. To: Sorin Sbarnea <ssbarnea(a)redhat.com> I would be cool to see the branch in the header for each review in check and gate. Currently we have... openstack/tripleo-quickstart-extras 710230,2 <https://review.opendev.org/710230> 1 hr 55 min 1 hr 10 min Would be nice to add branch info there too. Let me know if that makes sense. Thanks -- -- /sorin

2 1

zuul roles bindep and epel enablement issue
by Sorin Sbarnea 06 Mar '20

06 Mar '20

Background: As you probably know on centos there is the EPEL additional repository which provides some extra packages which are not part of the distribution, so not covered by support. Enabling EPEL is easy, usually just by installing epel-release, unless someone already installed it and disabled it (this is what rdo does in order to have the mirrors configured). Recently I discovered that some linters do need re2-devel, which comes from epel on centos-8. So far we used bindep succesfully but we cannot tell bindep role to install epel-release package before installing the the other rpms. Another approach would be to use test-setup.sh to enable this repo but last time I checked this runs after bindep, so too late. How can we address this issue? Do we have a more generic issue to install dependencies on nodes? I would not want to patch nodeset images because these makes the job not portable between different zuul instances. Another reason for not patching images is that what could be good idea to install for my use case, could prove bad for another one. Cheers, Sorin -- -- /sorin

2 1

Zuul v4/v5 planning
by corvus＠inaugust.com 04 Mar '20

04 Mar '20

Hi, Some folks in IRC recently brainstormed how to sequence the changes needed to implement the scale-out-scheduler spec. This is the plan we came up with, including a description of the changes at a high level, along with the major version numbers for important releases. Our current plan is to perform all of this development on the master branch, continue other unrelated development at the same time, and release interim releases as appropriate in the usual manner. We believe this sequence is constructed in a way that will enable everyone to continue to deploy the latest releases (or commits) of Zuul in the usual way with minimal disruption. At the end of the process, you'll be able to deploy more than one scheduler. :) There will be a couple of points in the timeline where we will ask you to make forward-compatible changes to your configuration or deployment. As long as you make those changes before the upcoming release which requires them, we don't expect any issues. Here is the current plan: * Add support for Zookeeper auth * Ask users to configure Zookeeper auth, ensure all Zuul components can reach the Zookeeper cluster, and define an SQL connection * Release last 3.x series * Require Zookeeper auth * Have all components connect to Zookeeper, even if they just idle for now * SQL reporters are required (an implied SQL reporter is added to every pipeline, explicit SQL reporters are ignored) * Release 4.0.0 * Warn on explicit SQL reporters in pipelines * Start adding in more Zookeeper stuff, removing equivalent gearman as appropriate * Release 4.1.0 * Error on explicit sql reporters in pipelines * Complete HA scheduler work * Release 5.0.0 -Jim

1 0

Ansiblefest - OSF Sponsor
by Jimmy McArthur 25 Feb '20

25 Feb '20

Hi all - It looks like Ansiblefest is going to be October 12-14, which is the week before the Berlin Summit. The Foundation is interested in sponsoring a booth at Ansiblefest again, but we'd like to make sure we have someone knowledgeable about Zuul to staff the booth. Is anyone interested/available that week? Cheers, Jimmy

3 3

Upcoming in-person events
by corvus＠inaugust.com 18 Feb '20

18 Feb '20

Hi, We haven't fully utilized the space at recent OSF events. But the next two are in Vancouver and Berlin, so I wonder if we might be able to get enough folks to show up and have some series design discussions. If so, maybe we could arrange for one or two whole days of collaboration to make it worthwhile. If you think you might be able to attend one or both of these events, please add your name to this etherpad: https://etherpad.openstack.org/p/zuul-events We can see which of the two has the most potential attendees and try to make plans accordingly. I don't think we need a commitment at this point, but rather an expression of interest and likelihood. Thanks, Jim

1 0

How do you manage and triage NODE_FAILURE
by Tristan Cacqueray 18 Feb '20

18 Feb '20

Hi Zuulers, currently when nodepool fails to launch a node, zuul reports NODE_FAILURE back to the user. This can be confusing for the end user, in particular when the user also provides nodepool resources. We are looking into sharing the ERROR logs of the nodepool launchers, similarly to the nodepool-builder dib log; but perhaps nodepool could return launcher exception message back to zuul so that is part of the build failure? Do you have other suggestions? Thanks in advance, -Tristan

2 1

Training session on Bitergia dashboard, Feb 17
by Thierry Carrez 13 Feb '20

13 Feb '20

Hi Zuulites, As mentioned in a previous thread, the Zuul community dashboard is available at zuul.biterg.io. It shows a series of pre-defined dashboards that let you extract metrics from gerrit, git and ML data. However the real power of the Bitergia toolkit is when you go to the next level and drill down and filter for more relevant data, or when you build your own analysis and visualization. In order to present those features and answer community questions, we've set up a video training session with Bitergia which will happen on Jitsi Meet[1] Monday, February 17 at 1600 UTC[2]. Please sign up on: https://etherpad.openstack.org/p/bitergia-training-Feb2020 All details for connection will be posted there. Also if you have examples of changes in existing dashboards that you'd like to see, or of visualizations you'd like to build, please add to the suggestions in the etherpad. We'll collect suggestions to build the final training contents. See you there! [1] https://meet.jit.si/ [2] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200217T16&p1=14… -- Thierry Carrez (ttx)

1 1

History of Zuul on opensource.com
by Jeremy Stanley 10 Feb '20

10 Feb '20

Over the Winter holidays I wrote up a narrative article recounting the origins and evolution of Zuul, which is now public here: https://opensource.com/article/20/2/zuul The article is distributed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) License, so feel free to reuse and redistribute it with those terms. -- Jeremy Stanley

2 1

Increasing project visibility
by Jeremy Stanley 05 Feb '20

05 Feb '20

With AnsibleFest just around the corner, I'm looking forward to seeing lots of you again. As many on this list are probably already aware, there will be a Zuul booth and I expect to spend a fair amount of time there talking to new folks about what Zuul is and why I think it's so amazing. I hear there will be some talks there which mention Zuul as well, so hopefully that helps spread the word to even more attendees. This got me thinking about how growing Zuul depends on growing our community around it, but to do that people need to know it exists in the first place. Speaking engagements and talking to folks at conferences are great ways, we have a slick looking Web site, some members of the community write articles or get interviewed about cool things they've done with Zuul, we're featured prominently in OSF marketing materials and newsletters... but what else can we do to get out the message, and how can we tell what's working to reach our future community and what isn't? Let's see what more we can come up with! Who's got suggestions? -- Jeremy Stanley

9 23

Zuul community activity metrics
by Thierry Carrez 04 Feb '20

04 Feb '20

Hi everyone, As some of you know, I have been working with Bitergia to provide a dashboard of community activity metrics for Zuul. This dashboard is now available at: https://zuul.biterg.io/ I customized the default dashboard so that it primarily shows Gerrit activity (merged changes that we generally count as "contributions"), rather than the default Bitergia dashboard. The rest of the dashboards are standard Bitergia dashboards, so you might find some panels more interesting than others. It currently tracks Git data, Gerrit activity, and mailing-list activity. We have the possibility to customize or add panels, so if you see some analysis or panel that would be specifically useful for Zuul, let me know ! Bitergia does its own affiliation tracking. We might develop a sync in the future to ingest OSF affiliation data automatically, but for the time being the affiliation mapping is separate, and requires manual fixing when the automated ingest ends up being incorrect. I did a pass at correcting the most obvious errors, but let me know if there is other entries to urgently fix. Also some identities may be duplicated (especially across data sources as people don't use the same email address in for example git and the ML), and some others may still be "unknown". Let me know if you have corrections. We plan to organize an open training session where Bitergia folks would cover the basic usage of the platform and answer community questions. I'll keep y'all posted. Cheers, -- Thierry Carrez (ttx)

2 2

Fosdem
by Mark Meyer 31 Jan '20

31 Jan '20

Moin, Any Zuul people say fosdem? Cheers Mark -- Mark Meyer mark(a)ofosos.org

2 2

2019 OSF Annual Report Now Available
by Jimmy McArthur 30 Jan '20

30 Jan '20

The OSF community had a productive year, merging 58k code changes to produce open source infrastructure software like Airship, Kata Containers, StarlingX, and Zuul, along with the third most active OSS project in the world, OpenStack. With 100,000 members and millions more visiting OSF websites in 2019 to get involved, the community made huge strides in addressing the 7.7B market for OpenStack and more than $12B combined OpenStack & Containers markets in the future. Each individual member, working group, SIG, and contributor was instrumental in continuing to support the OSF mission: helping people build and operate open infrastructure. The OSF 2019 Annual Report was published today highlighting the achievements across the community and the goals for the year ahead. Let’s break down some of the highlights of last year: -- The OSF confirmed three new open infrastructure projects to complement OpenStack in powering the world’s open infrastructure; -- OpenStack is one of the top three most active open source projects in number of changes, and is projected to be a $7.7 billion USD market by 2023; -- Some of the world’s largest brands—AT&T, Baidu, Blizzard Entertainment, BMW, China UnionPay, Walmart, and Volvo among others—shared their open source infrastructure use cases and learnings; -- Upstream contributors continued to prioritize cross-project integration with open source projects including Ceph, Kubernetes, Ansible, and Tungsten Fabric. -- New contributors were on-boarded through multiple internship and mentoring programs as well as OpenStack Upstream Institute, which was held in seven countries last year! The OSF would like to extend a huge thanks to the global community for all of the work that went into 2019 and is continuing in 2020 to help people build and operate open source infrastructure. Check out the full OSF 2019 Annual Report on the OpenStack website! Jimmy McArthur OSF

1 1

Help Shape the Track Content for OpenDev + PTG, June 8-11 in Vancouver
by Jimmy McArthur 30 Jan '20

30 Jan '20

Hi everyone, Hopefully by now you’ve heard about our upcoming event, OpenDev + PTG Vancouver, June 8-11,2020 <https://opendevptg2020.eventbrite.com>. We need your help shaping this event! Our vision is for the content to be programmed by you-- the community. OSF is looking to kick things off by selecting members for OpenDev Programming Committees for each Track. That Program Committee will then select Moderators who will lead interactive discussions on a particular topic within the track. Below you'll have the opportunity to nominate yourself for a position on the Programming Committee, as a Moderator, or both, as well as suggesting specific Topics within each Track. PTG programming will kick off in the coming weeks. If you’re interested in volunteering as an OpenDev Programming Committee member, discussion Moderator, or would like to suggest topics for moderated discussions within a particular Track, please read the details below, and then fill out this form <https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volun…>. We’re looking for subject matter experts on the following OpenDev Tracks: - Hardware Automation (accelerators, provisioning hardware, networking) - Large-scale Usage of Open Source Infrastructure Software (scale pain points, multi-location, CI/CD) - Containers in Production (isolation, virtualization, telecom containers) - Key Challenges for Open Source in 2020 (beyond licensing, public clouds, ethics) OpenDev Programming Committeemembers will: * Work with other Committee members, which will include OSF representatives, to curate OpenDev content based on subject expertise, community input, and relevance to open source infrastructure * Promote the individual Tracks within your networks * Review community input and suggestions for Track discussions * Solicit moderators from your network if you know someone who is a subject matter expert * Ensure diversity of speakers and companies represented in your Track * Focus topics around on real-world user stories and technical, in-the-trenches experiences Programming Committee members need to be available during the following dates/time commitments: * 8 - 10 hours from February- May for bi-weekly calls with your Track's Programming Committee (plus a couple of OSF representatives to facilitate the call) * OpenDev, June 8 - 10, 2020 (not required, but preferred) o Programming Committee members will receive a complimentary pass to the event Programming Committees will be comprised of a few people per Track who will work to select a handful of topics and moderators for each Track. The exact topic counts will be determined before Committees begin deciding. OpenDev Discussion Moderatorswill * Be appointed by the Programming Committees * Facilitate discussions within a particular Track * Have adequate knowledge and experience to lead and moderate discussion around certain topics during the event * Work with Programming Committee to decide focal point of discussion Moderators need to be available to attend OpenDev, June 8 - 10, 2020, and will receive a complimentary pass. Programming Committee nominations are open until February 11.Deadlines to volunteer to be a moderator and suggest topics will be in late February. Nominate yourself or suggest discussion topics here: <https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volun…>https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volun… Cheers, The OpenStack Foundation

1 1

Retiring as zuul-maint
by Clint Byrum 27 Jan '20

27 Jan '20

Hi everyone. I'd like to publicly state that I'm unable to continue as a Zuul maintainer. I've lost touch with the current status-quo, and I don't have any day-job time to work on Zuul. My hobby time spent on Zuul is no longer a joy, as I find working on zuul-jobs to be overbearing and unproductive, and the internals of Zuul have changed enough that I don't feel confident approaching core issues anymore. Thanks everyone for all the great stuff you've been doing. I still use Zuul every day, and believe strongly in the ethos of the project, but I just have to be realistic and lay down my +2.

3 2

Fetch roles improvement to enable running zuul-jobs on kubectl connection
by Tristan Cacqueray 24 Jan '20

24 Jan '20

Hello folks, I have been working on supporting kubectl connection for zuul-jobs. The issue is that Ansible synchronize module doesn't work[0]. One solution would be to include the fix in Zuul library[1], but that's not ideal because zuul's synchronize would be slightly different. Alternatively we can synchronize files using oc rsync[2] command but that can't be done from untrusted context. Thus we need to adapt every fetch roles to not perform the synchronize task, and instead rely on the generic fetch-output role. As a first step I added a zuul_use_fetch_output toggle to enable the new behavior, but we should consider enforcing the fetch-output job and make it the default behavior. Indeed It is much easier to copy or link file to ~/zuul-output and let the base job retrieve and publish instead of having each fetch roles bother with running synchronize to zuul.executor.work_root or log_root. A zuul_use_fetch_output toggle implementation is proposed[3] along with a third-party-ci build that demonstrates a full tox-py36[4] job running in a container. Regards, -Tristan [0]: https://github.com/ansible/ansible/pull/62107 [1]: https://review.opendev.org/681553 [2]: https://review.opendev.org/#/c/631402/6/roles/prepare-workspace-openshift/t… [3]: https://review.opendev.org/#/q/topic:zuul-jobs-with-kubectl [4]: https://review.opendev.org/682049

3 2

Next steps for zuul-operator
by corvus＠inaugust.com 24 Jan '20

24 Jan '20

Hi, The zuul-operator project seems to have stalled. I think that's partly due to time constraints, but also we have had a number of proposals for alternative implementations and no clear direction. Originally we said we would use the Ansible operator framework (and were vague about how to handle the more programmatic parts; one assumes Python of some sort). It has also been proposed that we use the golang framework. A third proposal is Ansible with most of the transformation handled by dhall. We might have enough people with enough time interested in finishing this up if we are able to agree on a path forward, so I'd like to have a meeting to discuss this. I think a voice conference might be appropriate for this, due to the nuances of the discussion. I've checked a number of folks active in the discussion so far, and it looks like Wednesday, January 15 at 15:30 UTC is a good time. Let's use the conferencing system[1] room 6001. Anyone may feel free to join, and please let me know if you think we should reschedule. [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing -Jim

3 9

zuul schema validation and zuul-lint
by Sorin Sbarnea 13 Jan '20

13 Jan '20

Over the last weekend I managed to finally produce a validation schema for zuul config files and also publish https://pypi.org/project/zuul-lint/ The goal is better described at https://storyboard.openstack.org/#!/story/2003989 but I will summarize below the goal: * ability to lint zuul config file syntax * ability to get vscode live validation of zuul config files * be able to lint zuul config syntax using pre-commit tool (not hook) All these are working now and I was able to run zuul-lint on all* zuul files from opendev and rdo. My initial desire was to make this part of zuul itself but I realized that installing zuul package comes with two big problems: - huge dependency chain (most not needed to perform a linting) - broken on macos due to some deps While the second bullet probably can be fixed I am not so sure about the first one, mainly because we cannot use a `zuul[lint]` extras for linter requirements as it would be additive to default ones. This could be sorted only if we decide to add extras for server and client and keep almost no default dependencies on zuul package itself. Another alternative would be to make zuul repository produce more than one python package, so the linter can be kept isolated. Still I am not sure how easy it would be to achieve that. It would be great to have some feedback from some very-early adopters. Please note that this is only schema validation, is not validating if the configuration is compatible with a specific zuul instance, as this is a totally different aspect, one that is unlikely to be possible to be done without a CR/PR (missing jobs) * "all" that I already had cloned locally, did not had time to do a full batch. /sorin

1 0

Changing default of stage_compress_logs in stage-output role
by Clark Boylan 07 Jan '20

07 Jan '20

The zuul-jobs stage-output role is useful in preparing logs for permanent storage. Previously the default behavior of this role was to compress logs that it collects to reduce storage space requirements (via a default true value for stage_compress_logs). Unfortunately, we've found that depending on the permanent storage system this may be undesireable. Specifically when storing logs in object storage services we can upload and store a compressed version of the file while still logically referring to it via its uncompressed name. Then the object storage service will convert it to the uncompressed version when retrieved. This is problematic if you want a compressed file to be worked with in its compressed form, like a .tar.gz tarball. In order to disambiguate between files that are intentionally compressed (like tarballs) and those that are compressed for storage efficiency reasons we are changing the default of stage_compress_logs to false and letting the upload roles determine how to compress things. In the case of upload-logs-swift already compressed files will be left alone and not treated special by the storage service. Any uncompressed files will be compressed on upload with hints to get the original back when retrieved. This should create a good balance of storage efficiency while still being able to work with intentionally compressed files without unexpected decompression from storage services. If you would like to keep the old stage-output behavior you can set stage_compress_logs to true in your site variables or base jobs. More details can be found in the change that updates stage-output, https://review.opendev.org/#/c/701282/. Clark

1 0

Project lead election
by corvus＠inaugust.com 07 Jan '20

07 Jan '20

Hi, The position of Zuul Project Lead is an elected position described in our governance document[1]. I currently hold the position, and would be happy to continue in that position for another year. If elected, I plan to continue my current hands-off approach. I believe that all of the Zuul Maintainers are empowered to collectively decide on and execute our vision for the project. My purpose is to help articulate that vision when necessary, drive the process of attaining consensus, and be a point of contact and representative for the project in circumstances where a single person is needed (but in those cases, I promise to share as much of that work as possible with the rest of the team). I have uploaded a change[2] to update the expiration date of my term. If any other Zuul Maintainers would like to nominate themselves for the position, please upload a similar change and send a reply to this message to this list. The nomination period will close on January 14, 2020. If there are other candidates, we will hold a Condorcet election at that time. -Jim [1] https://zuul-ci.org/docs/zuul/governance.html#zuul-project-lead [2] https://review.opendev.org/701267

1 0

Zuul single-user use case for GitHub
by Mohammed Naser 06 Jan '20

06 Jan '20

Hi everyone, With my recent efforts at trying to see how we can make Zuul more accessible, starting with contributing back all the Helm charts to deploy Zuul inside Kubernetes (those are still pending review), I'm hitting a common wall right now which doesn't allow gating a project that's managed by a single user. The *root* of the this issue is that as a user in GitHub, you are not able to "approve" your pull request, even if you're an administrator. This presents an issue for projects where the scenario is a single individual which is pushing pull requests towards their own repository. With the inability of 'approving' your own pull request, this leaves a few other options, however, they are all a bit painful right now and introduce a bit of a risk. 1. Enqueue changes into 'gate' once a user comments something like "lgtm". This works, however, the issue is that our current implementation of the trigger does not take into consideration if this user has admin/write/read roles and therefore can allow anyone to do this. 2. Using GitHub labels which AFAIK can be added/removed by anyone and it is probably not a very good user experience (commenting "lgtm" or something is very popular in projects like Kubernetes or Ansible). 3. Some other combination of hacks?? I'm thinking the best ideal workaround is for Zuul to be able to understand comments and the role that the user has when they place a comment, perhaps it would be interesting to pick up some of the code review process that is used inside Kubernetes (prow) and put that logic in: https://github.com/kubernetes/community/blob/master/contributors/guide/owne… How does everyone feel about the above? Do we feel like this start to be outside the scope of Zuul and instead it should be some external process which listens/watches for events and enqueues things manually in Zuul if a user wants this workflow? I'm just trying to gauge out interest on what everyone feels about this to see what ideal route works not just for us but for many other future Zuul users. Thanks, Mohammed

4 4

Helm charts jobs
by Mohammed Naser 20 Dec '19

20 Dec '19

Hi all, I've been working on some jobs that test Helm charts and running into a few interesting issues that I'd like to bring up for discussion. I am hoping to bring those jobs into zuul/zuul-jobs once I have gotten over these few humps. Helm charts can have dependencies (and those dependencies live in a repository). The repository which *contains* a bunch of *.tgz files are pulled down when the Helm chart is linted/tested/packaged. The requirements are defined something like this: ``` - name: prometheus-operator version: 6.21.0 repository: https://kubernetes-charts.storage.googleapis.com/ ``` My idea was to actually use the same pattern as buildset registry, but instead of starting up a registry, we would build all of the charts that are part of this build, push them into this mini-repository and let the jobs use them, but that led me to a bit of a tricky situation. - Do we modify the `repository` section dynamically during the job (based on whatever charts we actually built earlier?) to point towards this 'buildset' repository? - Do we build/mirror all of the charts or only the ones in `required-projects` / in the same repo? So far I have a successful `chart-testing` job which runs the linting, but I'm troubled by the fact that if I have multiple charts in the same repository (which depend on each other), they are pulled in from the listed repository. This means that we're not really doing any testing of the dependencies (and we can merge a dependency that works by itself, but breaks a consumer). Not very Zuul. :) Thanks, Mohammed

1 0

Make files matcher match changes with no files
by Radosław Piliszek 09 Dec '19

09 Dec '19

Hello Folks, I want to ask about https://review.opendev.org/678273 "Make files matcher match changes with no files" It has been 3 months since I proposed it and there has been no feedback (well, except for +1 from Jan, thanks) despite the change being quite small and straightforward. Please let me know if there is something you want to discuss regarding this fix. I tried reaching you out on the IRC channel a couple of times but it seems I have been unsuccessful in this endeavor. I would gladly see this fixed for OpenStack's Zuul to be able to use the simplified config where I specify files in base jobs instead of each child job reference in the check queue to not disable periodic jobs. Kind regards, -yoctozepto

3 4

Thread on OpenDev Independence and Governance
by Clark Boylan 04 Dec '19

04 Dec '19

Hello, I wanted everyone to be aware of this thread [0] at openstack-infra(a)lists.openstack.org that I've started to formalize OpenDev's future independence and governance. Currently the infra team is formally an OpenStack project, but we think that we'll be better able to serve our non OpenStack users if the OpenDev aspects of this team become independent with its own governance. We are more than happy to hear feedback so please read this thread and respond if the topic interests you. Note, I'm using this pointer thread in an effort to avoid cross posting and losing feedback. It would be great if people can respond to the original on openstack-infra@lists. [0] http://lists.openstack.org/pipermail/openstack-infra/2019-December/006537.h… Thank you, Clark

1 0

Project dependencies question
by Petar Terziev 03 Dec '19

03 Dec '19

Hi all, I'm new to Zuul - recently started looking at it, as I've been given a task to set my team's project up to use it for CI. The company's Zuul guru has left, and the thing I'm trying to do isn't quite covered by the docs available so I thought I'd reach out to you to first verify if what I want to do is achievable, and then to see how it can be done. We have two repositories, library A and application B, which uses library A. Commits to B have some basic gating requirements for now - allow merging if it builds and some tests pass, etc. A however is not as straight forward. Since changes to its interface can break B's build, I'd like to hold off breaking interface changes to A until B also has a job in the pipeline that includes a patch-set to update how that interface is used: A` <- Commit that changes an interface B uses enters the gating pipeline B` <- Commit that updates B's usage of A and align it with changes from A` enters the pipeline Ideally, A` would go through its check pipeline and review, and then fail gating because it breaks B. Then B` would be queued up and somehow retrigger the failed A` pipeline, but now running it with B`, causing it to succeed. I'm uncertain whether this can be classified as circular dependency, and if not - how to achieve it. I have noted the "Depends-On" stanzas you can add to commit messages which I could use to express the "B` depends on A`" relationship. But would this be enough to give me the desired behaviour above? Or maybe reference A in the "job.required-projects" configuration section of B? The docs say "Speculative merging and cross-repo dependencies will be honored", but I am still unsure whether this means that in the scenario above, B`'s pipeline will speculatively merge A`, and upon its success cause A` to be merged to mainline. The scenario above is not that uncommon, though I realise the whole "hold off the library interface change until the implementer is up-to-date" may not be standard practice. It's a library used in a fairly closed circle, but not closed enough to allow us have A and B live in the same repository. Any pointers to additional methods or more useful documentation would be much appreciated. Thanks!

4 6

Re: Creating OpenDev control-plane docker images and naming
by Ian Wienand 02 Dec '19

02 Dec '19

On Tue, Nov 26, 2019 at 05:31:07PM +1100, Ian Wienand wrote: > What I would propose is that projects do *not* have a single, > top-level Dockerfile, but only (potentially many) specifically > name-spaced versions. > [2] I started looking at installing these together from a Dockerfile > in system-config. The problem is that you have a "build context", > basically the directory the Dockerfile is in and everything under > it. I started looking closely at this, and I think have reversed my position from above. That is, I think we should keep the OpenDev related dockerfiles in system-config. [1] is a change in system-config to add jobs to build openstacksdk, diskimage-builder and nodepool-[builder|launcher] containers. It does this by having these projects as required-projects: in the job configuration and copying the Dockerfile into the Zuul-checked-out source (and using that as the build context). A bit ugly, but it works. However, to use these jobs for nodepool CI requires importing them into zuul/nodepool. This is tested with [2]. However, Zuul just reports: This change depends on a change with an invalid configuration. It only depends-on [1], which has a valid configuration, at least in the opendev tenant. I think that this has to do with the zuul tenant not having the projects that are used by required-jobs: from the new system-config jobs [3], but am not certain it doesn't have something else to do with the config errors at [4]. I have filed [5] because at the minimum a more helpful error would be good. -i [1] https://review.opendev.org/696000 [2] https://review.opendev.org/696486 [3] https://review.opendev.org/696859 [4] https://zuul.opendev.org/t/zuul/config-errors [5] https://storyboard.openstack.org/#!/story/2006968

1 0

Something between "config" and "untrusted"?
by Clint Byrum 12 Nov '19

12 Nov '19

For the second time in about 6 months, I've run into a weird problem in our Zuul. We use Zuul for CD, so we often write jobs in one repo that are scoped to a limited set of other repos, and which employ secrets to unlock various deployment-related things either in gate to upload artifacts or in promote to push a merged PR into production. What happens is that we try to make a new repo with some subset of our usual CD on an existing repo, and the new repo can't make use of the old repo's jobs. This is documented and intended, because there's a problem where the new repo could use Depends-On to expose the old repo's secrets. allowed-projects doesn't break this restriction (though I struggle to understand why). The usual answer is to move the top-level playbook and job definitions into a trusted repo. This complicates things for a number of reasons: One, we often have a check version of the same job which runs without secrets that tests that the playbook itself is ok. That ceases to be an option because now the job runs in a trusted context. While the roles are still shared, and we can maintain a separate playbook in the untrusted repo to keep some of this, we want to test *the actual playbook*, not the roles. Two, these two repos are not separated for trust reasons. They're separated for separation of concerns and because they have different release cadences. As such, we don't mind if that new repo exposes the secrets of the old repo, because they're both in the same security zone from our perspective. So, I wonder if we could have another class of repository restriction, which is to make one the partner of the other, and drop this restriction only between these two repos. If this sounds like a good idea, I'll try to carve out a few of my tens of spare minutes per month to implement. :) Thanks!

2 2

Bazel roles for Zuul
by Paul Albertella 08 Nov '19

08 Nov '19

Hi, As Matthieu mentioned, I gave a talk at OSS/ELCE about integrating Zuul and Bazel, and wanted to share some of the work I did with the wider Zuul community. Hence I've just submitted a couple of roles for Bazel to the zuul/zuul-jobs repository: https://review.opendev.org/#/c/693513/ I've tested these on a local Zuul setup, using the containers from the Quick Start tutorial, but wasn't sure if there is anything else I need to do to test them, or to make them easier to use in jobs/playbooks. Any suggestions would be very welcome! Cheers, Paul

1 0

Zuul at FOSDEM
by Thierry Carrez 28 Oct '19

28 Oct '19

Hi everyone, There is a CI/CD devroom at FOSDEM (Feb 1-2, 2020 in Brussels): https://lists.fosdem.org/pipermail/fosdem/2019q4/002880.html Zuul would be a great match for the crowd there. Trying to avoid duplicates... Is anyone planning to attend and present? -- Thierry Carrez

3 3

Zuul statistics on the Train dev cycle
by Matthieu Huin 26 Oct '19

26 Oct '19

Hello, I'd be curious to get some stats on the Train dev cycle from Zuul's standpoint. For example: * Amount of jobs run by Zuul * Amount of nodes managed by Nodepool * Amount of failed gate builds, maybe also as a ratio of failed/total gate builds: this would give an idea (assuming the false negatives are rare) of how critical speculative merging is for OpenStack * Amount of patches with cross-repo dependencies I assume most of these can be computed from the SQL reporter data (granted you have access to that). Has anybody tried to get these stats? If not, would anybody want to help me play around with the data and see what we can come up with? Cheers, -- Matthieu Huin Senior Software Developper Red Hat <https://www.redhat.com> <https://red.ht/sig>

4 8

Feedback on Airship pilot project
by Jeremy Stanley 17 Oct '19

17 Oct '19

Hi fellow Zuulies, The Airship project will start its confirmation process with the OSF Board of Directors at the Board meeting[1] Tuesday next week. A draft of the slide deck[2] they plan to present is available for reference. Per the confirmation guidelines[3], the OSF Board of directors will take into account the feedback from representative bodies of existing confirmed Open Infrastructure Projects (Zuul, OpenStack and Kata) when evaluating Airship for confirmation. You may recall this process from when we did it for Zuul not *that* long ago. ;) 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 Airship project which could serve as useful examples for how these projects do or do not meet this and other guidelines, please provide them on the etherpad[4] 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. [1] http://lists.openstack.org/pipermail/foundation/2019-October/002800.html [2] https://www.airshipit.org/collateral/AirshipConfirmation-Review-for-the-OSF… [3] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [4] https://etherpad.openstack.org/p/zuul-community-airship-confirmation-feedba… -- Jeremy Stanley

1 0

Common Questions from Ansiblefest
by Jimmy McArthur 16 Oct '19

16 Oct '19

We recently attended Ansiblefest in Atlanta and Zuul had a booth there. It was a great opportunity to meet with existing and potential Zuulies. Some common questions popped up over and over again, so I wanted to crowd source some answers that we could place on our FAQ: * How does Zuul compare to: ** Jenkins ** Molecule ** Tower * Is Zuul a replacement for Jenkins? * Does it work with GitLab? I believe those were the majors. Let me know if you're able to contribute some responses Cheers, Jimmy

4 5

OSF booth at KubeCon+CloudNativeCon in San Diego
by denise＠openstack.org 15 Oct '19

15 Oct '19

Hello Everyone, We wanted to let you know that the OpenStack Foundation will have a booth at the upcoming KubeCon+CloudNativeCon event in San Diego, CA on November 18-21, 2019. We are in booth #S23 and we will be featuring the OpenStack Foundation in addition to all the projects - Airship, Kata Containers, StarlingX, OpenStack and Zuul. At the booth we will have stickers and educational collateral about each project to distribute. We would like to invite you to help us in the following areas: Represent your project by staffing the OSF booth If you can spare 1 hour/day (or any time at all!) to represent your specific project in the OSF booth Here is the [ link ]( https://docs.google.com/spreadsheets/d/1mZzK0GHm9OQ0IL9njTWLxPLuAeR6jqmyeM6… ) to the google doc to sign up Project Demos in the OSF booth If you are interested in delivering a project-specific demo in the OSF booth, please contact [ Denise ]( http://denise@openstack.org ) Looking forward to seeing all of you in San Diego! Best regards, OSF Marketing team Denise, Claire, Allison and Ashlee

1 0

Ansible version changes to Zuul
by Paul Belanger 11 Oct '19

11 Oct '19

Greetings! This came up again today in #openstack-infra, which reminded me to send this email. I'd like to propose we make the following changes to Zuul to increase the versions of Ansible we are supporting. For example: Remove support for ansible 2.5: https://review.opendev.org/650431/ We have marked Ansible 2.5 deprecated for some time, and the Ansible project move 2.5 branch to EOL 6 months ago. I believe it is time for Zuul to also drop it. Switch ansible_default to 2.8: https://review.opendev.org/676695/ Both zuul.ansible.com and Zuul tenant on zuul.opendev.org have been running Ansible 2.8 for a while now. I don't believe we've seen any issues related to Ansible 2.8 (but I could be mistaken). I believe it is somewhat safe to default the version of Ansible to 2.8 now. This also marks Ansible 2.6 as deprecated, as it will move into EOL upstream in the next month when Ansible 2.9 is released. WIP: Support Ansible 2.9: https://review.opendev.org/674854/ Finally, with Ansible 2.9 to be released at the end of the month, I think it would be fantastic if we could also do a same day release of Zuul. This only adds Ansible 2.9 support, but doesn't change the default version used by jobs. Reviews on this would be helpful! For all above, I think we should try to over-communicate the changes, maybe email to announce list, then in 1 or 2 weeks work to merge them. Thoughts? Paul

1 0

Fwd: Important Shanghai PTG Information
by Kendall Nelson 09 Oct '19

09 Oct '19

Wanted to make sure you all saw this too :) While I realize Zuul hasn't planned to meet, if any of you will be in Shanghai, this info is important. -Kendall (diablo_rojo) ---------- Forwarded message --------- From: Kendall Waters <kendall(a)openstack.org> Date: Wed, Oct 9, 2019 at 10:09 AM Subject: Important Shanghai PTG Information To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Hello Everyone! As I’m sure you already know, the Shanghai PTG is going to be a very different event from PTGs in the past so we wanted to spell out the differences so you can be better prepared. Registration & Badges Registration for the PTG is included in the cost of the Summit. It is a single registration for both events. Since there is a single registration for the event, there is also one badge for both events. You will pick it up when you check in for the Summit and keep it until the end of the PTG. The Space Rooms The space we are contracted to have for the PTG will be laid out differently. We only have a couple dedicated rooms which are allocated to those groups with the largest numbers of people. The rest of the teams will be in a single larger room together. To help people gather teams in an organized fashion, we will be naming the arrangements of tables after OpenStack releases (Austin, Bexar, Cactus, etc). Food & Beverage Rules Unfortunately, the venue does not allow ANY food or drink in any of the rooms. This includes coffee and tea. Lunch will be from 12:30 to 1:30 in the beautiful pre-function space outside of the Blue Hall. Moving Furniture You are allowed to! Yay! If the table arrangements your project/team/group lead requested don’t work for you, feel free to move the furniture around. That being said, try to keep the tables marked with their names so that others can find them during their time slots. There will also be extra chairs stacked in the corner if your team needs them. Hours This venue is particularly strict about the hours we are allowed to be there. The PTG is scheduled to run from 9:00 in the morning to 4:30 in the evening. Its reasonably likely that if you try to come early or stay late, security will talk to you. So please be kind and respectfully leave if they ask you to. Resources Power While we have been working with the venue to accomodate our power needs, we won’t have as many power strips as we have had in the past. For this reason, we want to remind everyone to charge all their devices every night and share the power strips we do have during the day. Sharing is caring! Flipcharts While we won’t have projection available, we will have some flipcharts around. Each dedicated room will have one flipchart and the big main room will have a few to share. Please feel free to grab one when you need it, but put it back when you are finished so that others can use it if they need. Again, sharing is caring! :) Onboarding A lot of the usual PTG attendees won’t be able to attend this event, but we will also have a lot of new faces. With this in mind, we have decided to add project onboarding to the PTG so that the new contributors can get up to speed with the projects meeting that week. The teams gathering that will be doing onboarding will have that denoted on the print and digital schedule on site. They have also been encouraged to promote when they will be doing their onboarding via the PTGBot and on the mailing lists. If you have any questions, please let us know! Cheers, The Kendalls (wendallkaters & diablo_rojo)

1 0

[all] Final PTG Schedule
by Kendall Nelson 08 Oct '19

08 Oct '19

Hello Everyone! After a few weeks of shuffling and changes, we have a final schedule! It can be seen here on the 'Schedule' tab[1]. -Kendall (diablo_rojo) [1] https://www.openstack.org/PTG

1 0

Leadership meet-n-greet opportunities for the community in Shanghai
by Jeremy Stanley 07 Oct '19

07 Oct '19

A couple of events have been included in the Shanghai Open Infrastructure Summit schedule, to help attendees see that leadership roles in the projects gathering there are attainable and the folks who fill them are approachable and eager to engage in person: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24417/ https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24426/ It would be great if any Zuul Maintainers are available to be present for either or both of these sessions. If you'll be at the summit and are interested in helping represent the Zuul leadership at one of them, there's a sign-up here: https://etherpad.openstack.org/p/meet-the-project-leaders It's also an opportunity to plug any sessions or related activities we have coming up during the rest of the week and attempt to drum up additional attendance, as well as generally encourage more participation in the project. -- Jeremy Stanley

1 0

Re: Proposed Forum Schedule
by Jimmy McArthur 04 Oct '19

04 Oct '19

The forum schedule is now live: https://www.openstack.org/summit/shanghai-2019/summit-schedule/global-searc… If you'd prefer to use the spreadsheet view: https://drive.google.com/file/d/1qp0I9xnyOK3mhBitQnk2a7VuS9XClvyF Please let Kendall Nelson or myself know as soon as possible if you see any conflicts. Cheers, Jimmy > Jimmy McArthur <mailto:jimmy@openstack.org> > October 3, 2019 at 11:42 AM > Hello! > > I'm attaching a PDF of the proposed Shanghai Forum Schedule. I'll > publish the same on the actual website later this afternoon. However, > there is still time for feedback/time changes, assuming there aren't > conflicts for speakers/moderators. > > This is also available for download here: > https://drive.google.com/file/d/1qp0I9xnyOK3mhBitQnk2a7VuS9XClvyF/view?usp=… > > > Please respond to this thread with any concerns. > > Cheers, > Jimmy >

1 0

Developing a Gitlab driver
by Paul Albertella 30 Sep '19

30 Sep '19

Hi, I saw the @ZuulCI tweet about developing a Gitlab driver for Zuul (and responded as @reiterative) and would love to know more, as this is something that I had already been contemplating. I'm not a Zuul user yet, but it has been recommended by some colleagues and I'm keen to explore its possibilities on the projects that I'm involved in, which use Gitlab. Has any work already been done on a Gitlab driver, which could provide a starting point? Or is the existing GitHub driver the best starting point? Cheers, Paul

4 3

Elevator Pitch for Zuul
by Greg Dekoenigsberg 27 Sep '19

27 Sep '19

"Speculative gating saved our project." --Johannes Foufas, Volvo The most important question around Zuul is: why? Why, among all of the other CI/CD projects of various descriptions, should anyone choose Zuul? You generally get a very short time to explain to users why they should bother with a new technology, and the answer "Project X Uses It," while important, is seldom sufficient. I'd like to propose a 50-word elevator pitch for Zuul that focuses on its key differentiator: multi-project gating. It goes like this: "Complexity doesn't go away; it just moves. In the age of monolithic applications, complexity lived in the single application. Now, in the age of microservices, complexity lives in the relationships between applications. Zuul is the essential CI/CD project for the age of microservices, because it provides predictive gating between multiple projects." I believe that good marketing consists of two pieces: simplifying a story to the resonant essence, and then amplifying that story as much as possible. If we can agree that this simple story resonates, maybe we can figure out how to get this story in front of as many people as possible. --g

8 8

Gerrit support in master unstable
by corvus＠inaugust.com 19 Sep '19

19 Sep '19

Hi, We recently merged a bunch of changes which altered the Gerrit driver in master, and unfortunately real-world testing has exposed some errors which were not caught in either manual or automated testing. If you use Gerrit, particularly if you have it configured with an HTTP password, you may wish to avoid running master and stick with 3.10.2 for the moment until we fix those problems. I do not think they are very complicated and believe that we can merge fixes to them in not much more time than it would take to revert the changes, but if I'm wrong about that, we'll revert the stack and make another attempt. -Jim

1 0

Proposed new project: zuul-registry
by corvus＠gnu.org 18 Sep '19

18 Sep '19

Hi, We broke new ground with speculative container images, but in using this feature over the past few months, we have found some rough edges that I think can be smoothed by implementing our own container image registry server. Hear me out. :) There are two container image registries involved in the system: the intermediate registry and the buildset registry. The intermediate registry is a long-lived service which holds images after builds complete in order to transfer them between buildsets. In other words, when we build an image, we put it in the intermediate registry, and if, later, a change arrives which depends on that image, we pull it from that registry, and place it in the buildset registry. The buildset registry is short-lived, and is meant to supply images that we have local builds of if they appear in the dependency chain, or supply them from upstream dockerhub otherwise. Ideally the requirements for the intermediate registry are: * Authenticated write access * Anonymous read access * Support for more than one registry namespace (e.g., docker hub, quay, etc) Only "authenticated write access" is met by the current docker registry server -- and that's by putting the entire thing behind authentication -- read and write. In addition, we have found that the docker registry service seems to have problems working with a swift backend -- occasionally it writes zero-byte image objects, and the existing registry server logging isn't giving us any clues why. Ideally the requirements for the buildset registry are: * Authenticated access * Pass-through support for images not present * Support for more than one registry namespace Only "authenticated access" is met by the current docker registry; we accomplish the second by running a second instance and configuring them both as mirrors. I believe that if we make our own registry software, we can satisfy all of the requirements. The two registry servers have differing needs, but a single piece of software should be able to satisfy both by enabling or disabling certain options. It will be easy for us to configure whether read access requires authentication. We should be able to emulate different registry servers by observing the "Host" header (or, failing that, run on different ports). We can implement our own logic to perform pass-through requests automatically if an image is not present locally. And finally, we should be able to make uploading to swift more robust (though, obviously that alone is not a compelling reason to do this). I have made an initial implementation in Python which performs the basic functions of a registry (push and pull work). At this point, I have enough of an understanding of the protocol to feel that the remaining goals are achievable with a reasonable amount of effort. If folks don't object, I'd like to create a new repository ("zuul-registry" perhaps?) to hold this and continue further development. I would consider this an optional part of Zuul which operators could choose to deploy if they have a speculative image pipeline. -Jim

4 4

Open Infrastructure Summit Shanghai: Forum Submissions Open
by Jimmy McArthur 16 Sep '19

16 Sep '19

Hello Everyone! We are now accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Shanghai [2]. Please submit your ideas through the Summit CFP tool [3] through September20th. Don't forget to put your brainstorming etherpad up on the Shanghai Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. Keep in mind, Forum submissions are for discussions, not presentations. The timeline for submissions is as follows: Sep 4th | Formal topic submission tool opens: https://cfp.openstack.org. Sep 20th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda. Sep 30th | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins. Oct 7th | Scheduling committee final meeting Oct 14th | Forum schedule final Nov 4-6| Forum Time! If you have questions or concerns, please reach out to speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. Cheers, Jimmy [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/shanghai-2019/ [3] https://cfp.openstack.org [4] https://wiki.openstack.org/wiki/Forum/Shanghai2019

1 1

Can we start adding ansible-molecule files for testing zuul roles?
by Sorin Sbarnea 06 Sep '19

06 Sep '19

As this question raised on irc I think is time to get some feedback on it. Molecule is the official Ansible role testing framework which allows testing of Ansible roles (or playbooks) in isolation by taking care care of provisioning and cleanup of the required resources. Most common use-case is to use docker containers to test, where you can start running your role code in a couple of seconds, being able to run in parallel lots of platforms. Mainly as a role developer (or even occasional contributor), it makes extremely easy to run tests locally*, before even creating a change-request. So this opens few sub-questions: a) can we allow people to add molecule files, even if we do not run molecule in check/gates? -- there is value in this, even without jobs. b) can/should we add molecule jobs for these so we can assure they keep running? c) would this create duplication between what is tested as standalone zuul jobs and what what is tested via molecule ones? Is this a reason to worry or not? These roles are used on multiple zuul server so is in our interest to make them as reusable as possible. Maybe on opendev.org instance we do not have the resources to test them on all possible platforms, but this does not mean that other zuul instances cannot run these tests. In addition to making a role developer life easier by allowing it to run ansible code in a say similar to running unittests, we can even see other benefits: uploaded CRs would be of better quality and we will also lower zuul load, improving the build-response-time even for users that do not test their changes locally before uploading them. * Developer can still define DOCKER_HOST=ssh://host and fully avoid the need to install docker locally. So the term "locally" is a bit relaxed, as you can offload the work to external systems. Is more of running tests on my own hardware, but isolated, so I would not mess my localhost. Thanks Sorin Sbarnea

1 0

Root Ara report removed from Zuul Jobs
by Clark Boylan 06 Sep '19

06 Sep '19

Hello Everyone, We have removed the top level Zuul job Ara reports from our Zuul jobs. This was done to reduce the total number of objects we are uploading to our swift/ceph object stores as some clouds have indicated the total object volume is a bit high. Analysis showed that Ara represented a significant chunk of that data. We did not remove that information though. Zuul's build dashboard is able to render a similar report for builds. You can find that by clicking on the "Console" tab of a build. For exampe, here is one for a nova tox job: http://zuul.openstack.org/build/8e581b24d38b4e5c8ff046be081c4525/console We hope this makes our log storage easier to support while still providing the information you need to debug your jobs. Note jobs that run a nested ara-report are not affected by this. I think TripleO, OSA, and others do this. Thank you, Clark

1 0

Report from Gerrit User Summit
by corvus＠inaugust.com 04 Sep '19

04 Sep '19

Hi, Monty and I attended the Gerrit User Summit and hackathon last week. Zuul came up quite a lot, so I wanted to highlight some things here. For a fuller report of the event, see my mail to the OpenStack-Infra mailing list here: http://lists.openstack.org/pipermail/openstack-infra/2019-September/006475.… The following is an extract of the Zuul-relevant parts from that: Zuul ---- Zuul is happily used at Volvo by the propulsion team at Volvo (currently v2, working on moving to v3) [2]. Other teams are looking into it. The Gerrit maintainers are interested in using Zuul to run Gerrit's upstream CI system. Monty and I plan on helping to implement that. We spoke at length with Edwin and Alice who are largely driving the development of the new "checks" API in Gerrit. It is partially implemented now and operational in upstream Gerrit. As written, we would have some difficulty using it effectively with Zuul. However, with Zuul as a use case, some further changes can be made so that I think it will integrate quite well, and with more work could be a quite nice integration. At a very high level, a "checker" in Gerrit represents a single pass/fail result from a CI system or code analyzer, and must be configured on the project in advance by an administrator. Since we want Zuul to report the result of each job it runs on a change, and we don't know that set of jobs until we start, the current implementation doesn't fit the model very well. For the moment, we can use the checks API to report the overall buildset result, but not the jobs. We can, of course, still use Gerrit change messages to report the results of individual jobs just as we do now. But ideally, we'd like to take full advantage of the structured data and reporting the checks API provides. To that end, I've offered to write a design document[1] describing an implementation of support for "sub-checks" -- an idea which appeared in the original checks API design as a potential follow-up. Sub-checks would simply be structured data about individual jobs which are reported along with the overall check result. With this in place, Zuul could get out of the business of leaving comments with links to logs, as each sub-check would support its own pass/fail, duration, and log url. Later, we could extend this to support reporting artifact locations as well, so that within Gerrit, we would see links to the log URL and docs preview sites, etc. There is an opportunity to do some cross-repo testing between Zuul and Gerrit as we work on this. Upstream Gerrit's Gerrit does not have the SSH event stream available, so before we can do any work against it, we need an alternative. I think the best way forward is to implement partial (experimental) support for the checks API, so that we can at least use it to trigger and report on changes, get OpenDev's Zuul added as a checker, and then work on implementing sub-checks in upstream Gerrit and then Zuul. Conclusion ---------- I'm sure I'm leaving stuff out, so feel free to prompt me with questions. In general we got a lot of work done and I think we're set up very well for future collaboration. -Jim [1] https://gerrit-review.googlesource.com/Documentation/dev-contributing.html#… [2] https://model-engineers.com/en/company/references/success-stories/volvo-car…

1 0

Zuul posts non hiddable Gerrit comments
by Vitaliy Lotorev 04 Sep '19

04 Sep '19

Hi, Starting with at least v2.15 Gerrit is able to differentiate bot comments and hide them using 'Show comments' trigger on web UI. This is achived either using tagged comments or robot comments. A while ago I filed an issue about Zuul not using these technics [1] (ticket has links for Gerrit docs with tagged and robot comments). This results that Zuul comments are not hiddable in Gerrit. AFAIK, sending tagged comments via SSH to Gerrit is easy (one-line of code at [2]). I could try providing a patch for tagged comments. What Zuul maintainers think about adding support for bot comments? Should not be sending tagged comments done only if Gerrit version >= 2.15? [1] https://storyboard.openstack.org/#!/story/2005661 [2] https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/gerrit/gerritco…

4 4

review.opendev.org Outage September 16 to Perform Project Renames
by Clark Boylan 04 Sep '19

04 Sep '19

Hello, We will be taking a Gerrit outage of about an hour on September 16 at 14:00 UTC to perform project renames. Please let us know if this scheduling does not work for some reason. We have tried to schedule this for a quiet time at the end of OpenStack's Train release cycle. Also, if you'd like to rename a project, now is the time to start prepping for that. Feel free to ask us any questions you have or bring up your concerns with us. Thank you for your patience, Clark

1 0

Zuul at the Open Source Summit Europe; Zuul swag
by Matthieu Huin 30 Aug '19

30 Aug '19

Hello list, I am pleased to announce that I will be giving a presentation on Zuul with Fabien Boucher at the upcoming Open Source Summit in Lyon, France! The description of the session can be found here: https://osseu19.sched.com/event/TLMB/stop-merging-broken-code-an-introducti… This summit is right before the Shanghai Summit (October 28-30). Feel free to advertise our session! It would be nice to have some Zuul swag before the OSS to hand out and leave around; especially stickers as they were a huge hit at FOSDEM this year. Who should I contact about this? -- Matthieu Huin Senior Software Developper Red Hat <https://www.redhat.com> <https://red.ht/sig>

3 3