- Zuul-discuss - lists.opendev.org

Software Factory 3.0 released
by Tristan Cacqueray 31 Mar '18

31 Mar '18

Greeting folks, We are pleased to announce the release of Software Factory version 3.0: http://www.softwarefactory-project.io/releases/3.0 It is a software development forge that integrates the last version of Zuul and Nodepool along with a few patches that couldn't make it into the upstream release: * Ansible-2.4 support: https://review.openstack.org/535839 * Dynamic tenant configuration: https://review.openstack.org/535878 * MQTT reporter: https://review.openstack.org/535543 * Job and … [View More]

3 3

Next steps after 3.0.0 release
by corvus＠inaugust.com 30 Mar '18

30 Mar '18

Hi, Now that 3.0.0 is released[1] (yay!), it's a good time to go over what we need to do next. The first order of business is to land the changes to add reno: https://review.openstack.org/536861 https://review.openstack.org/262597 You should read the docs that those changes introduce (they'll be in the developer docs for future reference), but the key bit is: When adding a noteworthy feature, fixing a noteworthy bug or introducing a behavior change that a user or operator should … [View More]know about, it is a good idea to add a release note to the same patch. Every release from this point out will have release notes included in the documentation. We relaxed our review standards significantly during the feature branch phase, but we've been returning to normal for the past few months. At this point, the master branches of Nodepool and Zuul should always be kept working and ready for release. Gating usually handles the technical side of that, but don't lose track of the intent when it comes to other aspects. Please make sure that changes have documentation if they affect a user-visible aspect of the system, have a release note if the change is noteworthy, and have tests if they alter behavior. If a change is missing these things, please ask about it. These rules don't need to be too rigid, but if we flex them, we should be in the habit of discussing it and establishing that there's a good reason. We need to be careful about making changes to the zuul-jobs and zuul-base-jobs repos now. We'll write up a policy and include it in the docs for those repos, but the important thing is that we can't use new Zuul features in those repos until we've given folks a chance to upgrade (so probably some number of weeks after the feature appears in a release). And we can't remove features from Zuul until we've removed their use from zuul-jobs, and given folks who might be running a fork of zuul-jobs time to update. I expect us to release Zuul and Nodepool much more often now. Any time we make a significant change and establish that the software is working as intended, we should release. We've assigned some very specific meaning to version numbers recently, but don't think that will continue. The versions we release will be what they are depending on what has landed when we release. Thanks everyone for your work on the release, and I look forward to reviewing all the patches that are waiting in the wings! -Jim [1] http://lists.zuul-ci.org/pipermail/zuul-announce/2018-March/000006.html [View Less]

1 0

Docs and git repos on zuul-ci.org
by corvus＠inaugust.com 28 Mar '18

28 Mar '18

Hi, We now have all of the Zuul documentation hosted on the Zuul website[1], so folks may want to start referencing those URLs, rather than docs.openstack.org. We also have the Zuul git repos mirrored under the Zuul domain at [2]. That page shows only the Zuul-related git repos. Additionally, if you're referencing the zuul-jobs or zuul-base-jobs repos, you may want to switch your connection to use git.zuul-ci.org instead. Note that if you do that, the project name will be "git.zuul-ci.org/… [View More]

2 2

Re: [OpenStack-Infra] Zuul: Question about Github webhook
by Melvin Hillsman 23 Mar '18

23 Mar '18

I also have went through the "ZFS" at least once and ran into quite a few issues I think and started documenting[0] them. Bernd not sure if you have run into additional issues but feel free to add to the etherpad; it is not organized at all right now but the plan was/is to report back a list of things and patch(es). [0] https://etherpad.openstack.org/p/zuul-quickstart-and-zfs(zuul-from-scratch) On Wed, Mar 21, 2018 at 3:26 AM, <Tobias.Henkel(a)bmw.de> wrote: > Hi Bernd, > > … [View More]On 21.03.18, 08:54, "Bernd Bausch" <berndbausch(a)gmail.com> wrote: > > Sorry for this newbie intrusion on the distribution list. I am trying > to > follow the Zuul from Scratch instructions[1] to set up Zuul at home. > The > purpose is twofold: Learn about Zuul, and check whether Zuul from > Scratch > instructions are accurate and make sense. > > Currently I am at a roadblock. > > The problem is the Github webhook, through which Github sends data to > Zuul. > It should be > http://<zuul-hostname>/connection/github/payload [2], but on the Zuul > server > that > I have deployed so far, nothing listens at port 80. Thus, Github gets > a "connection refused" when trying to contact my server. I used > tcpdump to > confirm that my server does indeed receive an http POST from Github. > > Either something is wrong with my setup, which prevents Zuul from > listening > at > 80. Or the webhook isn't documented correctly. > > How can I confirm what could be the problem? > > Bernd > > [1] https://docs.openstack.org/infra/zuul/admin/zuul-from-scratch.html > [2] https://docs.openstack.org/infra/zuul/admin/drivers/github.html, > https://docs.openstack.org/infra/zuul/admin/zuul-from- > scratch.html#configure > -github > > > It looks like you discovered a bug in the zuul-from-scratch docs. Zuul-web > by default > listens on port 9000. While the documented webhook config in github > assumes port 80. > So you need to either change the webhook to use 9000 or change the zuul > config to use > port 80 [1]. > > Further I pushed up a change to fix the doc [2]. > > Sidenote: we now have zuul specific mailing lists [3] so you might want to > also subscribe > to them. > > [1] https://docs.openstack.org/infra/zuul/admin/components. > html#attr-web.port > [2] https://review.openstack.org/554829 > [3] http://lists.zuul-ci.org > > Kind regards > Tobias > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646 [View Less]

3 4

Services missing tenant scope (nodepool-*, zuul-executor)
by Tristan Cacqueray 19 Mar '18

19 Mar '18

Hello folks, Is there a plan to add a tenant scope to all the services? For example, we could add the tenant name to NodeRequest and a 'tenant' setting in nodepool.yaml so that a provider and its labels could be restricted to a particular tenant. Similarly for the executors, we could be able to isolate tenant job execution from each other. Has this been discussed at the PTG? Regards, -Tristan

2 2

Zookeeper ConnectionLoss/SessionExpired issues
by Tristan Cacqueray 16 Mar '18

16 Mar '18

Hello folks, Here is a recap of the issues happening when the connection to Zookeeper is unstable: * Nodepool marks dib build as failed, * ConnectionLoss/SessionExpired exceptions happen when the connection drop after the "self._zk.suspended or self._zk.lost" checks, * Zuul lost NodeRequest which may lock change in queued state, and * Zookeeper needs to be running before starting Zuul or Nodepool, otherwise the daemon stay stuck in limbo. This used to happen frequently in our deployment (… [View More]

5 16

Disabling nullwrap
by corvus＠inaugust.com 14 Mar '18

14 Mar '18

Hi, The recent security fixes have underscored that bubblewrap is currently key to Zuul executor security. While Zuul does have an option to run without bubblewrap (called "nullwrap"), it is not recommended, and it doesn't support secrets, which is a fairly important feature. Nullwrap was written with the idea of aiding those use-cases where it is not possible to run with bubblewrap. However, I think that if such a case still exists, we should work to address that -- nullwrap really shouldn'… [View More]

4 3

Landing changes to zuul-web javascript
by Monty Taylor 10 Mar '18

10 Mar '18

Hey everybody! Something just occurred to me while reviewing the next set of patches from Tristan to zuul-web that I think is important to share more broadly. In OpenStack's deployment of Zuul, HTML/JS changes to zuul-web go live basically immediately (give or take 15 minutes) No services need to be restarted or anything. However, while the python code will also be _installed_ at the same time, it will not go live immediately. It's also completely possible for someone to deploy web … [View More]

3 4

working on zuul trigger plugin for jenkins
by Darragh Bailey 08 Mar '18

08 Mar '18

Hi, Spend some time last week hacking away at a zuul trigger plugin for jenkins, really just about getting some better understanding of how this should hang together and what questions need to be asked. Lots of time spent reading details on gRPC as it was suggested at https://etherpad.openstack.org/p/zuulv3-jenkins-integration So far I've got a (very) rudimentary gRPC server that responds to a single status request with OK working as a Jenkins plugin that starts up automatically. I'll try to … [View More]get it released somewhere soon so it's possible to discuss code, though if it is of interest to the OpenStack community maybe it should be hosted on review.openstack.org? Some general things I've noted: - authenticating requests doesn't appear to be straight forward with gRPC - unclear whether this can share the default jenkins http port even though gRPC and REST (currently using dedicated port) can technically do this - given the number of messages exchanged for a single job, should this use bidirectional streaming - started with a proto layout that is mostly unary client calls and server streaming responses - but should the trigger really be a single connection with multiple messages around the hand-off coordination? I've also had a bunch of questions to bounce off Monty around how to deal with Zuulv3 and Jenkins node coordination, the upshot of those is to leave that to nodepool and probably help out with the Jenkins nodepool plugin and make that a dependency of the zuul trigger plugin. For more detail, originally I was worrying about how to ensure zuul trigger plugin would work without using the nodepool plugin, and it would end up needing to query Jenkins as to whether it had the resources to execute the on before triggering, and this would require a deeper integration into Zuul. It was suggested that this would complicate it deeply and would be better to have nodepool manage the resources, so that zuul would only start the ansible job that would call the zuul trigger API endpoints if nodepool had sufficient resources for Jenkins to use to execute the job. It appears clear any migration path to Zuulv3 involving Jenkins would want to use Zuulv2 -> Gearman -> Jenkins -> Nodepoolv3 first, then migrate Zuulv3. So I'm looking to help on the Jenkins Nodepool plugin first, and that will probably make it much more straight forward to understand what needs to be done in the trigger plugin. A couple of weeks ago someone was in the Zuul room chatting about working on the Nodepool plugin for Jenkins, wondering if there has been any progress there, and what I can help out with in the future. -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" [View Less]

1 0

[nodepool] Webapp label_list
by David Shrewsbury 01 Mar '18

01 Mar '18

Greetings! We have recently merged a change to add the label_list command to nodepool's webapp [1]. For that change, we briefly discussed in IRC [2] the meaning of the "count" parameter that was originally within the output of that command. The tl;dr from me in that discussion was that count without considering node state has no meaning. The final PS of that review left count out of the results. There is now another change proposing to add that count back in [3]. I think this functionality … [View More]

4 8