| *** tosky has quit IRC | 00:12 | |
| *** holser has joined #zuul | 00:18 | |
| *** ikhan has joined #zuul | 01:05 | |
| *** holser has quit IRC | 01:14 | |
| *** ikhan has quit IRC | 01:42 | |
| *** ikhan has joined #zuul | 02:54 | |
| *** ikhan has quit IRC | 03:01 | |
| *** ikhan has joined #zuul | 03:10 | |
| *** bhavikdbavishi has joined #zuul | 03:15 | |
| *** bhavikdbavishi1 has joined #zuul | 03:38 | |
| *** bhavikdbavishi has quit IRC | 03:39 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:39 | |
| *** bhagyashris has joined #zuul | 04:19 | |
| *** bhavikdbavishi has quit IRC | 04:54 | |
| *** ikhan has quit IRC | 05:02 | |
| *** ykarel has joined #zuul | 05:13 | |
| *** ikhan has joined #zuul | 05:16 | |
| *** ikhan has quit IRC | 05:21 | |
| *** bhavikdbavishi has joined #zuul | 05:25 | |
| *** bhavikdbavishi1 has joined #zuul | 05:28 | |
| *** bhavikdbavishi has quit IRC | 05:29 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 05:29 | |
| *** ykarel_ has joined #zuul | 05:32 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #zuul | 05:33 | |
| *** ykarel has quit IRC | 05:34 | |
| *** ykarel_ is now known as ykarel | 05:35 | |
| *** ikhan has joined #zuul | 05:47 | |
| *** vishalmanchanda has joined #zuul | 06:14 | |
| *** ikhan has quit IRC | 06:36 | |
| *** bhavikdbavishi has quit IRC | 07:07 | |
| *** bhavikdbavishi has joined #zuul | 07:07 | |
| *** bhavikdbavishi has quit IRC | 07:20 | |
| *** bhavikdbavishi has joined #zuul | 07:31 | |
| *** bhavikdbavishi1 has joined #zuul | 07:34 | |
| *** bhavikdbavishi has quit IRC | 07:36 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 07:36 | |
| *** jcapitao has joined #zuul | 08:15 | |
| *** hashar has joined #zuul | 08:32 | |
| *** vishalmanchanda has quit IRC | 08:34 | |
| *** tosky has joined #zuul | 08:35 | |
| *** rpittau|afk is now known as rpittau | 08:51 | |
| *** arxcruz|2021 is now known as arxcruz | 08:58 | |
| *** nils has joined #zuul | 09:14 | |
| *** icey has quit IRC | 09:19 | |
| *** icey has joined #zuul | 09:25 | |
| *** hamalq has joined #zuul | 09:42 | |
| *** hamalq has quit IRC | 09:46 | |
| *** ikhan has joined #zuul | 09:57 | |
| *** hamalq has joined #zuul | 09:57 | |
| *** hamalq has quit IRC | 10:02 | |
| *** lyr has quit IRC | 10:22 | |
| *** lyr has joined #zuul | 10:23 | |
| *** saneax has joined #zuul | 10:26 | |
| *** sanjayu_ has joined #zuul | 10:28 | |
| *** saneax has quit IRC | 10:31 | |
| *** lyr has quit IRC | 10:39 | |
| *** lyr has joined #zuul | 10:40 | |
| *** rfolco has joined #zuul | 10:41 | |
| *** lyr has quit IRC | 10:47 | |
| *** sanjayu_ has quit IRC | 10:49 | |
| *** lyr has joined #zuul | 10:49 | |
| *** ikhan has quit IRC | 10:52 | |
| *** ikhan has joined #zuul | 11:16 | |
| *** ikhan has quit IRC | 11:21 | |
| *** hashar is now known as hasharLunch | 11:53 | |
| *** ikhan has joined #zuul | 11:54 | |
| *** holser has joined #zuul | 11:59 | |
| *** jcapitao is now known as jcapitao_lunch | 12:03 | |
| *** dry has quit IRC | 12:22 | |
| *** dry has joined #zuul | 12:24 | |
| *** ykarel has quit IRC | 12:33 | |
| *** ykarel has joined #zuul | 12:33 | |
| *** bhavikdbavishi has quit IRC | 12:35 | |
| *** bhavikdbavishi has joined #zuul | 12:36 | |
| *** ykarel_ has joined #zuul | 12:37 | |
| *** rlandy has joined #zuul | 12:37 | |
| *** ykarel has quit IRC | 12:37 | |
| *** bhavikdbavishi1 has joined #zuul | 12:47 | |
| *** bhavikdbavishi has quit IRC | 12:49 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 12:49 | |
| *** sduthil has joined #zuul | 12:50 | |
| *** holser has quit IRC | 12:51 | |
| *** jcapitao_lunch is now known as jcapitao | 12:55 | |
| *** ikhan has quit IRC | 12:57 | |
| *** bhavikdbavishi has quit IRC | 13:11 | |
| *** ikhan has joined #zuul | 13:24 | |
| *** tosky has quit IRC | 13:30 | |
| *** tosky has joined #zuul | 13:30 | |
| sshnaidm | is it possible to set zuul log debug only for a specific gerrit connection? or for a specific project? | 13:38 |
|---|---|---|
| *** CrayZee has quit IRC | 13:53 | |
| *** snapiri has joined #zuul | 13:53 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: gerrit: fix invalid ref computation from change https://review.opendev.org/c/zuul/zuul/+/768229 | 14:11 |
| *** lyr has quit IRC | 14:17 | |
| *** lyr has joined #zuul | 14:18 | |
| *** lyr has quit IRC | 14:21 | |
| *** lyr has joined #zuul | 14:22 | |
| *** hasharLunch is now known as hashar | 14:45 | |
| zbr | it seams that I cannot even build the docs on macos because gear is incompatible, AttributeError: module 'select' has no attribute 'EPOLLET' | 14:45 |
| *** jcapitao has quit IRC | 14:45 | |
| zbr | and this is triggered even by simple command like: zuul-manage-ansible --help | 14:45 |
| zbr | there are 3 modules that trigger the broken gear: github, pagure and gitlab | 14:46 |
| *** jcapitao has joined #zuul | 14:46 | |
| zbr | i only want to made the "tox -e docs" to pass. any ideas? | 14:47 |
| tristanC | zbr: it doesn't seem like zuul or gear is tested/designed to run on macos. why are you not using linux? | 14:58 |
| zbr | tristanC: https://review.opendev.org/c/opendev/gear/+/708267 | 15:14 |
| fungi | zbr: do docs builds on macos work with that darwin support patch for gear in place? | 15:22 |
| zbr | testing now | 15:23 |
| zbr | not knowing about that patch i made another one,... one min | 15:23 |
| zbr | fungi: yes, they do. | 15:24 |
| zbr | in fact is quite simple: the missing attributes from select are what prevented it. and bad part is that this happened on just "import gear" | 15:24 |
| zbr | even if you would not need to use it | 15:25 |
| *** ykarel_ has quit IRC | 15:26 | |
| *** rfolco has quit IRC | 15:31 | |
| zbr | having a canary freebsd (or similar) node could prove useful for detecting such issues | 15:33 |
| fungi | i suppose the socket object could be lazily created to avoid that as well | 15:33 |
| fungi | i'm not opposed to having freebsd nodes in opendev, just nobody's done the work to support it in diskimage-builder yet | 15:34 |
| fungi | (last i looked anyway) | 15:34 |
| zbr | there is also my earlier stupid approach https://review.opendev.org/c/opendev/gear/+/769151/ -- but that one should be very safe. | 15:37 |
| *** bhavikdbavishi has joined #zuul | 15:47 | |
| *** bhavikdbavishi1 has joined #zuul | 15:50 | |
| *** bhavikdbavishi has quit IRC | 15:51 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 15:51 | |
| *** ykarel_ has joined #zuul | 15:55 | |
| *** ykarel_ has quit IRC | 16:03 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Pin pyjwt to 2.0.0 and fix issues due to version bump https://review.opendev.org/c/zuul/zuul/+/768312 | 16:18 |
| *** rfolco has joined #zuul | 16:19 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: gerrit: fix invalid ref computation from change https://review.opendev.org/c/zuul/zuul/+/768229 | 16:43 |
| *** hamalq has joined #zuul | 16:53 | |
| *** hashar is now known as hasharAway | 16:56 | |
| mhu | Am I the only one hitting errors with zuul-quick-start? Looks like provisioning the admin in gerrit is failing, for example https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_2b6/768312/2/check/zuul-quick-start/2b6cff3/container_logs/gerritconfig.log | 17:03 |
| mhu | also happy new year! | 17:03 |
| clarkb | mhu: I believe that job uses an up to date gerrit docker image. Wouldn't surprise me if an upstream change ahs broken it | 17:07 |
| fungi | Invalid project configuration: project.config: group "Non-Interactive Users" not in groups | 17:07 |
| fungi | maybe the Non-Interactive Users group has been removed | 17:07 |
| mhu | fungi, yep, weird | 17:07 |
| fungi | but yeah, this is the first i've noticed it | 17:07 |
| fungi | build history says the last successful run of zuul-quick-start was 2020-12-23 18:12:29 utc | 17:09 |
| fungi | first failure was 2020-12-27 10:54:55 utc | 17:09 |
| fungi | so perhaps something in that four-day span | 17:09 |
| clarkb | gerritcodereview/gerrit is the image used | 17:09 |
| fungi | and yeah, same error in that earliest failure from the 27th: https://zuul.opendev.org/t/zuul/build/f2a55eeb4ff541bca1d9d4c08e04b580/log/container_logs/gerritconfig.log#44 | 17:10 |
| clarkb | a quick and easy check would be to set ti to gerritcodereview/gerrit:3.3.1 or :3.2.6 and see if it works | 17:11 |
| mhu | last update to the container was 12 days ago | 17:11 |
| fungi | 12 days ago was our last successful run too, so that could be it | 17:11 |
| mhu | looks like all 3.x tags were updated | 17:12 |
| clarkb | mhu: yes, but we are using latest which is 3.4.dev aiui | 17:12 |
| clarkb | unrelated https://etherpad.opendev.org/p/zuul-2020-annual-report is a (very) rough draft for a zuul project update to go in the foundations annual report. I'm going to try and get it into shape this week and if others want to check it out and leave thoughts or edits that would be great | 17:13 |
| *** rpittau is now known as rpittau|afk | 17:14 | |
| *** hamalq_ has joined #zuul | 17:14 | |
| clarkb | the way gerrit does branch is weird, they update all teh things together but they are diverged | 17:15 |
| mhu | at first glance, looks like Non-Interactive Users was replaced by ... Service Users https://gerrit-documentation.storage.googleapis.com/Documentation/3.3.1/access-control.html#non-interactive_users | 17:17 |
| corvus | clarkb: after merging a bugfix to a stable branch, they merge the branch "up" | 17:17 |
| *** hamalq has quit IRC | 17:17 | |
| fungi | mhu: good catch, that's almost certainly it then | 17:18 |
| mhu | fungi, might not be the only breaking change ... and I didn't see anything in the changelogs about this | 17:19 |
| clarkb | https://gerrit-documentation.storage.googleapis.com/Documentation/3.2.6/access-control.html#non-interactive_users interesting that the html tag didn't change :) | 17:20 |
| clarkb | so ya I agree that looks like a likely candidate | 17:20 |
| clarkb | doc/source/examples/playbooks/project.config and doc/source/examples/playbooks/setup.yaml need updating then? | 17:21 |
| mhu | any reference to Non-Interactive Users, yep | 17:23 |
| mhu | Is it in 3.2.6 too though? | 17:23 |
| clarkb | mhu: 3.2.6 uses Non-Interactive users (at least according to my docs link) | 17:24 |
| *** zenkuro has quit IRC | 17:25 | |
| *** jcapitao has quit IRC | 17:27 | |
| mhu | clarkb, I can push a quick fix later if you'd like, but I gotta leave now | 17:27 |
| clarkb | I'm still trying to catch up on a number of things after the holidays but ya I can take a look after lunch probably | 17:29 |
| *** zenkuro has joined #zuul | 17:32 | |
| guillaumec | mhu, clarkb : https://review.opendev.org/c/zuul/zuul/+/766086/3 this is built on top of tutorial rework/new tutorial, main.yaml + Dockerfile aren't required | 17:37 |
| *** nils has quit IRC | 17:44 | |
| corvus | guillaumec: i think we'd like to continue using :latest -- any reason you propose pinning it to 3.3.0 there? | 17:46 |
| corvus | guillaumec: do you think we can take that change and cherry-pick it to master (but leave it set to :latest) ? | 17:47 |
| guillaumec | corvus, there could be, that's what i was also pointing at in quickstart rework patchset 23: https://review.opendev.org/plugins/gitiles/zuul/zuul/+/912340ffe06861dcb61537972d58547e70f645a8 | 17:47 |
| corvus | guillaumec: hrm. you make some good points, but for gerrit specifically, i'm not too worried about it. i think it's good that when gerrit upgrades, if they break something in the quickstart, we find out about it quickly | 17:49 |
| corvus | in other words, the fact that the job is currently failing due to normal gerrit upgrades and that we were notified about it is not a bug -- it's the system working as designed | 17:50 |
| corvus | so i'd like to keep pointing to gerrit :latest and fix the current issue | 17:50 |
| corvus | (if the current issue is difficult to fix, we can temporarily pin to an older version) | 17:50 |
| corvus | but what we've learned over the years is that if we pin to a current working version, we're unlikely to notice that our documentation no longer works with the latest gerrit | 17:51 |
| *** akrpan-pure has joined #zuul | 17:52 | |
| guillaumec | corvus, the pinning in this case was just to test the stream-event comment fix, because at that time "latest" was still 3.2.3, even if the tag "3.3.0" was available. | 17:57 |
| guillaumec | btw 3.3.1 has the intermediate fix for patchset level comment: https://www.gerritcodereview.com/3.3.html#bugfix-releases | 17:57 |
| corvus | guillaumec: gotcha. | 17:57 |
| *** bhavikdbavishi has quit IRC | 18:09 | |
| *** bhavikdbavishi has joined #zuul | 18:10 | |
| fungi | if folks aren't burned out on "virtual conferences" yet, https://events.linuxfoundation.org/cdcon/ might be a good place to reach additional audiences if someone has a zuul talk they're itching to give... cfp is supposedly opening in the next few weeks | 18:38 |
| corvus | ++ | 18:38 |
| fungi | also we've got a zuul section going into the cdf interoperability sig's whitepaper, currently in front of editor teams | 18:39 |
| fungi | there's a lot of "cncf/kubernetes echo chamber" effect in the cdf, so zuul is really not on many folks radar there | 18:41 |
| corvus | fungi: maybe a k8s focused zuul talk for the cdcon would be a good idea then | 18:42 |
| clarkb | my first thought was somethign talking about the image build pipeline work | 18:43 |
| corvus | clarkb: ++ | 18:43 |
| corvus | [biab] | 18:43 |
| *** zenkuro has quit IRC | 18:52 | |
| *** bhavikdbavishi has quit IRC | 18:52 | |
| *** sassyn has joined #zuul | 19:43 | |
| sassyn | hi all | 19:43 |
| sassyn | good morning/afternoon | 19:43 |
| sassyn | How can I limited the number of times job can run? the attempts doesn't seems to be working in my setup | 19:44 |
| sassyn | i have a commit that running a job. the job failed but once it failed Zuul start the job again and again.... | 19:44 |
| clarkb | sassyn: https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.attempts is what you have set to try and change that behavior? | 19:46 |
| sassyn | yep | 19:47 |
| clarkb | if so I wonder if the ansible return code 4 code doesn't use that value. An ansible return code of 4 means that network connectivity to the test node(s) failed | 19:47 |
| clarkb | sassyn: I would check the executor debug logs to see what zuul reports is the exit code of those playbooks | 19:47 |
| sassyn | https://pastebin.com/1cgBj08a | 19:48 |
| clarkb | sassyn: also another piece of useful info would be how many times is it retrying? | 19:49 |
| fungi | sounds like indefinitely | 19:49 |
| sassyn | Seems like I have an issue with my NFS | 19:53 |
| mhu | corvus, re: gerrit support, I *might* be in favor of supporting a pinned version of gerrit. I mean, we stuck with gerrit 2.X on openstack/opendev for quite some time ... My point being, updating gerrit is costly and/or scary | 20:02 |
| corvus | mhu: that's exactly why i don't think we should pin it :) | 20:02 |
| mhu | corvus, fair enough, that works both ways :) | 20:03 |
| corvus | mhu: so far the quickstart job has served us very well by being set to gerrit latest :) | 20:03 |
| mhu | is there a 3.X considered stable or LTS? | 20:03 |
| fungi | not really. all the 3.x minor releases get supported for a while with stable branches, and then they eol those at regular intervals | 20:04 |
| fungi | also please don't use opendev's failure to upgrade gerrit as any indication we were sticking with any sort of "lts" version of gerrit. we just got behind on upgrades and integrated ourselves into a hole we couldn't climb out of without choosing to break a lot of our existing integration in favor of getting on a supported version of gerrit again | 20:05 |
| sassyn | One more thing: I created a repo (name Zuul) that holds all Zuul jobs (trusted project) in my Gerrit server. I also have anther Gerrit Repo call Core which on every commit trigger zuul to run a Job name complication. Once complication is done I want to run a 2 test jobs in parallel. The dependency option give me that out of the box. However, each | 20:06 |
| sassyn | job runs in it's own workspace, which is not what I want. The best if I could set on the core Repo a gate configuration that fire up the complication job, where the compilation job than require to run the 2 other test in parallel. Inherence with post/pre and abstract will also not work here as the job will not run in parallel. Write an ansible | 20:06 |
| sassyn | playbook that use the async will also miss my goal. any idea? . | 20:06 |
| mhu | fungi, I was also speaking from experience with software factory, we've only just looked at supporting gerrit 3, and the migration work was not trivial | 20:06 |
| mhu | my apologies if it sounded like blaming anyone, that was not my intention | 20:08 |
| clarkb | sassyn: you specifically want them to share a workspace? | 20:09 |
| fungi | mhu: to the contrary, i just wanted to make it clear that we didn't choose to run older gerrit so much as we made it hard for ourselves to upgrade | 20:09 |
| sassyn | yes - that will be the best option for me | 20:09 |
| fungi | (also gerrit's rocky transition to notedb didn't help matters, but most of it really was on us) | 20:09 |
| clarkb | sassyn: the onyl way to share a workspace is to run everything in one job. YOu can run different tasks in parallel within a single job using different inventory entries | 20:09 |
| mhu | speaking of notedb, we got a python library called pynotedb that's pretty convenient to provision the admin user in gerrit, I'd suggest giving it a look for zuul-quick-start (cc tristanC ) | 20:11 |
| sassyn | I see, but this is also quite complex. I can't think of a way of easy doing it. When I put Complication job and since I put it this will run Test Job A and Test Job B. seems like the easy easy is to write the playbook like this | 20:13 |
| fungi | sassyn: can you stash the contents of the workspace which your subsequent jobs want to use in some build-unique (but perhaps ephemeral) location at the end of the compilation job and then use zuul_return to communicate the location to teh other builds which run after it? | 20:15 |
| fungi | that's how we do things like multi-stage container image building and testing | 20:15 |
| fungi | jobA creates some artifact and puts it in an accessible location then uses zuul_return to record the location it's at, jobB and jobC which declare jobA in their dependencies reference that location variable to fetch the artifact and use it | 20:16 |
| fungi | we do this so that the image only has to be built once even if it's then exercised in parallel by multiple subsequent jobs | 20:17 |
| *** rlandy is now known as rlandy|drappt | 20:18 | |
| fungi | rather than redundantly building the image in every job which needs it | 20:18 |
| sassyn | this is what I'm doing as well right now | 20:18 |
| sassyn | great mind think a like! | 20:18 |
| fungi | sassyn: however, an alternative approach might be the cache solution avass has been working on | 20:18 |
| sassyn | but I wanted to avoid the multi playbook and make it all in one | 20:19 |
| fungi | depending on what exactly you need to do | 20:19 |
| sassyn | I was thinking to define the complication job has a parent of test job A (where test job A is abstract job and have a post job define), so once I call the compilation job it will run the playbook and later the post run... but if I do the same for test job B I ended with 2 time run the compile job. and putting the compilation has parent of A and | 20:21 |
| sassyn | A as parent of B etc... is to much to manage | 20:21 |
| fungi | so you just need a way to get the resulting compiled files from A into the workspace of B, C, et cetera? | 20:26 |
| *** holser has joined #zuul | 20:39 | |
| sassyn | yes | 20:42 |
| fungi | right, so like i said, what we've usually done is to save whatever we want reused from A somewhere accessible and then use zuul_return to tell B and C where to get it from | 20:44 |
| sassyn | eOK | 20:44 |
| sassyn | Got it! | 20:44 |
| sassyn | thank you! | 20:44 |
| sassyn | Zuul is so cool! | 20:44 |
| sassyn | I wish I was part of the group. | 20:44 |
| fungi | sassyn: by using the software and being in here discussing it with us, you're a part | 20:46 |
| sassyn | :-) | 20:46 |
| sassyn | it is just so impressive work! | 20:46 |
| fungi | on behalf of everyone who's made it happen, thanks! | 20:48 |
| clarkb | corvus: if you are around, I was thinking of adding a mention of zuul being used to test gerrit plugins upstream to the project update on the annual report. Is that being used for all plugins or just those that opt in? what sort fo thing should I be saying about that (if anything at all) ? | 21:03 |
| avass | sassyn, fungi: yeah the caching should work for those kinds things whenever it's ready, you'd need to configure an s3 bucket or implement some other storage option to use it though. | 21:19 |
| corvus | clarkb: i think it's opt-in; we opted a bunch in though | 21:22 |
| clarkb | maybe something along the lines of "Zuul's integration with the Gerrit project continues to get better. Gerrit is now running a Zuul instance that is used to test Gerrit plugins. Plugins can opt into this testing and a number have including X Y Z" ? | 21:23 |
| corvus | clarkb: ++ | 21:25 |
| clarkb | ok I searched reviewedby:Zuul and chose replication, code-owners, and oauth as examples. Thanks | 21:39 |
| *** hasharAway has quit IRC | 21:43 | |
| *** hasharAway has joined #zuul | 21:43 | |
| *** holser has quit IRC | 21:53 | |
| *** holser has joined #zuul | 22:12 | |
| *** ikhan has joined #zuul | 22:22 | |
| *** hasharAway has quit IRC | 22:31 | |
| *** rlandy|drappt is now known as rlandy | 22:46 | |
| *** ikhan has quit IRC | 23:06 | |
| *** ikhan has joined #zuul | 23:55 | |
| akrpan-pure | Quick question about zuul job variables | 23:56 |
| akrpan-pure | I made a base job, which sets some variables in the `vars` block, and abstract is set to true | 23:56 |
| akrpan-pure | Then I made another job with the parent set to the base job, then changed just one variable, but it looks like the ansible role is taking the default from either the role vars/main.yaml or the base job | 23:57 |
| akrpan-pure | I'll debug for sure which it is in a sec, but does anyone see anything immediately wrong with how I'm doing that? | 23:58 |
| clarkb | akrpan-pure: I think the vars in a role may have precedence | 23:58 |
| clarkb | akrpan-pure: you can do roles/defaults/main.yaml instead to lower the precedence | 23:59 |
| akrpan-pure | Ahh I was wondering about that, that's perfect actually | 23:59 |
| akrpan-pure | Lemme give that a try | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!