June 2019 - Zuul-discuss - lists.opendev.org

OpenInfra Days Vietnam 2019 (Hanoi) - Call For Presentations
by Trinh Nguyen 12 Jul '19

12 Jul '19

Hello, Hope you're doing well :) The OpenInfra Days Vietnam 2019 [1] is looking for speakers in many different topics (e.g., container, CI, deployment, edge computing, etc.). If you would love to have a taste of Hanoi, the capital of Vietnam, please join us this one-day event and submit your presentation [2]. *- Date:* 24 AUGUST 2019 *- Location:* INTERCONTINENTAL HANOI LANDMARK72, HANOI, VIETNAM Especially this time, we're honored to have the Upstream Institute Training [3] hosted by the OpenStack Foundation on the next day (25 August 2019). [1] http://day.vietopeninfra.org/ [2] https://forms.gle/iiRBxxyRv1mGFbgi7 [3] https://docs.openstack.org/upstream-training/upstream-training-content.html See you in Hanoi! Bests, On behalf of the VietOpenInfra Group. -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 1

Assigning nodeset/nodes dynamically based in user who made the pull request in github
by Kasibhatla Sarma 30 Jun '19

30 Jun '19

Hi Team, I am trying to see if there are any options using which I can select the nodeset/nodes dynamically. For example, assume that I have two users in two different regions (us-west and us-east) Based on who made the pull request in GitHub, we would like to run the check/gate pipelines on specific nodes. For example, - nodeset: name: emea nodes: - name: node_emea label: centos76 groups: - name: emea nodes: - node_emea The first job returns the location of the user who made a pull request (say zuul_location) - job: name: check_location run: playbooks/check_location.yaml parent: base I would like to use the location in the nodeset as something like this.. - job: name: pullrequest_label run: playbooks/pullrequest_label.yaml dependencies: - check_location parent: base vars: location: "{{ zuul_location }}" nodeset: "{{ zuul_location }}" I would like to know if there are ways to achieve this Thanks, Sarma K

5 8

CFP Deadline for Open Infrastructure Summit Shanghai
by Jimmy McArthur 26 Jun '19

26 Jun '19

Hi Everyone! The July 2 deadline to submit a presentation [1] for the Open Infrastructure Summit [2] in Shanghai is in less than one week! Submit your session today and join the global community in Shanghai, November 4-6, 2019. Sessions will be presented in both Mandarin and English, so you may submit your presentation in either language. Submit your presentations, panels, and hands-on workshops [3] before July 2 at 11:59 pm PT (July 3, 2019 at 15:00 China Standard Time). Tracks [4]: Container Infrastructure Hands-on Workshops AI, Machine Learning & HPC Private & Hybrid Cloud Public Cloud 5G, NFV & Edge Open Development Getting Started CI/CD Security Upcoming Shanghai Summit Deadlines * Register now [5] before the early bird registration deadline in early August (USD or RMB options available) * Apply for Travel Support [6] before August 8. For more information on the Travel Support Program, go here [7]. * Interested in sponsoring the Summit? [8]. * The content submission process for the Forum and Project Teams Gathering will be managed separately in the upcoming months. We look forward to your submissions! Cheers, Jimmy [1] https://cfp.openstack.org/ [2] https://www.openstack.org/summit/shanghai-2019/ [3] https://cfp.openstack.org/ [4] https://www.openstack.org/summit/shanghai-2019/summit-categories/ [5] https://www.openstack.org/summit/shanghai-2019/ [6] https://openstackfoundation.formstack.com/forms/travelsupportshanghai [7] https://www.openstack.org/summit/shanghai-2019/travel/ [8] https://www.openstack.org/summit/shanghai-2019/sponsors/

1 0

Feedback for Zuul web UI
by Paul Belanger 24 Jun '19

24 Jun '19

Greetings, I wanted to share some feedback I've gotten over the last few weeks about the Zuul web UI, I am mostly doing so, because I am struggling to make progress on fixing these issue myself (I don't have my JS experience). Here are a few recent examples: Builds page ----------- * Lack of pagination support. Currently, there is no easy way to scroll through the history of the builds UI. Right now, it is hardcoded to a single page, of 50 results. Users would like the ability to go further backwards in time, even listing more then 50 results per page. * More filters. It has been asked, for the ability to add filtering for start / end time ranges. This would allow a user to create a weekly report email, linking to the results of the week. The context is periodic jobs. Voting / non-voting jobs has also been requested. * Regex of job name filters. We currently have a lot of jobs which append the version of python onto a job name. For example, ansible-test-network-integration-vyos-python37, ansible-test-network-integration-vyos-python36, etc. A few users have requested the ability to use a single regex for job name filter. Buildset page ------------- * Add link to builds page of jobs that ran. Some users would like to see a link create, which auto creates the build page filters for a change that was build. This is because, in our case we have some jobs to do not report back to github, and depending on PR to list jobs isn't 100%. I'm happy to give additional information if needed, or also happy to write the code, howerver I'd likely need some hand holding for the first little bit. Thanks! Paul

2 1

Zuul autohold changes
by David Shrewsbury 17 Jun '19

17 Jun '19

Hello, I've mentioned this info in the IRC channel, but thought it would be a good idea to mention this on the mailing list as well. I have a series of changes [1] up that significantly change the way Zuul deals with autohold requests. The tl;dr of it is that we now store those requests in ZooKeeper rather than in memory. Advantages of this change are: 1. Easily identify which nodes are held for a request and to easily delete those held nodes when the request is deleted. 2. Supports future scheduler scale-out. 3. Hold requests are kept across Zuul restarts. This work conflicts with Matthew's work on the web API [2] as it adds new commands for deleting autohold requests, and getting autohold detail information. I fully expect his work to merge first, so my series of changes will likely need rework after that merge. I bring this up because I'm about to be AFK for a couple of weeks for shoulder surgery (such fun), so if those merges happen while I'm out, I'm hoping someone can volunteer to fix any merge conflicts or other minor changes that may be needed. Since this all started because of a hand-wavey comment from Monty, I volunteer him. :) :) :) j/k [1] https://review.opendev.org/#/q/topic:autohold-revamp [2] https://zuul-ci.org/docs/zuul/developer/specs/tenant-scoped-admin-web-API.h… -Shrews

2 1

Reviews for the Bitbucket Server driver
by Mark Meyer 13 Jun '19

13 Jun '19

Hi, I'd like you to review the Bitbucket Server driver for Zuul. We now have all the components in place. Basic testing shows that it's working and my team at work has been using it for a while in an experimental setting. Now we need to go the next steps and have it refined. *Not Bitbucket Cloud Thanks, mark -- Mark Meyer mark(a)ofosos.org

1 0

Slack connectivity
by Mark Meyer 12 Jun '19

12 Jun '19

Hey list, I'd like to gauge interest here. So you want connectivity options for slack? I'm thinking of having this as part of zuul to trigger jobs and report results, out alternatively as an external bit that runs on the scheduler node. We already have some code and some ideas. But I don't feel like walking that path on my own. What so you think? Cheers, mark -- Mark Meyer mark(a)ofosos.org

4 3

GitHub API ReadTimeout Errors
by Paul Belanger 12 Jun '19

12 Jun '19

Greetings, We (ansible team) are running into a issue using the zuul github driver, please see the following pastebin: http://paste.openstack.org/show/752756/ As you can see, we don't seem to be getting reliable network access to api.github.com. I am currently trying to figure out if this is a network issue with our control plane provider (vexxhost) or something related to GitHub side (eg: bad load balancer). However, what it does result in, is Zuul missing events from GitHub and not properly enqueue PRs into the pipelines. I understand there is only so much we might be able to do regarding a network issue, but I'd be interested to hear if there are idea of how we could tolerate them more. I also wonder if we should be reporting these issues back to the users PR too. My main goal is to minimize the amount of humans that _think_ zuul is to blame for tests not being run on their PRs, when in fact it is something else. - Paul

2 3

Shanghai PTG Changes
by Kendall Nelson 11 Jun '19

11 Jun '19

Hello All, After Denver we were able to take time to reflect on the improvements we can make now that the PTG will occur immediately following the summit for the near future. While Shanghai will have its own set of variables, it's still good to reevaluate how we allocate time for groups and how we structure the week overall. tldr; - Onboarding is moving into the PTG for this round (updates stay a part of the Summit) - You can still do regular PTG stuff (or both onboarding and regular PTG stuff) - PTG slots can be as short as 1/4 of a day - More shared space at the Shanghai venue, less dedicated space - New breakdown: 1.5 days of Forum and 3.5 days of PTG - Survey will be out in a few weeks for requesting PTG space We'll have our traditional project team meetings at the PTG in Shanghai as the default format, that won't change. However, we know many of you don't expect to have all your regulars attend the PTG in Shanghai. To combat this and still help project teams make use of the PTG in the most effective way possible we are encouraging teams that want to meet but might not have all the people they need to have technical discussions to meet anyway and instead focus on a more thorough onboarding of our Chinese contributors. Project teams could also do a combination of the two, spend an hour and a half on onboarding (or however much time you see fit) and then have your regular technical discussions after. Project Updates will still be a part of the Summit like normal, its just the onboardings that will be compacted into the PTG for Shanghai. We are making PTG days more granular as well and will have the option to request 1/4 day slots in an effort to leave less empty space in the schedule. So if you are only doing onboarding, you probably only need 1/4 to 1/2 of a day. If you are doing just your regular technical discussions and still need three days, thats fine too. The venue itself (similar to Denver) will have a few large rooms for bigger teams to meet, however, most teams will meet in shared space. For those teams meeting to have only technical discussions and for teams that have larger groups, we will try to prioritize giving them their own dedicated space. For the shared spaces, we will add to the PTGbot more clearly defined locations within the shared space so its easier to find teams meeting there. I regret to inform you that, again, projection will be a very limited commodity. Yeah.. please don't shoot the messenger. Due to using mainly shared space, projection is just something we are not able to offer. The other change I haven't already mentioned is that we are going to have the PTG start a half day early. Instead of only being 3 days like in Denver, we are going to add more time to the PTG and subtract a half day from the Forum. Basically the breakdown will be 1.5 Forum and 3.5 PTG with the Summit overlapping the first two days. I will be sending the PTG survey out to PTLs/Project Leads in a couple weeks with a few changes. -Kendall Nelson (diablo_rojo)

1 0

Zuul project update 2019-06-10
by corvus＠inaugust.com 10 Jun '19

10 Jun '19

Hi, Last week we merged the Tenant-scoped admin web API spec: https://zuul-ci.org/docs/zuul/developer/specs/tenant-scoped-admin-web-API.h… We can start reviewing the implementation for that now (status:open topic:zuul_admin_web). David is finishing up a series which stores autohold information in Zookeeper to improve the experience around that. Tobias has continued his work on adding event IDs to log messages. Clark is moving us to node version 10 across all of our javascript jobs. Mark Meyer has been refining his patch series to add a Bitbucker driver. I've been (and will continue to) work on moving Zuul into its own tenant in the OpenDev Zuul. That will require some changes to where we publish branch-tip builds. Help write the next update email by updating https://etherpad.openstack.org/p/zuul-update-email Thanks, Jim

1 0

Toggle host-key-checking per label
by Paul Belanger 05 Jun '19

05 Jun '19

Greetings, I'd like to get a few eyes on https://review.opendev.org/663378/ please, as I'm currently blocked on doing some network automation with nodepool / zuul. Due to issues with a network appliance, we have a use case where an interface comes online but there is no default gateway assigned (apparently this needs to be done by a human). In this case, we actually want nodepool to launch the node, but not scan for hostkeys. This is okay for us, because zuul doesn't directly manage this node (due to connection being network_cli), we actually create a nodeset with another node (fedora) that zuul can still reach then use nested ansible to provision the network appliance. We cannot move the network node into its own pool, because we cannot split labels multinodes across pools, we get node_failures back from nodepool. I'm open to other ideas / solutions to work around this use-case, but believe adding a host-key-checking toggle at the label level, should work. - Paul

1 0