Monday, 2020-04-27

*** tosky has quit IRC00:09
*** sgw has quit IRC00:16
*** sgw has joined #zuul00:35
*** Goneri has quit IRC00:59
*** swest has quit IRC01:04
*** swest has joined #zuul01:18
*** swest has quit IRC02:02
*** swest has joined #zuul02:17
*** bhavikdbavishi has joined #zuul02:46
*** bhavikdbavishi1 has joined #zuul02:49
*** threestrands has joined #zuul02:51
*** bhavikdbavishi has quit IRC02:51
*** bhavikdbavishi1 is now known as bhavikdbavishi02:51
*** bhavikdbavishi has quit IRC04:02
*** bhavikdbavishi has joined #zuul04:22
*** evrardjp has quit IRC04:35
*** bhavikdbavishi has quit IRC04:35
*** evrardjp has joined #zuul04:35
openstackgerritMerged zuul/zuul-jobs master: Update ensure-javascript-packages README  https://review.opendev.org/72235404:52
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-virtualenv  https://review.opendev.org/72330904:57
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-virtualenv  https://review.opendev.org/72330905:00
*** ysandeep|away is now known as ysandeep05:12
openstackgerritIan Wienand proposed zuul/zuul-jobs master: [wip] ensure-virtualenv  https://review.opendev.org/72330905:37
*** dpawlik has joined #zuul05:56
*** yolanda has joined #zuul06:16
*** lennyb has quit IRC06:54
*** rpittau|afk is now known as rpittau07:22
*** tosky has joined #zuul07:26
*** jcapitao has joined #zuul07:34
*** sshnaidm|afk is now known as sshnaidm07:35
*** jcapitao has quit IRC07:38
*** jcapitao has joined #zuul07:40
*** bhavikdbavishi has joined #zuul07:50
*** bhavikdbavishi1 has joined #zuul08:01
*** bhavikdbavishi has quit IRC08:03
*** bhavikdbavishi1 is now known as bhavikdbavishi08:03
*** jpena|off is now known as jpena08:12
*** ysandeep is now known as ysandeep|lunch08:16
*** threestrands has quit IRC08:20
*** mhu has joined #zuul08:25
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: enable installing ansible collections  https://review.opendev.org/72307108:26
*** logan_ has joined #zuul08:31
*** logan- has quit IRC08:32
*** logan_ is now known as logan-08:35
*** kmalloc has joined #zuul08:45
openstackgerritJan Kubovy proposed zuul/zuul master: Connect merger to Zookeeper  https://review.opendev.org/71622109:30
openstackgerritJan Kubovy proposed zuul/zuul master: Connect merger to Zookeeper  https://review.opendev.org/71622109:35
openstackgerritJan Kubovy proposed zuul/zuul master: Connect executor to Zookeeper  https://review.opendev.org/71626209:39
*** ysandeep|lunch is now known as ysandeep09:53
*** yolanda has quit IRC09:56
*** yolanda has joined #zuul10:10
*** rpittau is now known as rpittau|bbl10:32
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: enable installing ansible collections  https://review.opendev.org/72307110:40
*** kmalloc has quit IRC10:54
openstackgerritJan Kubovy proposed zuul/zuul master: Connect executor to Zookeeper  https://review.opendev.org/71626210:59
*** jcapitao is now known as jcapitao_lunch11:03
openstackgerritAlbin Vass proposed zuul/zuul master: WIP: enable installing ansible collections  https://review.opendev.org/72307111:07
*** jpena is now known as jpena|lunch11:31
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Use cached buildset_registry fact  https://review.opendev.org/72338511:32
avassmordred: re 723109, is that ^ what we want?11:33
avassoh, or is this two completely different hosts11:34
*** rf0lc0 has joined #zuul11:35
*** bhavikdbavishi has quit IRC11:42
*** yolanda has quit IRC11:44
*** yolanda has joined #zuul11:44
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: haskell-stack-test: add haskell tool stack test  https://review.opendev.org/72326311:58
*** rlandy has joined #zuul11:59
*** jcapitao_lunch is now known as jcapitao12:04
zbrdoes anyone know the reasons behind the "42" value for tailing inside renderFailedTask ? -- i find it far too low to be of practical use.12:26
zbrat least 100 would be needed, but I wonder if not even 1024 would not be seen as acceptable.12:27
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Support multi-arch image builds with docker buildx  https://review.opendev.org/72233912:33
*** jpena|lunch is now known as jpena12:34
tristanCzbr: no particular reason. I think if you need more context, then you should use the console tab. In which situation the error is not visible in the last lines of a failed task?12:34
mordredavass: yeah - different host - and it's actually totally ok and correct for that task to fail sometimes - there might not be a buildset registry and the role should work both with and without12:35
zbrtributarian: pytest with coverage is a perfect example: https://dashboard.zuul.ansible.com/t/ansible/build/4345cbf047764c46a062678433f64a6f12:35
avassmordred: but doesn't zuul_return return variables to child jobs laready? what is the reason we check result.json?12:35
zbrwhere you endup without any error visible12:35
mordredavass: I was mostly trying to poke at getting it to not just correctly deal with the failure case, but also not show as error12:36
zbri am making now a PR to increase it, but i am not sure which value to pick, TBH, I can understand why "42" was picked initially, but sadly it proves to be a too small ultimate answer12:36
mordredavass: ah - good question12:36
mordredavass: in this case, it might not be a child job12:36
tristanCzbr: there is `ERROR:   py35-ansible28: commands failed` and the `short test summary info` output though12:36
mordredwe're reading the buildset_registry of a paused job in the same buildset12:37
mordredso it's a sibling job12:37
avassmordred: oh12:37
avassmordred: I'll push a fix for that later, I think it's better to check if that file exists and buildset_registry is defined, rather than supressing that error12:37
zbrlist of failed tests is far less useful than the specific exceptions12:38
mordredavass: cool - yeah - the error task has been frequently distracting when debugging issues12:38
zbris anyone afraid that 1024 may be too much?12:38
zbris only about *failed*12:38
mordredzbr: 1024 would not fit on my screen without significant scrolling - so there's a balance to be found between showing too little, just enough, and too much again so that it's no longer clear either12:39
zbrmordred: with 42 even an infinite amount of scrolling would not help ;)12:40
zbrif you challenge me, i could waste few hours and implement an expand option12:40
zbrmordred: 256 ok?12:42
tristanCzbr: in https://dashboard.zuul.ansible.com/t/ansible/build/4345cbf047764c46a062678433f64a6f , how much you need to see the relevant bit?12:42
zbri am not sure, 100 may be enough, let me check.12:43
zbrnote: that is just one recent example/12:43
tristanCzbr: because it seems like that if the `short test summary info` is not enough, then you might need to show the whole output to get what you want12:45
zbrtristanC: i am not searching the web for a simple implementation of "more" / collapse/expand12:45
zbrthis would sort other issues by making visible when the output was censored12:46
zbri was confused often by the default tailing, even on linting jobs, where it failed at before running ansible-lint (which is verbose by default).12:46
zbrmaybe I can find a better solution that does not fore the user to dig for the full output12:47
*** rpittau|bbl is now known as rpittau12:49
*** Goneri has joined #zuul12:54
*** Goneri has quit IRC13:01
*** Goneri has joined #zuul13:18
avassI wonder if this works13:19
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: omit variable instead of ignoring errors  https://review.opendev.org/72352413:19
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: omit variable instead of ignoring errors  https://review.opendev.org/72352413:20
openstackgerritSorin Sbarnea proposed zuul/zuul master: WIP: Make task errors expandable  https://review.opendev.org/72353413:39
noonedeadpunkhey everyone.13:53
noonedeadpunkSo I was working on jobs to build images and upload it to glance. But wondering of the best way to provide clouds.yaml to the upload step...13:54
noonedeadpunkOr maybe you have some advices regarding the thing...13:54
*** cdearborn has joined #zuul13:55
corvuszbr, tristanC: how about we put a button in the error section to take you directly to that task in the console tab?  that way if the error is outside of the 42 lines, it's one click to get the full output.14:00
corvusmordred: ^14:00
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json  https://review.opendev.org/72352414:01
zbrcorvus: it is an option but with its own challanges: now the expand does not have an anchor, got to get it, also the popup window with details is another UX nightmare and I almost never using it.14:04
zbranother place where screen estate is wasted.14:04
corvuszbr: rather than saying it's a "ux nightmare" perhaps you could constructively indicate what is deficient and could be improved14:05
zbrit uses ~80% screen width for no practical reason, plus it does not auto-wrap long lines, producing endless horizontal scrolling14:06
zbralso, there is no way to share a link to specific line, the entire webpage ends with /console14:07
corvuszbr: if you're looking for output, it might be better to expand the task using the arrow on the left rather than use the popup14:07
zbrso if I want to send a link to a specific error to a collegue, i have no way of doing that.14:07
corvuszbr: it's true, there's no line link, but you can share a link to the task14:07
corvuszbr: i suspect it would be possible to add line links14:08
zbrit should change the browser URL, requiring people to search for <anchor> symbol is not really what I call friendly. AFAIK, browsers allow to update the url without reloading.14:08
corvuszbr: i don't understand that last statement14:09
corvusi'm not aware of any workflow that requires searching for anchors14:09
zbrcorvus: when I click to see a task and popup appears, there is no update on browser url.14:09
*** irclogbot_3 has joined #zuul14:09
corvusright, there's a link icon in the top right14:09
corvusis that what you meant by searching for anchors?14:10
zbrcorvus: i am trying to explain that the most common way to share a web page is to copy browser url, and not a specific anchor point from the page.14:10
zbri think is fixable14:11
zbrthe moment I click on a task, the url should change to append something like "#4/0/10/ubuntu-xenial", so I can share it.14:12
corvuszbr: doing so may affect back-button navigation, so while i think it's worth considering, i'm not sure it's necessarily desirable14:12
corvuszbr: if you want to propose a change to implement that, i expect we would consider it.  as well as adding line links.14:13
*** irclogbot_3 has quit IRC14:13
zbrin fact I think is possible to change url even without affecting browser history (at least some browsers allow this)14:13
corvusthat would make it more likely to be accepted i think14:13
zbris not as we would be the first ecountering these challenges14:14
corvuszbr: the 80% width seems like a pretty nice way to communicate navigation information, that one is looking at details for a specific task in the list, but i'm sure there are other options14:15
corvuszbr: i understand you dislike horizontal scrolling, but others do.  it may take a bit of work to support both.14:16
zbrcorvus: we already fixed horizontal scroll in other places, so i doubt we cannot fix it here.14:16
zbrtry to scroll around this page with a trackpad: https://dashboard.zuul.ansible.com/t/ansible/build/4345cbf047764c46a062678433f64a6f/console#4/0/10/ubuntu-xenial14:17
corvuszbr: i don't use a trackpad14:17
zbris kinda similar to how your would see after drinking too much alcohol14:18
zbrquite oftern i endup with an empty section of page with no knowledge of where is the output. mainly because it did scroll bit on the right side.14:19
corvusi agree that could be improved14:19
zbrthat one is the easiest to fix, i will raise patch. others may be less easy.14:19
zbranyway, one at a time14:19
corvusthanks :)14:19
tristanCcorvus: adding the link seems like a good improvement, perhaps that would be enough to satisfy zbr need14:27
*** irclogbot_3 has joined #zuul14:27
zbrbtw, can someone give me a hint on how to easily test UI changes locally? it takes a lot of time to upload changes to gerrit and wait for zuul-build-dashboard to run.14:29
*** irclogbot_3 has quit IRC14:29
corvuszbr: yes, 1sec14:30
zbrmainly a local-site-preview kind of run14:30
corvusit's really easy and nice14:30
corvuszbr: https://zuul-ci.org/docs/zuul/reference/developer/javascript.html14:30
corvuszbr: the first part of that should get you the toolchain installed locally14:31
*** irclogbot_0 has joined #zuul14:31
corvuszbr: then just "yarn start:openstack" as described in https://zuul-ci.org/docs/zuul/reference/developer/javascript.html#development14:31
corvuszbr: you can edit files and as soon as you save them, they'll automatically get recompiled and the browser reloads14:32
zbrcorvus: wow, really impressed, i had the toolset installed but never run that.14:33
zbri would personally find useful to have a tox env for command like this, even if it does not need a venv to run, just for documenting it.14:34
*** irclogbot_0 has quit IRC14:35
zbri may be biased towards tox as being so ubiquitous on python projects, and stretch its use a bit.14:35
fungiit's not as ubiquitous as `make` ;)14:36
zbr but instead of having to "cd web && yarn start:openstack" it may be easier to have envs.14:36
fungibut yeah, zuul already relies on tox, so probably more sensible than make14:36
zbrfungi: i would not mind make at all, I seen quite nice implementations, same idea: single command to run in root with various "targets".14:36
fungiclarkb even had a poc a few years back to replace tox with make14:37
zbrhaha14:37
fungifollowing one too many non-backward-compatible behavior changes from the tox maintainers14:37
zbrin fact many years ago I used "waf", a pure python build tool using procinples similar to make14:38
zbrwhich also happens to be self-bootstraping14:38
*** irclogbot_2 has joined #zuul14:38
zbri wonder if the newer version of tox (v4) is going to go towards being more generic or not.14:39
*** zxiiro has joined #zuul14:39
*** irclogbot_2 has quit IRC14:39
zbrmaybe the easiest approach is to just create a makefile that calls tox and yarn, w/o much fuss, only for convenience14:40
zbrat least it would not be biased towards python or javascript world :D14:40
*** irclogbot_3 has joined #zuul14:41
fungii take it yarn is a replacement for npm14:44
*** irclogbot_3 has quit IRC14:45
*** irclogbot_0 has joined #zuul14:48
zbrwould anyone be against adding a Makefile for development purposes?14:50
*** irclogbot_0 has quit IRC14:51
*** bhavikdbavishi has joined #zuul14:53
*** bhavikdbavishi1 has joined #zuul14:56
*** bhavikdbavishi has quit IRC14:57
*** bhavikdbavishi1 is now known as bhavikdbavishi14:57
clarkbfungi: yes I was told by people like dstufft that make would be too difficult for python developers15:00
fungiglad i'm not as dense as a python developer then ;)15:04
fungi(or rather, his opinion of other python developers anyway)15:04
openstackgerritMerged zuul/zuul-jobs master: hlint: add haskell source code suggestions job  https://review.opendev.org/72230915:24
*** ysandeep is now known as ysandeep|away15:25
zbrclarkb: and you take everything such people do/say as true or good?15:26
clarkbzbr: no but the change was pushed and no one in openstack seemed willing to take it further15:28
clarkbzbr I used zuul as a guinea pig the change is still in gerrit if you want to see it. let me see if I can find it15:28
*** bhavikdbavishi has quit IRC15:29
clarkbzbr https://review.opendev.org/#/c/88698/15:30
zbrclarkb: looks ok but i can understand why people may prefer tox.15:31
zbrwriting makefiles requires years of software engineering, editing a ini file, far less.15:31
zbrstill, tox and make have very different goals, with little overlap.15:32
clarkbeh we were required to write makefiles in second year of university so only 1 year required :)15:32
zbrmy only intention was to have a single launcher for various testing commands on zuul, not to replace tox15:32
zbrlike a makefile that would have a list of commands (some would be tox calls, some yarn,...)15:33
clarkba large part of my motivation at the time was tox was unstable and every release broke us in new ways. I actually used that makefiel locally for a while as result while people struggled with tox15:33
zbris much better now15:33
clarkbeventually maintainership of tox seems to have shifted and it got better15:33
*** bhavikdbavishi has joined #zuul15:33
zbryep, i am happy that tox was salvaged15:33
clarkbthe real issue is tox would break, we would push bugfices then get told we are just using tox wrong and the fix would wait 6 months for someone other than us to complain before landing15:34
fungiyeah, we covered makefiles during a seminar in c programming at my highschool (pre-university), so ~11th year students15:34
funginobody seemed to have any trouble with the concept15:34
zbrbut we know well that if we try to reimplement tox features in a Makefile we may retire soon :D15:35
fungiand yes, the difference between tox and make is that tox encodes a lot of behaviors as internal black box magic, while make basically gives you a miniature programming language so that the logic is laid bare in your makefile15:36
clarkbzbr: ya but we don't need those features imo15:36
clarkbthat was sort of the key bit of my makefile example15:36
clarkbits ridiculously simple to have core functionality15:36
clarkbanyway that ship has long sailed15:37
zbrstill, adding a utility Makefile should not be out of the questions, right? like one that exposes various targers, supports listting them15:38
*** irclogbot_1 has joined #zuul15:39
zbrcorvus: really thanks for the yarn hint! is awesome.15:43
corvuszbr: yw;  tristanC, mordred ^ kudos :)15:43
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json  https://review.opendev.org/72352415:46
tristanCzbr: nice :)15:46
avasscorvus, mordred: How about doing something like this for ansible collections? https://review.opendev.org/#/c/723071/15:47
tristanCcorvus: would you mind revisit your -1 on https://review.opendev.org/712759 since it is fixed in the next CR, or should i update and rebase the stack?15:47
avasswhat's the policy on adding packages to requirements.txt by the way?15:47
corvusavass: i don't think we have any policies really, we just evaluate them as needed :)15:50
avasscorvus: ah ok, just wondering since using packaging was really nice, but it's just for one line of code :)15:51
*** sshnaidm is now known as sshnaidm|afk15:53
corvustristanC: ah, oops, i stopped at that change; i'll proceed through 965 then15:53
tristanCcorvus: thanks a lot15:56
*** rpittau is now known as rpittau|afk16:07
openstackgerritSorin Sbarnea proposed zuul/zuul master: WIP: Make task errors expandable  https://review.opendev.org/72353416:11
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json  https://review.opendev.org/72352416:13
*** avass has quit IRC16:24
*** tobiash has quit IRC16:26
*** tobias-urdin has quit IRC16:26
*** noonedeadpunk has quit IRC16:26
*** jkt has quit IRC16:26
*** msuszko has quit IRC16:26
*** kgz has quit IRC16:26
*** AJaeger has quit IRC16:26
openstackgerritSorin Sbarnea proposed zuul/zuul master: Fix pre-wrapping on console  https://review.opendev.org/72360316:27
*** irclogbot_1 has quit IRC16:28
*** irclogbot_0 has joined #zuul16:30
*** kgz has joined #zuul16:31
*** avass has joined #zuul16:32
*** bhavikdbavishi has quit IRC16:32
zbrcorvus: clarkb : what do you think about https://review.opendev.org/#/c/650276/ ? (splitting stdout/stderr)16:32
*** tobiash has joined #zuul16:32
*** tobias-urdin has joined #zuul16:32
*** noonedeadpunk has joined #zuul16:32
*** jkt has joined #zuul16:32
*** msuszko has joined #zuul16:32
*** AJaeger has joined #zuul16:32
zbri would find it useful to be split as we can also display it with different colors, but i am not sure if implementation is good.16:33
*** evrardjp has quit IRC16:35
*** sgw has quit IRC16:35
*** jcapitao has quit IRC16:35
corvusthat's tricky.  the only way we can reproduce the behavior you see when you run something in a shell is to combine them.  if we separate them, we can approximane that, but the lines may still arrive in a slightly different order.16:37
corvusif we're okay with that, then i think we could return 3 things: stdout, stderr, and interleaved (which would be as close as we could get to the original order)16:38
corvuszbr: interleaved could be a tuple of (fd, text) so that you could color-code them16:38
corvus(ie, the console output would use interleaved)16:39
*** ChanServ has quit IRC16:42
*** ChanServ has joined #zuul16:45
*** tepper.freenode.net sets mode: +o ChanServ16:45
*** evrardjp has joined #zuul16:46
openstackgerritMerged zuul/zuul-operator master: Add TLS configuration to ZooKeeper service  https://review.opendev.org/71275916:51
*** sgw has joined #zuul16:54
*** avass has quit IRC16:58
toskyis there a way to extract all the jobs which (recursively) inherit from a certain job but just for a specific branch (master)?17:02
toskyhttps://zuul.openstack.org/jobs shows the full inheritance tree, but some of the elements may be relevant only for some stable branches17:02
tosky(the specific use case is: on the openstack.org instance of zuul I need to get the list of all the legacy jobs (from legacy-base) to start preparing a cleanup work in the next development cycle)17:04
corvustosky: i don't think you can automate a query like that, but if you click on any of the jobs under legacy-base, you can cycle through their branch variants and see which ones inherit from legacy-base17:07
corvusit doesn't look like there are very many?17:07
corvusthough there are a lot of legacy-dsvm-base jobs17:07
corvustosky: but all that comes from the api, so if you can do it by clicking, you can do it with a python script too :)17:08
toskyI wanted to avoid the clicks :/17:09
toskyI asked because the API documentation says that it's incomplete, so I wanted to be sure first17:09
openstackgerritGraham Hayes proposed zuul/nodepool master: Implement an Azure driver  https://review.opendev.org/55443217:12
*** yolanda has quit IRC17:18
*** tobiash has quit IRC17:26
*** tobias-urdin has quit IRC17:26
*** noonedeadpunk has quit IRC17:26
*** jkt has quit IRC17:26
*** msuszko has quit IRC17:26
*** AJaeger has quit IRC17:26
*** jcapitao has joined #zuul17:28
*** tobiash has joined #zuul17:29
*** tobias-urdin has joined #zuul17:29
*** noonedeadpunk has joined #zuul17:29
*** jkt has joined #zuul17:29
*** msuszko has joined #zuul17:29
*** AJaeger has joined #zuul17:29
*** jpena is now known as jpena|off17:35
*** ChanServ has quit IRC17:39
*** ChanServ has joined #zuul17:41
*** tepper.freenode.net sets mode: +o ChanServ17:41
*** avass has joined #zuul17:43
*** jcapitao has quit IRC17:43
avasscorvus: regarding this: https://review.opendev.org/#/c/723524/ setting failed_when: false still makes the task log an exception, that can be a bit annoying when debugging17:45
avasscorvus: compare to the logs from zuul-jobs-test-registry-docker of mordreds change: https://review.opendev.org/#/c/723109/17:49
avass(just noticed I change build-container-image instead of build-docker-image)17:51
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json  https://review.opendev.org/72352417:53
corvusavass: bummer -- i'd love it if we could ignore that without having an exception or an extra task :/18:11
*** cdearborn has quit IRC18:12
corvus(maybe we should add a zuul-specific module to load results.json iff present)18:13
corvusavass: but i agree that getting rid of the "red" is the most important thing here :)18:13
avasscorvus: yeah, I'm starting to feel that ignore_errors should be avoided18:13
corvusavass: yes, i think we've mostly come to the conclusion we probably want faild_when instead of ignore_errors18:14
corvusi think the tricky part here is the way the file lookup module failes18:14
corvusfails18:14
avasscoruvs: yep18:14
corvusi think i looked into that previously and didn't see any options we could pass to it to improve it's behavior18:15
avasssince it's a sibling i don't think there is18:15
*** jlk has joined #zuul18:17
*** dmellado has quit IRC18:17
*** dmellado has joined #zuul18:24
*** dmellado has quit IRC18:25
*** dmellado has joined #zuul18:33
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: tox: Use 'block: ... always: ...' instead of ignore_errors  https://review.opendev.org/72364018:39
corvusavass: ohh nice -- looking at that original comment to undertand why that was written that way, i think your approach may achieve the goal better :)18:41
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: ensure-sphinx: use failed_when: false instead of ignore_errors: true  https://review.opendev.org/72364218:41
avasscorvus: yeah, I think the block construct is a bit underused at the moment :)18:43
AJaegerthere're a few open zuul-jobs reviews by avass - anybody else wants to review them, please? https://review.opendev.org/721237 https://review.opendev.org/701381 https://review.opendev.org/721248 https://review.opendev.org/72179618:44
avassI'm going to try to get rid of some usage of ignore_errors in the repo :)18:44
*** dpawlik has quit IRC18:47
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: fo: Use 'block: ... always: ...' and failed_whne instead of ignore_errors  https://review.opendev.org/72364318:47
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: go: Use 'block: ... always: ...' and failed_when instead of ignore_errors  https://review.opendev.org/72364318:47
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: ara-report: use failed_when: false instead of ignore_errors: true  https://review.opendev.org/72364418:49
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: k8-logs: use failed_when: instead of ignore_errors:  https://review.opendev.org/72364718:51
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: container-logs: use failed_when: instead of ignore_errors:  https://review.opendev.org/72364818:54
corvusmordred, clarkb: can you look at https://review.opendev.org/701381 ?18:56
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: tox: Use 'block: ... always: ...' instead of ignore_errors  https://review.opendev.org/72364018:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: ensure-sphinx: use failed_when: false instead of ignore_errors: true  https://review.opendev.org/72364218:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: go: Use 'block: ... always: ...' and failed_when instead of ignore_errors  https://review.opendev.org/72364318:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: ara-report: use failed_when: false instead of ignore_errors: true  https://review.opendev.org/72364418:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: fetch-subunit-output: use failed_when: instead of ignore_errors:  https://review.opendev.org/72365318:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: add-build-sshkey: use failed_when: instead of ignore_errors:  https://review.opendev.org/72365418:57
avassI think that's it18:57
avasssorry for that last spam, I got a bit lost when I didn't stack them :)18:57
corvusnp, it's exciting :)18:57
corvusmnaser, clarkb: https://review.opendev.org/721796 could use your eyes18:59
avasscorvus: re 701381, I think we have to be able to control the owner/group, since if you can't have multiple 'zuul' users on the same node18:59
avasscorvus: unless there's a better solution for that18:59
corvusavass: i may not understand the problem -- but don't we just want the files pulled to the executor to be owned by the running user?19:00
avasscorvus: do they need to be?19:03
avasscorvus: if so we should probably set the owner after synchronize instead of keeping it from the remote19:03
corvusavass: that seems like the easiest way to avoid any permissions issues.  i think for logs we don't actually care about ownership on the executor.19:03
avasscorvus: we have the same problem with unarchive19:04
*** saneax has quit IRC19:04
avasscorvus: by default synchronize keeps the owner/group of the files, if that owner doesn not exist on the executor the task fails19:05
corvusright, i think that's what we should fix then -- we don't ever care to save the owner/group of those files, we always want them to be owned by the current user (ie, the zuul user on the executor)19:06
avasscorvus: yeah, I could update it to do that instead19:06
corvusif that's only working right now because most of the time there's a zuul user on the remote side, than that's just an accident.  it wasn't intentionally designed that way :)19:06
avassi guessed so :)19:06
openstackgerritMerged zuul/zuul-jobs master: fetch-sphinx-tarball: use remote_src true  https://review.opendev.org/72123719:09
openstackgerritMerged zuul/zuul-jobs master: fetch-sphinx-tarball: Do not keep owner of archived files  https://review.opendev.org/72124819:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Set owner to executor user  https://review.opendev.org/70138119:28
avasscorvus: I'm not sure if there's a way to check the user running on the executor side in an untrusted context19:28
*** armstrongs has joined #zuul19:40
AJaegercorvus, avass, http://lists.zuul-ci.org/pipermail/zuul-discuss/2020-April/001203.html was send on the 2nd of April to zuul-discuss and not to zuul-announce. Do we need to send an announcement to zuul-announce before we merge https://review.opendev.org/#/c/719322/ ?19:46
* AJaeger suggest we do...19:46
avassAJaeger: we should probably do that19:47
AJaegeravass: can you do, link to the earlier zuul-discuss email and the review and give an additional 2 weeks time, please?19:48
avassAJaeger: sure, I have to leave in a minute sicne it's getting late here. But I can do it tomorrow19:48
avassand I want to get my i3 setup up on my laptop :)19:49
corvusdo we want to add a step where we make those fail with a message?19:49
corvus(we've never done quite so large a migration before)19:49
*** armstrongs has quit IRC19:50
avasscorvus: you mean fail with a message to use ensure-* instead? yeah that could be good19:50
corvus(if we did that, maybe we would send a 2 week announcement, then merge changes to do that ^, then send another 2 week announcement, then merge changes to remove)19:50
*** zenkuro has joined #zuul19:51
AJaegeravass: https://review.opendev.org/#/c/719401 needs rebaseing - I'm just ping dependencies19:52
AJaegerAnd looking how slow those merge: Yes, let's do that - and move the dependencies to the final change to remove the jobs - and let users fail...19:52
AJaegercorvus: could you merge https://review.opendev.org/#/c/719402/ for x/pbrx, please?19:53
openstackgerritAlbin Vass proposed zuul/zuul-operator master: Use ensure-* roles  https://review.opendev.org/71940119:53
AJaegerinfra-root, could you review https://review.opendev.org/#/c/719404/ for gerrit-lib so that we can retire ensure roles, please?19:54
corvusyeah, that's what i'm worried about :)  lots of these are going to be lurking out there, so we should be as helpful as possible to users :)19:56
openstackgerritMerged zuul/zuul-jobs master: tox: allow running default envlist in tox  https://review.opendev.org/72179619:56
corvuswe should maybe add a 'warnings' attr to zuul_return so we can return zuul warnings in jobs19:57
corvusthen we could have something show up on the report19:57
AJaegerthat sounds cool19:57
clarkbin #openstack-infra its been pointed out that serving the main.js file for our zuul dashboard is not very quick. Looking at it we don't seem to have super minified that file and also don't serve it compressed. I think this may be a change with our friday switch from using tarball of js to the js in our docker container?19:58
AJaeger"Job uses install-X, update it to ensure-X since install-X will be removed 15th of May"19:58
clarkbits got me wondering if cherrypy should serve compressed versions of those files if clients say they can handle them? but also got me wondering if we are compiling an appropriate artifact?19:58
corvusAJaeger: ++19:59
corvusclarkb: oh that's a good question -- mordred, tristanC: ping20:00
*** Shrews has left #zuul20:00
corvuswe were serving the javascript-content tarball20:00
clarkbthe file is 3.2MB fwiw and takes me about 2-3s to download. Firefox does cache it properly though. The user in question did not have the browser caching it so it was more noticeable20:00
avasscorvus, AJaeger: yeah that sounds cool20:00
AJaegeravass: FYI, most of you ignore_error changes are in merge conflict now - something for tomorrow...20:02
corvustobiash: we reverted the git gc change; we're pretty sure it was causing problems with some repos in production in opendev. i saved a copy of one of them; i'll try to see if i can articulate the problem.20:02
avassAJaeger: ah, yeah I'll fix that tomorrow as well20:03
* AJaeger signs off now as well - good night everybody20:03
avasssame here, good night!20:05
tristanCclarkb: corvus: iirc we are using create-react-app build toolchain which should produce a fairly optimized build20:05
clarkbtristanC: it looks like whitespace is removed but var names are still expanded and the like20:05
clarkbtristanC: https://zuul.opendev.org/static/js/main.7c3d47f8.js if you want to see what we are serving20:06
tobiashcorvus: thanks for the info. Did it clean too much or do you suspect some sort of race?20:07
tristanCclarkb: i'm not sure what is suspicious in that link, what var names are you refering too?20:08
clarkbtristanC: createElement etc20:08
clarkbtristanC: it seems like the libraries and such aren't minimized too?20:08
clarkbparentNode20:09
tristanCthose are standard js/dom function, iirc they are usually left as-is20:10
clarkbtristanC: looks like we also have some fairly verbose error log messages?20:10
clarkbtristanC: fwiw I've just pulled the old tarball and it is the same 3.2MB so we aren't a regression there20:12
clarkbI wonder if our old apache config was serving that compressed though20:12
corvustobiash: https://review.opendev.org/723110 has the error message -- it seemed like it pruned too much (ie, it pruned the commit in fetch_head), but it's entirely possible that was a race20:12
tristanCclarkb: there are probably more efficient packer, though iirc create-react-app pick one that enable runtime debugging.20:12
corvustobiash: we saw it on one repo across several mergers, but activity was low; we later saw it on a second repo and decided there was a risk of increasing occurrances as activity increased, so reverted20:14
corvustobiash: (incidentally we also saw a problem with the delete refs change, but tristanC was able to fix than quickly and we rolled forward for that one)20:14
corvustobiash: (i explored the possibility that the delete-refs change could have triggered the problem with the gc change, but i think i found evidence that eliminated that possibility)20:15
clarkbtristanC: I thought the way that was supposed to work was you get super minial thing but then for debugging requested the debugging file. Kind of like adding in a symbols file when you use gdb20:17
clarkbalso for most users I expect they cache the file and are fine for a while20:18
tobiashHrm, interesting fetch_head is a ref which should inhibit pruning that object20:19
clarkbI don't know why this particular user's browser was not caching the js file20:19
tobiashMaybe we should set the prune threshold to a day instead of now20:19
corvustobiash: is it really a ref?20:20
corvushttps://static.opendev.org/user/corvus/oo.tgz  has the git repo i saved on one of the failing executors20:22
tobiashI assume it's a ref similar to head20:24
corvushrm, that looks like it's working -- let me double check that's the right copy20:24
*** zxiiro has quit IRC20:24
corvusdrat, i'm unable to reproduce that error using the tarball; maybe the repo was just in the wrong state when i made it20:30
fungii suppose we could try reapplying that tuning to just one of our executors in opendev20:32
corvusi can get the repo back into a state where it returns that error by: untarring the archive, then running: git reset --hard origin/master; git gc; git merge -s resolve FETCH_HEAD20:32
corvusthat last command is the command which failed20:32
clarkbrereviewing our old apache webhosting we were compressing status.json as well as caching it but didn't do anything special for the js that I can see20:32
fungiit went essentially unnoticed for a couple of days after one of our executors was spontaneously rebooted onto that patch after a provider issue, we didn't find out there was a problem with the git repos until we upgraded all of them20:33
corvusfungi: yeah, that might be a good approach; but we may want to make sure we have all the anticipated debug lines in place first.20:33
clarkbmordred: ^ maybe we want to go back to caching the status json as well as compressing it? We can also compress js in the same way I think20:33
corvusfungi: good point, the retry logic should keep it at a low level20:33
clarkboh ok we are still doing that for json20:34
fungionce we realized there was a problem, we were able to find evidence of it dating back on that one executor to when it got rebooted20:35
corvusfungi: was that for the gc patch?  because that merged very recently20:36
fungicorvus: oh, right maybe it was the cleaning change20:36
corvusyeah, the gc change only merged thursday20:37
fungiokay, yeah it was the refs cleaning then20:37
fungisorry, we wound up dealing with both in the same window, i mixed them up20:37
*** Goneri has quit IRC21:05
*** igordc has joined #zuul21:07
*** jrichard13 has joined #zuul21:07
*** jrichard13 has quit IRC21:07
*** jrichard has joined #zuul21:08
*** cdearborn has joined #zuul21:14
*** jrichard has quit IRC22:35
mordredcorvus: lookit: https://zuul.opendev.org/t/zuul/build/d0083d186b914d6e90eef6600fe049b1 - we got further - now we're just to issues pushing and CA's.22:59
*** tosky has quit IRC23:02
mordredcorvus: I think we can just copy {{ ca_dir }}/buildset-registry.crt into the builder container and then run update-ca-certificates in there23:02
*** igordc has quit IRC23:14

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