January 2024 - Zuul-discuss - lists.opendev.org

Persist changes to job inventory
by James E. Blair 17 Jan '24

17 Jan '24

Hi, I'm looking into a use case that involves the Nodepool k8s namespace driver. The intent with this driver is to provide a job with a namespace in which it can create its own k8s resources. It might then use those resources directly, or call a nested Ansible to interact with k8s, or add them to the Zuul job's Ansible inventory using add_host. However, that last option doesn't persist across playbooks, and Zuul jobs are typically made up of multiple playbooks which can make some kinds of work difficult (for example, necessitating running add_host at the start of each playbook). The inventory file itself is mounted in bubblewrap read-only, so even direct manipulation of the file is not an option to address persistence. I think we could change that and allow updates to the Zuul job's Ansible inventory file (either through direct manipulation, or via a custom add_host or similar module). Though I don't see any issues now, there may be security implications that I'm not immediately seeing, so I wanted to circulate the idea and get feedback before proceeding. I believe that since any playbook can already use the add_host module to affect the running of that playbook, then any concerns about access to resources using Zuul's ssh keys are moot. Most installations drop the built-in nodepool ssh keys during an early pre-run playbook, so this change would offer no ability to circumvent that. Likewise, project ssh keys are always present at the project level, regardless of which playbook is running. The main potential avenue for mischief that I can see would be the ability to substitute one host for another before a later trusted playbook (eg, a post-run playbook) is run. However, if such a playbook is depending on an *existing* inventory host being present (as opposed to executing its own add_host to, say, add a log server to the inventory), then that is already subject to the ability of users to change the nodeset on jobs just as easily as they might change the playbook of a job. I think such a situation would only be possible in a system where users have no ability to create or edit jobs yet do have the ability to edit playbooks. That seems very unlikely, and even more unlikely that anyone would consider that completely secure from abuse. I'm inclined to think that adding the ability to persist inventory changes across Zuul job playbooks is safe to do. But please let me know if you think that could cause problems. Thanks, Jim

2 1

Is the Zuul Quickstart tutorial abandoned?
by anders.klint＠qamcom.se 11 Jan '24

11 Jan '24

Hi, Way back (several years ago) I worked in a team using Zuul as one of several tools for CI. Running through the quickstart tutorial was a great way to get started and get a feeling for Zuul. I am now looking at Zuul again a potential tool in another setting and planned to run a "refresher" by working through the tutorial again. Sadly i only got part of the way (no results on changes to test1 project) and a _little_ digging shows that both zuul-tutorial-executor-1 and zuul-tutorial-gerritconfig-1 containers fails directly on start. Looking at the bugs list in storyboard, I find at https://storyboard.openstack.org/#!/story/2007325 that was created almost 4 years(!) ago with basically the same symptom(s). I remember the tutorial as a great start and intro to Zuul, but it needs to be solid. With the tutorial as one of the first links on several Zuul-ci.org pages, having it broken (for years??) is not really a great starting experience for a tool with the slogan "Stop merging broken code". Is it abandoned?

2 1

Fwd: Team Signup for April 2024 OpenInfra PTG
by Kendall Nelson 10 Jan '24

10 Jan '24

Hello Everyone, Hopefully, you have seen by now, that the next OpenInfra PTG[1] will take place April 8-12, 2024 virtually! *To sign up your team, you must complete the survey[2] by February 18 at 7:00 UTC.* We NEED accurate contact information (email and IRC nickname ideally) for the moderator of your team’s sessions. This is because the survey information will be used to organize the schedule sign ups which will be done via the PTGBot. If you are not on IRC, please get set up[3] on the OFTC network and join #openinfra-events. You are also encouraged to familiarize yourself with the PTGBot documentation[4] as well. If you have any questions, please reach out! Information about signing up for timeslots will be sent to moderators late February after the team sign up deadline. Continue to visit openinfra.dev/ptg for updates. Registration will open soon! -Kendall Nelson (diablo_rojo) [1] PTG Site: https://openinfra.dev/ptg/ [2] Team Survey: https://openinfrafoundation.formstack.com/forms/april2024_ptg_survey [3] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 0

Project lead election
by James E. Blair 09 Jan '24

09 Jan '24

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 15, 2024. 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/905001

1 0