Tuesday, 2020-04-07

openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add a zuul-ensure-passwords role  https://review.opendev.org/71788000:06
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add a zuul-ensure-passwords role  https://review.opendev.org/71788000:10
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Add bionic-plain non-voting testing  https://review.opendev.org/71765500:14
openstackgerritIan Wienand proposed zuul/zuul-jobs master: test jobs: fixup autogeneration header  https://review.opendev.org/71765600:14
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763900:14
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add zuul-registry deployment  https://review.opendev.org/71065000:14
*** rlandy|afk is now known as rlandy00:22
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Add bionic-plain non-voting testing  https://review.opendev.org/71765500:25
openstackgerritIan Wienand proposed zuul/zuul-jobs master: test jobs: fixup autogeneration header  https://review.opendev.org/71765600:25
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788200:25
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763900:27
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766300:27
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765700:28
tristanCcorvus: it seems like we are still missing https://review.opendev.org/708860 to get the zuul-operator image actually published00:29
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Add bionic-plain non-voting testing  https://review.opendev.org/71765500:35
openstackgerritClark Boylan proposed zuul/zuul-jobs master: test jobs: fixup autogeneration header  https://review.opendev.org/71765600:35
openstackgerritClark Boylan proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788200:35
openstackgerritClark Boylan proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763900:37
openstackgerritClark Boylan proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766300:38
openstackgerritClark Boylan proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765700:39
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Add bionic-plain non-voting testing  https://review.opendev.org/71765500:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: test jobs: fixup autogeneration header  https://review.opendev.org/71765600:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788200:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763900:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766300:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765700:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788201:08
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763901:08
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766301:08
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765701:08
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788201:15
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763901:15
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766301:15
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765701:15
*** swest has quit IRC01:28
*** zxiiro has quit IRC01:39
*** swest has joined #zuul01:43
*** cdearborn has quit IRC01:43
*** Goneri has quit IRC02:00
*** ysandeep|away is now known as ysandeep|rover02:02
*** igordc has joined #zuul02:33
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788202:59
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763902:59
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766303:00
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765703:00
*** ysandeep|rover is now known as ysandeep|afk03:13
*** igordc has quit IRC03:16
*** bhavikdbavishi has joined #zuul03:20
*** bhavikdbavishi1 has joined #zuul03:22
*** bhavikdbavishi has quit IRC03:24
*** bhavikdbavishi1 is now known as bhavikdbavishi03:24
*** bhavikdbavishi has quit IRC03:36
*** rlandy has quit IRC03:37
*** bhavikdbavishi has joined #zuul03:38
*** bhavikdbavishi has quit IRC03:45
*** bhavikdbavishi has joined #zuul04:08
*** ysandeep|afk is now known as ysandeep|rover04:18
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763904:21
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788204:21
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766304:21
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765704:22
*** evrardjp has quit IRC04:36
*** evrardjp has joined #zuul04:37
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: Update registry test to use ensure-podman and ensure-docker  https://review.opendev.org/71675204:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763904:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: fetch-zuul-cloner: prefer venv to virtualenv  https://review.opendev.org/71788204:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766304:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765704:53
openstackgerritMerged zuul/zuul-jobs master: Update registry test to use ensure-podman and ensure-docker  https://review.opendev.org/71675205:14
*** saneax has joined #zuul05:20
*** y2kenny has quit IRC05:32
*** dpawlik has joined #zuul06:30
*** avass has quit IRC06:53
*** avass has joined #zuul06:53
*** gtema has joined #zuul06:55
*** rpittau|afk is now known as rpittau06:56
*** pleia2 has quit IRC07:02
openstackgerritTobias Henkel proposed zuul/zuul master: Retry nodeenv creation  https://review.opendev.org/71782007:04
*** pleia2 has joined #zuul07:04
*** bhavikdbavishi has quit IRC07:11
*** sgw has quit IRC07:11
*** jcapitao has joined #zuul07:18
*** tosky has joined #zuul07:24
openstackgerritTobias Henkel proposed zuul/zuul master: Don't try to stream from winrm connections  https://review.opendev.org/71797307:38
*** ysandeep|rover is now known as ysandeep|lunch07:44
tobiashtristanC: I've added a question on https://review.opendev.org/70886008:08
openstackgerritMerged zuul/zuul-jobs master: docs: fix a typo in `run-test-command`  https://review.opendev.org/71771308:15
*** bhavikdbavishi has joined #zuul08:33
*** ysandeep|lunch is now known as ysandeep|rover08:44
*** sshnaidm|afk is now known as sshnaidm08:57
openstackgerritMerged zuul/zuul master: Render buildset progress bar correctly  https://review.opendev.org/71687809:08
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Support ssh-enabled windows hosts in add-build-sshkey  https://review.opendev.org/65371209:12
zbrtristanC: tobiash: can you please recheck https://review.opendev.org/#/c/690057/ -- i really need to be able to upgrade tox09:27
zbron ansible zuul instance there is an outdated version pre-installed, and this would enable me the bump it from consuming jobs.09:28
* tobias-urdin just passed 10k zuul builds since moving away from jenkins10:01
*** rpittau is now known as rpittau|bbl10:25
tobiashtobias-urdin: congratulations :)10:59
*** bhavikdbavishi has quit IRC11:06
*** bhavikdbavishi has joined #zuul11:11
tobiashzbr: you already got a comment11:13
tobiashhowever I don't understand it11:14
zbryep, addressing it. minor stuff11:14
tobiashk11:14
zbrmaybe someone knows how to avoid repeating the same uninstall task 3 times in the file11:14
*** jcapitao is now known as jcapitao_lunch11:19
*** gtema has quit IRC11:22
openstackgerritFabien Boucher proposed zuul/zuul master: pagure: Improve CI status flag handling  https://review.opendev.org/71806311:22
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005711:24
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add zuul-operator-upload-image job  https://review.opendev.org/70886011:27
*** ysandeep|rover is now known as ysandeep|afk11:29
*** hashar has joined #zuul11:31
*** hashar has quit IRC11:42
tristanCzbr: why not using include_tasks?11:48
zbrtristanC: not a big fun of them, especially for a single task.11:48
zbrbut i may have to, i am still unsure if looping with become works or not11:48
tristanCzbr: the `Verify tox is not installed` task is also repeated11:49
zbrnot fully, the last verification is quite different11:50
tristanCzbr: i find the yaml anchor and merge operator rather confusing11:50
zbrtristanC: nopb, i can avoid it.11:50
zbrthere is also another way of doing it, adding remove support to the role itself.11:51
zbri could use tasks_from: remove.yaml and keep the removal code inside the role itself, instead of having it part of the test playbook.11:52
zbrsome could find it useful11:52
tristanCzbr: that sounds like a bad idea. and how would you test that without introducing more repetition?11:52
zbri would just run removal, and assume it worked.11:53
zbrtristanC: if I add a removal tasks file, only for the test playbook, where should I put it? how to name it?11:55
zbrlike test-playbooks//tasks/tox-remove.yaml ?11:55
tristanCzbr: i meant, adding a remove task to an install role just to avoid the repetition of a task in the zuul-test playbook sounds odd11:56
*** ysandeep|afk is now known as ysandeep|rover11:56
zbri do have an use-case: if you want to enforce removal of tox somewhere. but I will do the local implementation for the moment and not touch the role11:57
*** sshnaidm is now known as sshnaidm|afk11:58
tristanCzbr: if we need install-* role to be able to uninstall, other than for install-* testing purpose, then that's another story.11:59
zbrinstall is no more, now we have ensure11:59
tristanCs/install-/ensure-/12:00
zbrand i can see a (low) use case for "ensure foo is missing" ;)12:00
tristanCzbr: the semantic looks odd, why would you use an ensure-foo role to remove foo?12:02
zbrtristanC: it is a common pattern on configuration management, that is why ansible does have only one package module and it does not have a "install-package" and "remove-package" module.12:03
zbrstate determines the action, defaults to present.12:03
zbranyway, i am not going to propose that, at least not now.12:03
*** gtema has joined #zuul12:04
tristanCzbr: in ansible module that make sense as the semantic is `package.state = <absent|present>` . Using `package` doesn't imply the state to be present. In zuul-jobs we have `ensure-foo` which already imply that foo state will be present.12:05
*** armstrongs has joined #zuul12:06
*** rpittau|bbl is now known as rpittau12:06
openstackgerritFabien Boucher proposed zuul/zuul master: pagure: Improve CI status flag handling  https://review.opendev.org/71806312:08
*** armstrongs26 has joined #zuul12:11
zbrtristanC: https://opendev.org/zuul/zuul-jobs/src/branch/master/test-playbooks/ensure-tox.yaml#L34-L57 -- this seems like a bug, running removing twice.12:13
zbri see no reason to run twice12:13
armstrongs26hey have a question. We have a common framework untrusted repo that is defined in around 16 tenants. It is used a dependency in all these tenants. We noticed when we commit to master to change this dependant project it causes a queue on the zuul scheduler. Is there a way of setting this up to avoid the queue delay?12:14
*** armstrongs has quit IRC12:14
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005712:18
*** armstrongs has joined #zuul12:19
*** rfolco has joined #zuul12:20
*** rlandy has joined #zuul12:24
*** jcapitao_lunch is now known as jcapitao12:31
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: Enables whitelisting and configuring callbacks  https://review.opendev.org/71726012:31
*** hashar has joined #zuul12:31
*** armstrongs has quit IRC12:32
*** igordc has joined #zuul12:34
mnaserarmstrongs26: are you saying that it gets queued in all of the tenants?12:52
openstackgerritGraham Hayes proposed zuul/nodepool master: Implement an Azure driver  https://review.opendev.org/55443213:05
*** bhavikdbavishi has quit IRC13:07
armstrongs26mnaser: we see the scheduler pause scheduling jobs for a couple of minutes and the build queue has a big number of management events. When it goes back down jobs start queuing again13:07
armstrongs26when i say pause i mean new requests queue and wait and don't get scheduled by nodepool13:08
*** sgw has joined #zuul13:12
openstackgerritAlbin Vass proposed zuul/zuul master: Rename getAnsiblePluginDir to getZuulAnsiblePluginDir  https://review.opendev.org/71810213:18
openstackgerritAlbin Vass proposed zuul/zuul master: Rename getAnsiblePluginDir to getZuulAnsiblePluginDir  https://review.opendev.org/71810213:18
*** Goneri has joined #zuul13:23
*** sshnaidm|afk is now known as sshnaidm13:27
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: Enables whitelisting and configuring callbacks  https://review.opendev.org/71726013:28
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: Enables whitelisting and configuring callbacks  https://review.opendev.org/71726013:29
openstackgerritAlbin Vass proposed zuul/zuul master: Rename getAnsiblePluginDir to getZuulAnsiblePluginDir  https://review.opendev.org/71810213:33
openstackgerritAlbin Vass proposed zuul/zuul master: Rename getAnsibleDir to getZuulAnsibleDir  https://review.opendev.org/71810213:35
mnaserin cool news, cheroot and cherrypy is getting testing via zuul, though no gating yet13:36
*** gtema has quit IRC13:45
openstackgerritTobias Henkel proposed zuul/zuul master: Log missing required status checks  https://review.opendev.org/71811413:47
mordredmnaser: \o/13:48
*** harrymichal has joined #zuul13:50
tobiashzbr: I wonder if installing tox into a venv and linking it into PATH would be easier than this uninstall dance13:51
tobiasharmstrongs26: a merge to master requires a tenant reconfiguration in all tenants that use this repo13:54
tobiasharmstrongs26: currently there is no way around this but with the ha scheduler work we'll be switching from a single event queue to a distributed multi-worker event queue13:55
tobiasharmstrongs26: this won't then block zuul globally in this case13:55
armstrongs26was just checking to see if there is any better way for configuring common projects. Thanks for the info. Looking forward to the distributed scheduler :)13:57
*** avass has quit IRC14:08
*** avass has joined #zuul14:10
*** gtema has joined #zuul14:12
openstackgerritMerged zuul/zuul-jobs master: Add bionic-plain non-voting testing  https://review.opendev.org/71765514:14
*** gtema has quit IRC14:25
openstackgerritFabien Boucher proposed zuul/zuul master: pagure: Make use of the new project webhook/token endpoint  https://review.opendev.org/71773214:27
openstackgerritAlbin Vass proposed zuul/zuul master: Use ensure-* roles  https://review.opendev.org/71812414:27
zbrmordred: clarkb: can we merge https://review.opendev.org/#/c/716578/ ? (ensure-podman)14:32
*** ysandeep|rover is now known as ysandeep|away14:33
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005714:34
*** harrymichal has quit IRC14:35
*** bhavikdbavishi has joined #zuul14:44
*** bhavikdbavishi1 has joined #zuul14:46
*** bhavikdbavishi has quit IRC14:48
*** bhavikdbavishi1 is now known as bhavikdbavishi14:48
*** bhavikdbavishi has quit IRC15:03
*** sshnaidm is now known as sshnaidm|afk15:07
mnasermordred, corvus: so fetch-javascript-output posts an artifact called "Site preview" -- but the zuul-preview code seems to (probably) need an artifact name without a space?15:09
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005715:11
*** bhavikdbavishi has joined #zuul15:11
corvusmnaser: yeah, it's got to be something valid for dns, so only letters, numbers, '-'  in the name15:14
corvusmnaser: maybe we should change zuul-preview to use the 'type' metadata entry instead of the name15:15
corvusmnaser: that's what we did with the artifact fetching roles15:15
*** sshnaidm|afk is now known as sshnaid15:27
*** sshnaid is now known as sshnaidm15:27
mnasercorvus: that seems reasonable, and as much as i dont want to complicate things, we need to figure out if there is a possibility of multiple previews i guess15:29
openstackgerritGraham Hayes proposed zuul/nodepool master: Implement an Azure driver  https://review.opendev.org/55443215:30
corvusmnaser: here's the previous use of this: http://zuul.opendev.org/t/openstack/build/167715b656ee4504baa940c5bd9f382115:30
corvusmnaser: we just named the artifact "site"15:30
mnasercorvus: yeah, i guess i'll have to template it out inside here -- https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/fetch-javascript-output/tasks/main.yaml15:31
mnaseras i'm using the zuul built-in build-javascript-content job15:33
openstackgerritJames E. Blair proposed zuul/zuul-preview master: Look up artifacts by metadata.type rather than name  https://review.opendev.org/71815115:35
corvusmnaser: ^ if we want to go that way15:35
mnasercorvus: that looks good to me, to get a head start, ill push a change to zuul/zuul-jobs :)15:36
corvusmnaser: yes, we'll need to update https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/fetch-javascript-output/tasks/main.yaml to either change the name or add the metadata.type field; then we'll want to return a second artifact on the build job.  that shouldn't be in zuul-jobs, since it's going to have opendev site-specific information.15:36
tobiashcorvus: we noticed that our executors get a significant performance benefit when we do a regular (e.g. weekly cache wipe). What do you think about a builtin mechanism to facilitate this in an easy way?15:38
tobiashour current approach is pause a bunch of executors, wait intil there is no starting build, wipe the cache and unpause again15:38
corvusmnaser: (we need one artifact that is the url on the log server, and we'll want a second artifact that's the link to the preview server.  we'll have to figure out the best way to name those, since they are both preview links)15:38
corvustobiash: we see the same improvement whenever we clean caches; it's all the throwaway refs.  i think we should automate it; we probably don't have to delete the whole repo, we can probably figure out what refs to delete and then run a gc15:39
tobiashdo they accumulate?15:40
corvustobiash: if we do it that way, it can probably be very quick and maybe very frequent (maybe run a process every few hours that deletes refs older than 24 hours)15:40
corvustobiash: i think so, but i haven't looked lately15:41
corvustobiash: hrm, maybe we don't store refs anymore15:42
corvustobiash: if that's the case, i wonder what it is...15:42
corvustobiash: because git should automatically run gc15:42
tobiashcorvus: at least for github we seem to accumulate local branches that don't have matching remote refs anymore15:43
corvustobiash: ah, good point.  we don't see that, but that should be easy to automate too15:44
tobiashcorvus: gc only prunes objects older than two weeks by default so on a busy system that might still leave a lot of unneeded objects around15:44
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005715:45
tobiashcorvus: so I guess we need to manually run git gc with a custom prune period15:47
tobiashand solve the branch leak for github15:47
clarkbzbr: looking now15:47
zbrthanks. i am still working on ensure-tox one, seems to be quite hard to eradicate tox from ubuntu hosts :D15:48
clarkbzbr: I've approved the change but elft a note on it if you want to address that in a followup15:49
clarkb(its a minor thing)15:49
tobiashcorvus, tristanC: hrm, we just have been hit by NoneType has no loading_errors (https://review.opendev.org/676947) as well15:53
openstackgerritMerged zuul/zuul master: Add yappi and objgraph to container image  https://review.opendev.org/71760215:56
tristanCcorvus: tobiash: this also seems relevant: https://review.opendev.org/#/c/712544/1 , not sure what to do about it though15:56
openstackgerritTobias Henkel proposed zuul/zuul master: WIP: Implement graceful termination for the executor  https://review.opendev.org/71815715:57
mnasercorvus: actually, maybe a good time to ask, i was a bit confused as to what the point of uploading to log server vs uploading to "preview" server?  is this similar to a upload/promote type of behaviour?15:57
tristanChaving Optional[] type annotation would help understand and enforce how missing layout are handled15:57
mordredmnaser: the preview server is just a proxy service that allows serving a log server location from a root url - so for things like the gatsby build that just don't work if you try to suburl them with an arbitrary suburls15:59
mnaserOH, okay, i get it15:59
mnaserso one artifact is going to be "contents" and the other is "view website"16:00
mnaseri was thinking of using success-url and not using an artifact16:00
tobiashtristanC: that looks like the same bugfix :)16:00
*** dpawlik has quit IRC16:00
tobiashwe had 8 hits of that exception (and reports) in the last 7 days, so seems to be a very rare corner case or some sort of race16:00
corvustobiash, tristanC: yeah, there is a bug somewhere, but i don't think anyone has a theory for what it is; it needs more investigation/debugging.  the bug is not fixed by that patch, that patch would only mask it.16:01
*** bhavikdbavishi has quit IRC16:01
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add zuul-registry deployment  https://review.opendev.org/71065016:01
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: test: refactor run tasks to include file  https://review.opendev.org/71815816:01
tobiashI'm aware of that, digging in the logs now16:01
corvusi guess that was mostly for tristanC then :)16:02
openstackgerritMerged zuul/zuul-jobs master: Add support for RedHat platforms on ensure-podman  https://review.opendev.org/71657816:03
corvusmnaser: i think we're trying to stop using success-urls, since if we use them, there's no way to actually get to the logs.  so i think it should be a second artifact16:03
openstackgerritTobias Henkel proposed zuul/zuul master: Annotate dynamic layout creation  https://review.opendev.org/71816016:03
*** sshnaidm is now known as sshnaidm|afk16:03
mnasercorvus: fair enough, i think an artifact of type zuul-website is probably what we'd use, but yeah, there's some trickery around finding the right word16:04
mnaserbut that's an opendev-ism, not a zuul-ism, we can probably stick with 'site' as type16:04
tobiashcorvus: I just got the info from the user that depends-on and a yaml syntax error are involved16:05
corvustobiash: i'm not having any luck making opendev repos any smaller with git gc; so maybe the main outstanding issue is the extra branches you see due to the github workflow?16:07
corvusmaybe everything else is automatic now16:08
*** rpittau is now known as rpittau|afk16:08
tobiashcorvus: probably, but maybe in gerrit case the size is not the main factor but the number of objects not in a pack16:08
corvustobiash: yeah, i haven't tried more extensive repacks16:09
tobiashside note, don't try --aggressive ;)16:09
tobiashit easily ooms16:09
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Increase scheduler wait to timeout  https://review.opendev.org/71816216:10
tristanCHere is a simple review to improve zuul-operator test reliability ^16:11
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: fetch-javascript-output: add metadata.type  https://review.opendev.org/71816316:11
mnaser^ so that should get us the type16:12
mnaserso once https://review.opendev.org/#/c/718151/ lands, we'll be able to see the preview of the zuul gatsby-ified website16:13
openstackgerritMerged zuul/zuul master: tox: rename pep8 to linters  https://review.opendev.org/70363516:15
clarkbmnaser: mordred: that is a backward incompatbile change right? any concern with that?16:20
clarkbwe could continue to fallback to name and be backward compatbile16:20
mordredclarkb: I mean - proxy isn't in use because of the security issue that was just fixed16:22
mordredso - I think it's fairly safe to just do it16:22
mordredI mean - I _suppose_ someone other than us could be using it who cares less about open proxies16:23
openstackgerritMerged zuul/zuul master: tox: do not install bindep for linters  https://review.opendev.org/70363616:24
tobiashcorvus: also I found out that the repo of the parent item has a .zuul.yaml as well as a zuul.d16:26
tobiashbut that might be unrelated16:29
fungitobiash: according to https://github.com/ether/etherpad-lite/issues/3781 the zuul.d would be used and .zuul.yaml ignored16:32
tobiashfungi: that is correct16:32
fungiunless you actually meant .zuul.yaml and .zuul.d in which case .zuul.yaml is read and .zuul.d ignored16:32
tobiashjust found that warning in the context of the issue16:32
fungier, wrong link from my paste buffer, sorry16:33
fungihttps://zuul-ci.org/docs/zuul/reference/config.html#configuration-loading16:33
* fungi is doing too many things at once16:33
tobiashfungi: code and docs are in sync for that :)16:34
openstackgerritMerged zuul/zuul-jobs master: fetch-javascript-output: add metadata.type  https://review.opendev.org/71816316:36
*** evrardjp has quit IRC16:36
*** evrardjp has joined #zuul16:37
*** harrymichal has joined #zuul16:37
*** zxiiro has joined #zuul16:39
corvusclarkb: i think i'll approve 151 under the assumption it has no users16:42
corvusclarkb: if someone yells, it's certainly possible to support both, but i think it's desirable to be clear and only support one16:42
clarkbok16:42
openstackgerritMerged zuul/nodepool master: Use ensure-* roles  https://review.opendev.org/71782216:52
openstackgerritMerged zuul/zuul-preview master: Look up artifacts by metadata.type rather than name  https://review.opendev.org/71815116:59
openstackgerritMerged zuul/zuul master: Use ensure-* roles  https://review.opendev.org/71812417:10
*** harrymichal has quit IRC17:11
*** harrymichal has joined #zuul17:11
*** harrymichal has quit IRC17:40
*** armstrongs26 has quit IRC17:45
clarkbfungi: provides and requires are oriented around artifacts, they don't really care about projects or branches as far as I know17:50
clarkbfungi: a job will say I provide this artifact foo, then if you require that artifact foo any jobs providing it will run before you run17:51
fungiclarkb: yeah, so how would you go about ensuring that the artifact for the build of that job ahead of the current change completed?17:54
clarkbfungi: zuul does that for you17:55
fungiassuming they're both for the same project17:55
fungiso your current buildset has a job which provides that, but by virtue of being for the same project+branch the change ahead of that one in the queue also provides that from the build of the same job in its buildset17:55
fungiand it sounded like what he was looking for was a way to be sure that the artifact provided by the build in the change ahead of the current one in the queue had completed17:56
clarkbyup17:56
fungiso... how does zuul differentiate then?17:56
clarkbthats how the docker image jobs are intended to work aiui and they rely on provides, requires to do that17:56
clarkbfungi: because provides and requires are between buildsets and dependencies are within a buildset17:57
clarkbso you've got two constructs and you have to configure both17:57
clarkbin the docker image case you both provide and requires the same artifact17:57
clarkbthat way you can wait for parent change to complete that build then update the image the parent provided17:58
clarkbthen in the buildset you depend on your job to build that image in order to consume it for testing17:58
fungiso change 1 is approved and enqueued for project foo and runs a job which declares that it provides artifact bar. change 2 for foo is approved and enqueued into the same dependent pipeline and also runs the same job which claims to provide artifact bar. a second job for change 2 requires artifact bar from change 1's buildset... how?17:58
*** jcapitao has quit IRC17:59
clarkbthe job providing artifact bar in change 2 doesn't start until the one in change 1 completes. This is configured via the "requires" directive. This allows change 2's artifact production to incorporate what change 1 has done18:00
clarkbthe second job in change 2 does not directly depend on the artifact in change 1, instead it depends on the artifact produced by change 2, but if that artifact production requires the artifact from change 1  you get the ordering right18:01
fungii see, so you can chain then by saying don't start the job which produces artifact bar in this change until all the buildsets enqueued ahead have also already produced artifact bar?18:01
clarkbyes18:01
fungiand you express that by saying this job provides bar and requires bar (on the same job)? or is it implicit that zuul won't run two builds in different buildsets concurrently if they both claim to provide the same artifact?18:03
clarkbyou have to provides and requires on the same job pretty sure this is what the docker image builds do18:03
fungiokay18:03
*** harrymichal has joined #zuul18:06
*** bhavikdbavishi has joined #zuul18:07
mordredclarkb, fungi : almost but not quite ... you would not have a single job providing and requiring the same artifact18:09
*** hashar has quit IRC18:10
mordredfungi: in your example above, the second job in change 2 that requires artifact bar isn't going to be looking for bar from change 1's buildset, it's going to be looking for it from change 2's buildset, since change 2 is building it and providing it18:11
mordredhowever, if you uploaded change 2 and it _didn't_ trigger artifact bar to be built, then the second job that requires artifact bar would get the artifact from change 1's build rather than change 2's18:12
fungii'll admit i was reading between the lines for the question in the ml, but it sounded like the desire was to be able to compare the artifact built in one change against the same artifact enqueued ahead of it, to see how they differ18:12
*** bhavikdbavishi1 has joined #zuul18:12
*** bhavikdbavishi has quit IRC18:12
*** bhavikdbavishi1 is now known as bhavikdbavishi18:12
fungiso i compile foo.c in a job on change 1 and produce an artifact, i want to compile foo.c from change 2 and compare it against the result from change 1, but to do that i have to be sure that change 1's job has already completed to the point of producing that artifact18:13
mordredI do not believe the system is built with that use-case in mind. it's built to get the best speculative future artifact from the stack of dependent changes18:13
mordredhrm18:13
clarkbmordred: I think both providing and requires on a single job would address that18:13
mordredok - that makes more sense to my brain18:13
mordredand yes - I think it's at least worth a try of providing and requiring there18:14
mordredmy brain hurts now18:14
fungii suppose the build for change 2 could start whenever but just busywait until it can find an artifact produced by the same job running for change 118:14
fungithat could make calculating job timeouts tough though18:15
mordredno - I think the simul provide/require is the trick18:15
mordredweird as it is for my brain18:16
mordredthen the job content itself will still have to deal with "was there a job ahead of me that built an artifact that's in the list, grab it, else grab the published artifact"18:16
clarkbyup18:17
mordredalthough if it's docker images the base jobs will do that for them18:17
fungiso that would effectively create an implicit queue-specific semaphore for that job so that the builds for all changes ran that job one at a time in serial order18:17
fungineat18:17
mordred(they'd still need to have custom content to pull the sha of the image in question at the start of the job before doig their build)18:17
*** cdearborn has joined #zuul18:19
openstackgerritMonty Taylor proposed zuul/zuul-preview master: Check to make sure artifact has a url  https://review.opendev.org/71818618:25
openstackgerritMonty Taylor proposed zuul/zuul-preview master: Check to make sure artifact has a url  https://review.opendev.org/71818618:28
*** harrymichal has quit IRC18:37
*** harrymichal_ has joined #zuul18:37
*** harrymichal_ has quit IRC18:50
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005719:07
*** y2kenny has joined #zuul19:14
*** saneax has quit IRC19:15
y2kennyfor job.files, is there a way to specify the project if multiple project uses the same job?19:17
fungiso one set of files if it's project a, different set of files for project b? i think you can stick files matchers in a job variant in the specific project-pipeline19:18
y2kennyok19:18
openstackgerritMerged zuul/zuul-preview master: Check to make sure artifact has a url  https://review.opendev.org/71818619:21
*** bhavikdbavishi has quit IRC19:27
*** harrymichal has joined #zuul19:29
zbrclarkb: if you can have a look at https://review.opendev.org/#/c/690057/ and tell me why it does not work on ubuntu it would be great, i am either too tired to duumb to see what is wrong.20:01
zbrapparently tox refuses to be let itself removed :p20:02
clarkbzbr: it looks like you remove it via python2 but its still installed via python320:03
clarkbnote the deprecation warnings on the uninstall but the file path on the error20:04
zbrbut the command -v lines are supposed to remove it from all pythons20:04
openstackgerritTobias Henkel proposed zuul/zuul master: Retry nodeenv creation  https://review.opendev.org/71782020:04
zbrunless some "pip" commands are really missing from path. maybe i should try using python -m to call pip instead.20:04
zbri got the same impression that that command | xargs finds only pip, but my local tests worked fine.20:05
fungiyes, looking at the bionic job it's reporting a path of /usr/local/lib/python3.6/dist-packages/tox/__init__.py which means it was installed with pip for python3.6 (the default python on the platform)20:05
zbron the same platforms.20:05
zbrfungi: in that case the package absent line should have already being removed it20:05
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: Enables whitelisting and configuring callbacks  https://review.opendev.org/71726020:06
fungizbr: which package absent line?20:10
fungithis is not a distro package of tox, it's pip-installed tox using the distro's python3.6 interpreter (and some unknown installation of pip)20:10
fungithe "Remove tox package with pip(s) - root" task does: command -v pip pip2 pip3 | xargs -I{} sh -xc "{} uninstall -y tox || true"20:13
fungiwhich seems to only wind up running /usr/local/bin/pip20:14
zbrthis means that the other pips are not that in path, i will try tomorrow to call pip as a module.20:18
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: Enables whitelisting and configuring callbacks  https://review.opendev.org/71726020:22
*** tjgresha has joined #zuul20:31
*** tjgresha has quit IRC20:31
*** hashar has joined #zuul20:38
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766320:38
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765720:38
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-pip: export ensure_pip_virtualenv_command  https://review.opendev.org/71822420:39
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] use ensure-pip in fetch-subunit-output test  https://review.opendev.org/71822520:39
*** igordc has quit IRC20:47
*** zxiiro has quit IRC20:47
*** igordc has joined #zuul20:48
*** rlandy is now known as rlandy|biab21:10
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure pip role  https://review.opendev.org/71763921:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-pip: export ensure_pip_virtualenv_command  https://review.opendev.org/71822421:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] fetch-zuul-cloner: use ensure-pip  https://review.opendev.org/71788221:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] use ensure-pip in fetch-subunit-output test  https://review.opendev.org/71822521:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766321:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765721:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] fetch-zuul-cloner: use ensure-pip  https://review.opendev.org/71788221:45
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] use ensure-pip in fetch-subunit-output test  https://review.opendev.org/71822521:45
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: preinstall pip  https://review.opendev.org/71766321:45
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765721:45
*** harrymichal has quit IRC21:52
*** rlandy|biab is now known as rlandy21:54
openstackgerritMerged zuul/nodepool master: Update tests for node-attributes  https://review.opendev.org/71473821:55
openstackgerritMerged zuul/nodepool master: Support image uploads in 'info' CLI command  https://review.opendev.org/71277522:02
openstackgerritMerged zuul/nodepool master: Fix shutdown ordering  https://review.opendev.org/71713422:02
openstackgerritMerged zuul/nodepool master: Add GCE driver tests  https://review.opendev.org/71713322:02
openstackgerritMerged zuul/zuul master: Annotate dynamic layout creation  https://review.opendev.org/71816022:13
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-tox: use ensure-pip role  https://review.opendev.org/71766322:35
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Update Fedora to 31  https://review.opendev.org/71765722:35
*** saneax has joined #zuul22:56
*** hashar has quit IRC22:56
jktwow, this is pretty strict, An unhandled exception occurred while running the lookup plugin 'env'. Error was a <class 'ansible.errors.AnsibleError'>, original message: Use of lookup modules that perform local actions on the executor is forbidden.23:11
fungijkt: we've whitelisted them as folks have done sufficient analysis to make sure they can't open write access to arbitrary files or enable arbitrary code execution23:14
jktyup, I'm on a pretty oldish Zuul23:14
fungiso it's possible that one's safe and just nobody's audited its implementation yet23:14
jktbesides, if it's really on the executor, then I should not use it anyway23:15
fungiright, that's the only place we blacklist them23:15
jkta few more tries and I might have a working setup for coverage diffing23:15
jkta few questions -- can I somehow return FAILURE instead of a FAILURE from a post_run playbook?23:16
fungii don't understand the question23:16
jktcontext is https://gerrit.cesnet.cz/c/ci/zuul-jobs-cesnet/+/2416/1023:17
fungii read that as you want a post_run playbook to return FAILURE instead of FAILURE, so i'm surely misunderstanding23:17
jktdoh23:17
jktI would like a post_run playbook to return FAILURE instead of POST_FAILURE that it can return now23:17
fungiahh, interesting, i'm not aware of a way, no... usually the idea is that you put things you want to represent actual failure conditions when they don't work into the run phase23:18
fungiso POST_FAILURE is how zuul indicates that a failure condition was found in a post phase playbook23:19
fungias opposed to during the run phase23:19
fungiand then during the pre phase, errors are retried until RETRY_LIMIT condition is returned23:19
fungiso the phases are mostly about how the system behaves when a playbook doesn't work23:20
jktI can do that, but it means that I cannot "just" inherit from my "main build job" in the "build prev version + compute coverage diff" job definition23:21
jktno worries, it's just very slightly inconvenient23:21
jktsecond Q, can I somehow set job.success_url as a relative suffix from my job?23:22
jktI would like to keep on whatever setup is already in place for uplaoding logs and setting that absolute URL in log_url23:22
jktand then, if my job made it as far as to the very end, which means that there's that coverage-diff.html in my job dir, only then append a relative suffix to the URL23:22
jktif not, as the patch above is doing, then the user might click to a link which doesn't work, but once again, this should be relatively rare23:23
clarkbyou might want ot add it as an artifact instead?23:23
clarkbthen you get a nice link to it in the dashboard23:23
fungiyeah, success_url and friends are somewhat inflexible in that you only get one23:24
jktclarkb: I can do that, but given that this job cannot really produce anything extra apart from this HTML, I would like to save that extra click23:24
fungiso if you set it to anything special then it makes it hard to get to the build result details23:24
fungiwell, i mean, the job likely also produces a console log, job metadata, et cetera23:25
fungiso if the job fails, getting to that information to debug becomes a fair bit harder23:25
jktyeah23:25
*** tosky has quit IRC23:26
clarkbI'm not sure how to set up relative urls fwiw23:27
clarkbbut I do recall we switched away from that mechanism entirely once the dasboard could show builds23:27
fungithough i suppose if it's just success_url then maybe that's less of a concern as long as the job doesn't do something it's not supposed to and succeed anyway23:27
jktyeah, mine instance of Zuul is on 3.8, no fancy dashboards there23:28
fungithere is some basic templating for the url parameters, refreshing my recollection from docs23:28
fungihrm, we actually no longer document it at all that i can find23:30
clarkbfungi: ya I think the dashboard updates effectively broke the old system23:31
clarkbso it was an either or23:31
fungiwell, we don't seem to have documented it at all for v323:32
fungilooking back through git history23:32
fungiit looks like it's still implemented in QueueItem.formatProvisionalJobResult() and there's one unit test of it23:33
fungibut yeah, basically an undocumented feature and seems to have been so at least since v323:34
fungiit's definitely not something we generally encourage relying on because of the reasons mentioned above. it looks like it can template in anything formatUrlPattern() supports23:36
fungiwhich is basically the set of: change, pipeline, tenant, buildset, job, build23:36
jktnice, but I think that won't help me23:37
fungieverything else is statically defined in the value set in the config, so at best also subject to yaml's templating features, which are limited at best23:38
fungiand interpreted at configuration load time23:38
jktbtw, funny intermezzo #123, this time related to our Swift configuration -- it always sends out "content-encoding: deflate", so Ansible's get_url won't retrieve it properly, and I think I have to call out to `curl --compress`23:39
fungiwe had to take extra care to only upload compressed files if we want them downloaded in a compressed format (so stuff like .tar.gz files), and otherwise upload uncompressed and rely on swift's built-in compression for serving up things we want retried plain23:49
fungis/retried/retrieved/23:49
jktfungi: well, I'm unsure if it's a bug on my side or somewhere else, but `wget https://object-store.cloud.muni.cz/swift/v1/ci-logs-CzechLight-internal/14/2414/19/check/f29-gcc/eb5f0f5/coverage.xml` doesn't return an actual XML for me23:55
clarkbjkt: are you using the zuul-jobs swift upload role?23:56
clarkbbasically it was uploading a compressed verson of a file then also setting the encoding type to be compressed. At the time I THink the idea was that everything was compressed and the values agreed with each other. Problem is you run into that behavioryou see23:57
clarkbinstead what we can do is upload compressed (and it is stored compressed) but set the encoding type to uncompressed and swift seems to figure it out at the web server level23:58
clarkblet me see ifI can find the change23:58
jktclarkb: yes; mine is at https://gerrit.cesnet.cz/plugins/gitiles/ci/zuul-jobs/+/2da7fecff5d1650b8767a7d294deeff3e6fc54bd%5E%21/ which I hope is a cherry-pick of mine c31cd37164ae3e24c70a9de078d8f637386ce8ec upstream23:58
clarkb0e23325a12651756faf5b99dda308a93788bd9db is the commit that fixes it23:59
clarkbthough there were a couple followups after that the cleaned up some edge case stuff23:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!