- 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 17 Feb '20

17 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 06 Jan '20

06 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 03 Dec '19

03 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