*** tosky has quit IRC | 00:09 | |
*** sgw has quit IRC | 00:16 | |
*** sgw has joined #zuul | 00:35 | |
*** Goneri has quit IRC | 00:59 | |
*** swest has quit IRC | 01:04 | |
*** swest has joined #zuul | 01:18 | |
*** swest has quit IRC | 02:02 | |
*** swest has joined #zuul | 02:17 | |
*** bhavikdbavishi has joined #zuul | 02:46 | |
*** bhavikdbavishi1 has joined #zuul | 02:49 | |
*** threestrands has joined #zuul | 02:51 | |
*** bhavikdbavishi has quit IRC | 02:51 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 02:51 | |
*** bhavikdbavishi has quit IRC | 04:02 | |
*** bhavikdbavishi has joined #zuul | 04:22 | |
*** evrardjp has quit IRC | 04:35 | |
*** bhavikdbavishi has quit IRC | 04:35 | |
*** evrardjp has joined #zuul | 04:35 | |
openstackgerrit | Merged zuul/zuul-jobs master: Update ensure-javascript-packages README https://review.opendev.org/722354 | 04:52 |
---|---|---|
openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: [wip] ensure-virtualenv https://review.opendev.org/723309 | 04:57 |
openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: [wip] ensure-virtualenv https://review.opendev.org/723309 | 05:00 |
*** ysandeep|away is now known as ysandeep | 05:12 | |
openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: [wip] ensure-virtualenv https://review.opendev.org/723309 | 05:37 |
*** dpawlik has joined #zuul | 05:56 | |
*** yolanda has joined #zuul | 06:16 | |
*** lennyb has quit IRC | 06:54 | |
*** rpittau|afk is now known as rpittau | 07:22 | |
*** tosky has joined #zuul | 07:26 | |
*** jcapitao has joined #zuul | 07:34 | |
*** sshnaidm|afk is now known as sshnaidm | 07:35 | |
*** jcapitao has quit IRC | 07:38 | |
*** jcapitao has joined #zuul | 07:40 | |
*** bhavikdbavishi has joined #zuul | 07:50 | |
*** bhavikdbavishi1 has joined #zuul | 08:01 | |
*** bhavikdbavishi has quit IRC | 08:03 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 08:03 | |
*** jpena|off is now known as jpena | 08:12 | |
*** ysandeep is now known as ysandeep|lunch | 08:16 | |
*** threestrands has quit IRC | 08:20 | |
*** mhu has joined #zuul | 08:25 | |
openstackgerrit | Albin Vass proposed zuul/zuul master: WIP: enable installing ansible collections https://review.opendev.org/723071 | 08:26 |
*** logan_ has joined #zuul | 08:31 | |
*** logan- has quit IRC | 08:32 | |
*** logan_ is now known as logan- | 08:35 | |
*** kmalloc has joined #zuul | 08:45 | |
openstackgerrit | Jan Kubovy proposed zuul/zuul master: Connect merger to Zookeeper https://review.opendev.org/716221 | 09:30 |
openstackgerrit | Jan Kubovy proposed zuul/zuul master: Connect merger to Zookeeper https://review.opendev.org/716221 | 09:35 |
openstackgerrit | Jan Kubovy proposed zuul/zuul master: Connect executor to Zookeeper https://review.opendev.org/716262 | 09:39 |
*** ysandeep|lunch is now known as ysandeep | 09:53 | |
*** yolanda has quit IRC | 09:56 | |
*** yolanda has joined #zuul | 10:10 | |
*** rpittau is now known as rpittau|bbl | 10:32 | |
openstackgerrit | Albin Vass proposed zuul/zuul master: WIP: enable installing ansible collections https://review.opendev.org/723071 | 10:40 |
*** kmalloc has quit IRC | 10:54 | |
openstackgerrit | Jan Kubovy proposed zuul/zuul master: Connect executor to Zookeeper https://review.opendev.org/716262 | 10:59 |
*** jcapitao is now known as jcapitao_lunch | 11:03 | |
openstackgerrit | Albin Vass proposed zuul/zuul master: WIP: enable installing ansible collections https://review.opendev.org/723071 | 11:07 |
*** jpena is now known as jpena|lunch | 11:31 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Use cached buildset_registry fact https://review.opendev.org/723385 | 11:32 |
avass | mordred: re 723109, is that ^ what we want? | 11:33 |
avass | oh, or is this two completely different hosts | 11:34 |
*** rf0lc0 has joined #zuul | 11:35 | |
*** bhavikdbavishi has quit IRC | 11:42 | |
*** yolanda has quit IRC | 11:44 | |
*** yolanda has joined #zuul | 11:44 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: haskell-stack-test: add haskell tool stack test https://review.opendev.org/723263 | 11:58 |
*** rlandy has joined #zuul | 11:59 | |
*** jcapitao_lunch is now known as jcapitao | 12:04 | |
zbr | does 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 |
zbr | at least 100 would be needed, but I wonder if not even 1024 would not be seen as acceptable. | 12:27 |
openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Support multi-arch image builds with docker buildx https://review.opendev.org/722339 | 12:33 |
*** jpena|lunch is now known as jpena | 12:34 | |
tristanC | zbr: 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 |
mordred | avass: 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 without | 12:35 |
zbr | tributarian: pytest with coverage is a perfect example: https://dashboard.zuul.ansible.com/t/ansible/build/4345cbf047764c46a062678433f64a6f | 12:35 |
avass | mordred: but doesn't zuul_return return variables to child jobs laready? what is the reason we check result.json? | 12:35 |
zbr | where you endup without any error visible | 12:35 |
mordred | avass: I was mostly trying to poke at getting it to not just correctly deal with the failure case, but also not show as error | 12:36 |
zbr | i 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 answer | 12:36 |
mordred | avass: ah - good question | 12:36 |
mordred | avass: in this case, it might not be a child job | 12:36 |
tristanC | zbr: there is `ERROR: py35-ansible28: commands failed` and the `short test summary info` output though | 12:36 |
mordred | we're reading the buildset_registry of a paused job in the same buildset | 12:37 |
mordred | so it's a sibling job | 12:37 |
avass | mordred: oh | 12:37 |
avass | mordred: 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 error | 12:37 |
zbr | list of failed tests is far less useful than the specific exceptions | 12:38 |
mordred | avass: cool - yeah - the error task has been frequently distracting when debugging issues | 12:38 |
zbr | is anyone afraid that 1024 may be too much? | 12:38 |
zbr | is only about *failed* | 12:38 |
mordred | zbr: 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 either | 12:39 |
zbr | mordred: with 42 even an infinite amount of scrolling would not help ;) | 12:40 |
zbr | if you challenge me, i could waste few hours and implement an expand option | 12:40 |
zbr | mordred: 256 ok? | 12:42 |
tristanC | zbr: in https://dashboard.zuul.ansible.com/t/ansible/build/4345cbf047764c46a062678433f64a6f , how much you need to see the relevant bit? | 12:42 |
zbr | i am not sure, 100 may be enough, let me check. | 12:43 |
zbr | note: that is just one recent example/ | 12:43 |
tristanC | zbr: 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 want | 12:45 |
zbr | tristanC: i am not searching the web for a simple implementation of "more" / collapse/expand | 12:45 |
zbr | this would sort other issues by making visible when the output was censored | 12:46 |
zbr | i 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 |
zbr | maybe I can find a better solution that does not fore the user to dig for the full output | 12:47 |
*** rpittau|bbl is now known as rpittau | 12:49 | |
*** Goneri has joined #zuul | 12:54 | |
*** Goneri has quit IRC | 13:01 | |
*** Goneri has joined #zuul | 13:18 | |
avass | I wonder if this works | 13:19 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: WIP: omit variable instead of ignoring errors https://review.opendev.org/723524 | 13:19 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: WIP: omit variable instead of ignoring errors https://review.opendev.org/723524 | 13:20 |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: WIP: Make task errors expandable https://review.opendev.org/723534 | 13:39 |
noonedeadpunk | hey everyone. | 13:53 |
noonedeadpunk | So 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 |
noonedeadpunk | Or maybe you have some advices regarding the thing... | 13:54 |
*** cdearborn has joined #zuul | 13:55 | |
corvus | zbr, 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 |
corvus | mordred: ^ | 14:00 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json https://review.opendev.org/723524 | 14:01 |
zbr | corvus: 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 |
zbr | another place where screen estate is wasted. | 14:04 |
corvus | zbr: rather than saying it's a "ux nightmare" perhaps you could constructively indicate what is deficient and could be improved | 14:05 |
zbr | it uses ~80% screen width for no practical reason, plus it does not auto-wrap long lines, producing endless horizontal scrolling | 14:06 |
zbr | also, there is no way to share a link to specific line, the entire webpage ends with /console | 14:07 |
corvus | zbr: if you're looking for output, it might be better to expand the task using the arrow on the left rather than use the popup | 14:07 |
zbr | so if I want to send a link to a specific error to a collegue, i have no way of doing that. | 14:07 |
corvus | zbr: it's true, there's no line link, but you can share a link to the task | 14:07 |
corvus | zbr: i suspect it would be possible to add line links | 14:08 |
zbr | it 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 |
corvus | zbr: i don't understand that last statement | 14:09 |
corvus | i'm not aware of any workflow that requires searching for anchors | 14:09 |
zbr | corvus: when I click to see a task and popup appears, there is no update on browser url. | 14:09 |
*** irclogbot_3 has joined #zuul | 14:09 | |
corvus | right, there's a link icon in the top right | 14:09 |
corvus | is that what you meant by searching for anchors? | 14:10 |
zbr | corvus: 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 |
zbr | i think is fixable | 14:11 |
zbr | the 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 |
corvus | zbr: doing so may affect back-button navigation, so while i think it's worth considering, i'm not sure it's necessarily desirable | 14:12 |
corvus | zbr: 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 IRC | 14:13 | |
zbr | in fact I think is possible to change url even without affecting browser history (at least some browsers allow this) | 14:13 |
corvus | that would make it more likely to be accepted i think | 14:13 |
zbr | is not as we would be the first ecountering these challenges | 14:14 |
corvus | zbr: 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 options | 14:15 |
corvus | zbr: i understand you dislike horizontal scrolling, but others do. it may take a bit of work to support both. | 14:16 |
zbr | corvus: we already fixed horizontal scroll in other places, so i doubt we cannot fix it here. | 14:16 |
zbr | try to scroll around this page with a trackpad: https://dashboard.zuul.ansible.com/t/ansible/build/4345cbf047764c46a062678433f64a6f/console#4/0/10/ubuntu-xenial | 14:17 |
corvus | zbr: i don't use a trackpad | 14:17 |
zbr | is kinda similar to how your would see after drinking too much alcohol | 14:18 |
zbr | quite 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 |
corvus | i agree that could be improved | 14:19 |
zbr | that one is the easiest to fix, i will raise patch. others may be less easy. | 14:19 |
zbr | anyway, one at a time | 14:19 |
corvus | thanks :) | 14:19 |
tristanC | corvus: adding the link seems like a good improvement, perhaps that would be enough to satisfy zbr need | 14:27 |
*** irclogbot_3 has joined #zuul | 14:27 | |
zbr | btw, 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 IRC | 14:29 | |
corvus | zbr: yes, 1sec | 14:30 |
zbr | mainly a local-site-preview kind of run | 14:30 |
corvus | it's really easy and nice | 14:30 |
corvus | zbr: https://zuul-ci.org/docs/zuul/reference/developer/javascript.html | 14:30 |
corvus | zbr: the first part of that should get you the toolchain installed locally | 14:31 |
*** irclogbot_0 has joined #zuul | 14:31 | |
corvus | zbr: then just "yarn start:openstack" as described in https://zuul-ci.org/docs/zuul/reference/developer/javascript.html#development | 14:31 |
corvus | zbr: you can edit files and as soon as you save them, they'll automatically get recompiled and the browser reloads | 14:32 |
zbr | corvus: wow, really impressed, i had the toolset installed but never run that. | 14:33 |
zbr | i 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 IRC | 14:35 | |
zbr | i may be biased towards tox as being so ubiquitous on python projects, and stretch its use a bit. | 14:35 |
fungi | it'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 |
fungi | but yeah, zuul already relies on tox, so probably more sensible than make | 14:36 |
zbr | fungi: 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 |
fungi | clarkb even had a poc a few years back to replace tox with make | 14:37 |
zbr | haha | 14:37 |
fungi | following one too many non-backward-compatible behavior changes from the tox maintainers | 14:37 |
zbr | in fact many years ago I used "waf", a pure python build tool using procinples similar to make | 14:38 |
zbr | which also happens to be self-bootstraping | 14:38 |
*** irclogbot_2 has joined #zuul | 14:38 | |
zbr | i wonder if the newer version of tox (v4) is going to go towards being more generic or not. | 14:39 |
*** zxiiro has joined #zuul | 14:39 | |
*** irclogbot_2 has quit IRC | 14:39 | |
zbr | maybe the easiest approach is to just create a makefile that calls tox and yarn, w/o much fuss, only for convenience | 14:40 |
zbr | at least it would not be biased towards python or javascript world :D | 14:40 |
*** irclogbot_3 has joined #zuul | 14:41 | |
fungi | i take it yarn is a replacement for npm | 14:44 |
*** irclogbot_3 has quit IRC | 14:45 | |
*** irclogbot_0 has joined #zuul | 14:48 | |
zbr | would anyone be against adding a Makefile for development purposes? | 14:50 |
*** irclogbot_0 has quit IRC | 14:51 | |
*** bhavikdbavishi has joined #zuul | 14:53 | |
*** bhavikdbavishi1 has joined #zuul | 14:56 | |
*** bhavikdbavishi has quit IRC | 14:57 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 14:57 | |
clarkb | fungi: yes I was told by people like dstufft that make would be too difficult for python developers | 15:00 |
fungi | glad i'm not as dense as a python developer then ;) | 15:04 |
fungi | (or rather, his opinion of other python developers anyway) | 15:04 |
openstackgerrit | Merged zuul/zuul-jobs master: hlint: add haskell source code suggestions job https://review.opendev.org/722309 | 15:24 |
*** ysandeep is now known as ysandeep|away | 15:25 | |
zbr | clarkb: and you take everything such people do/say as true or good? | 15:26 |
clarkb | zbr: no but the change was pushed and no one in openstack seemed willing to take it further | 15:28 |
clarkb | zbr 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 it | 15:28 |
*** bhavikdbavishi has quit IRC | 15:29 | |
clarkb | zbr https://review.opendev.org/#/c/88698/ | 15:30 |
zbr | clarkb: looks ok but i can understand why people may prefer tox. | 15:31 |
zbr | writing makefiles requires years of software engineering, editing a ini file, far less. | 15:31 |
zbr | still, tox and make have very different goals, with little overlap. | 15:32 |
clarkb | eh we were required to write makefiles in second year of university so only 1 year required :) | 15:32 |
zbr | my only intention was to have a single launcher for various testing commands on zuul, not to replace tox | 15:32 |
zbr | like a makefile that would have a list of commands (some would be tox calls, some yarn,...) | 15:33 |
clarkb | a 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 tox | 15:33 |
zbr | is much better now | 15:33 |
clarkb | eventually maintainership of tox seems to have shifted and it got better | 15:33 |
*** bhavikdbavishi has joined #zuul | 15:33 | |
zbr | yep, i am happy that tox was salvaged | 15:33 |
clarkb | the 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 landing | 15:34 |
fungi | yeah, we covered makefiles during a seminar in c programming at my highschool (pre-university), so ~11th year students | 15:34 |
fungi | nobody seemed to have any trouble with the concept | 15:34 |
zbr | but we know well that if we try to reimplement tox features in a Makefile we may retire soon :D | 15:35 |
fungi | and 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 makefile | 15:36 |
clarkb | zbr: ya but we don't need those features imo | 15:36 |
clarkb | that was sort of the key bit of my makefile example | 15:36 |
clarkb | its ridiculously simple to have core functionality | 15:36 |
clarkb | anyway that ship has long sailed | 15:37 |
zbr | still, adding a utility Makefile should not be out of the questions, right? like one that exposes various targers, supports listting them | 15:38 |
*** irclogbot_1 has joined #zuul | 15:39 | |
zbr | corvus: really thanks for the yarn hint! is awesome. | 15:43 |
corvus | zbr: yw; tristanC, mordred ^ kudos :) | 15:43 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json https://review.opendev.org/723524 | 15:46 |
tristanC | zbr: nice :) | 15:46 |
avass | corvus, mordred: How about doing something like this for ansible collections? https://review.opendev.org/#/c/723071/ | 15:47 |
tristanC | corvus: 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 |
avass | what's the policy on adding packages to requirements.txt by the way? | 15:47 |
corvus | avass: i don't think we have any policies really, we just evaluate them as needed :) | 15:50 |
avass | corvus: 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|afk | 15:53 | |
corvus | tristanC: ah, oops, i stopped at that change; i'll proceed through 965 then | 15:53 |
tristanC | corvus: thanks a lot | 15:56 |
*** rpittau is now known as rpittau|afk | 16:07 | |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: WIP: Make task errors expandable https://review.opendev.org/723534 | 16:11 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json https://review.opendev.org/723524 | 16:13 |
*** avass has quit IRC | 16:24 | |
*** tobiash has quit IRC | 16:26 | |
*** tobias-urdin has quit IRC | 16:26 | |
*** noonedeadpunk has quit IRC | 16:26 | |
*** jkt has quit IRC | 16:26 | |
*** msuszko has quit IRC | 16:26 | |
*** kgz has quit IRC | 16:26 | |
*** AJaeger has quit IRC | 16:26 | |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: Fix pre-wrapping on console https://review.opendev.org/723603 | 16:27 |
*** irclogbot_1 has quit IRC | 16:28 | |
*** irclogbot_0 has joined #zuul | 16:30 | |
*** kgz has joined #zuul | 16:31 | |
*** avass has joined #zuul | 16:32 | |
*** bhavikdbavishi has quit IRC | 16:32 | |
zbr | corvus: clarkb : what do you think about https://review.opendev.org/#/c/650276/ ? (splitting stdout/stderr) | 16:32 |
*** tobiash has joined #zuul | 16:32 | |
*** tobias-urdin has joined #zuul | 16:32 | |
*** noonedeadpunk has joined #zuul | 16:32 | |
*** jkt has joined #zuul | 16:32 | |
*** msuszko has joined #zuul | 16:32 | |
*** AJaeger has joined #zuul | 16:32 | |
zbr | i 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 IRC | 16:35 | |
*** sgw has quit IRC | 16:35 | |
*** jcapitao has quit IRC | 16:35 | |
corvus | that'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 |
corvus | if 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 |
corvus | zbr: interleaved could be a tuple of (fd, text) so that you could color-code them | 16:38 |
corvus | (ie, the console output would use interleaved) | 16:39 |
*** ChanServ has quit IRC | 16:42 | |
*** ChanServ has joined #zuul | 16:45 | |
*** tepper.freenode.net sets mode: +o ChanServ | 16:45 | |
*** evrardjp has joined #zuul | 16:46 | |
openstackgerrit | Merged zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 16:51 |
*** sgw has joined #zuul | 16:54 | |
*** avass has quit IRC | 16:58 | |
tosky | is there a way to extract all the jobs which (recursively) inherit from a certain job but just for a specific branch (master)? | 17:02 |
tosky | https://zuul.openstack.org/jobs shows the full inheritance tree, but some of the elements may be relevant only for some stable branches | 17: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 |
corvus | tosky: 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-base | 17:07 |
corvus | it doesn't look like there are very many? | 17:07 |
corvus | though there are a lot of legacy-dsvm-base jobs | 17:07 |
corvus | tosky: 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 |
tosky | I wanted to avoid the clicks :/ | 17:09 |
tosky | I asked because the API documentation says that it's incomplete, so I wanted to be sure first | 17:09 |
openstackgerrit | Graham Hayes proposed zuul/nodepool master: Implement an Azure driver https://review.opendev.org/554432 | 17:12 |
*** yolanda has quit IRC | 17:18 | |
*** tobiash has quit IRC | 17:26 | |
*** tobias-urdin has quit IRC | 17:26 | |
*** noonedeadpunk has quit IRC | 17:26 | |
*** jkt has quit IRC | 17:26 | |
*** msuszko has quit IRC | 17:26 | |
*** AJaeger has quit IRC | 17:26 | |
*** jcapitao has joined #zuul | 17:28 | |
*** tobiash has joined #zuul | 17:29 | |
*** tobias-urdin has joined #zuul | 17:29 | |
*** noonedeadpunk has joined #zuul | 17:29 | |
*** jkt has joined #zuul | 17:29 | |
*** msuszko has joined #zuul | 17:29 | |
*** AJaeger has joined #zuul | 17:29 | |
*** jpena is now known as jpena|off | 17:35 | |
*** ChanServ has quit IRC | 17:39 | |
*** ChanServ has joined #zuul | 17:41 | |
*** tepper.freenode.net sets mode: +o ChanServ | 17:41 | |
*** avass has joined #zuul | 17:43 | |
*** jcapitao has quit IRC | 17:43 | |
avass | corvus: 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 debugging | 17:45 |
avass | corvus: 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 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Do not set buildset_fact if it's not present in results.json https://review.opendev.org/723524 | 17:53 |
corvus | avass: bummer -- i'd love it if we could ignore that without having an exception or an extra task :/ | 18:11 |
*** cdearborn has quit IRC | 18:12 | |
corvus | (maybe we should add a zuul-specific module to load results.json iff present) | 18:13 |
corvus | avass: but i agree that getting rid of the "red" is the most important thing here :) | 18:13 |
avass | corvus: yeah, I'm starting to feel that ignore_errors should be avoided | 18:13 |
corvus | avass: yes, i think we've mostly come to the conclusion we probably want faild_when instead of ignore_errors | 18:14 |
corvus | i think the tricky part here is the way the file lookup module failes | 18:14 |
corvus | fails | 18:14 |
avass | coruvs: yep | 18:14 |
corvus | i think i looked into that previously and didn't see any options we could pass to it to improve it's behavior | 18:15 |
avass | since it's a sibling i don't think there is | 18:15 |
*** jlk has joined #zuul | 18:17 | |
*** dmellado has quit IRC | 18:17 | |
*** dmellado has joined #zuul | 18:24 | |
*** dmellado has quit IRC | 18:25 | |
*** dmellado has joined #zuul | 18:33 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: tox: Use 'block: ... always: ...' instead of ignore_errors https://review.opendev.org/723640 | 18:39 |
corvus | avass: 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 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: ensure-sphinx: use failed_when: false instead of ignore_errors: true https://review.opendev.org/723642 | 18:41 |
avass | corvus: yeah, I think the block construct is a bit underused at the moment :) | 18:43 |
AJaeger | there'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/721796 | 18:44 |
avass | I'm going to try to get rid of some usage of ignore_errors in the repo :) | 18:44 |
*** dpawlik has quit IRC | 18:47 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fo: Use 'block: ... always: ...' and failed_whne instead of ignore_errors https://review.opendev.org/723643 | 18:47 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: go: Use 'block: ... always: ...' and failed_when instead of ignore_errors https://review.opendev.org/723643 | 18:47 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: ara-report: use failed_when: false instead of ignore_errors: true https://review.opendev.org/723644 | 18:49 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: k8-logs: use failed_when: instead of ignore_errors: https://review.opendev.org/723647 | 18:51 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: container-logs: use failed_when: instead of ignore_errors: https://review.opendev.org/723648 | 18:54 |
corvus | mordred, clarkb: can you look at https://review.opendev.org/701381 ? | 18:56 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: tox: Use 'block: ... always: ...' instead of ignore_errors https://review.opendev.org/723640 | 18:57 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: ensure-sphinx: use failed_when: false instead of ignore_errors: true https://review.opendev.org/723642 | 18:57 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: go: Use 'block: ... always: ...' and failed_when instead of ignore_errors https://review.opendev.org/723643 | 18:57 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: ara-report: use failed_when: false instead of ignore_errors: true https://review.opendev.org/723644 | 18:57 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-subunit-output: use failed_when: instead of ignore_errors: https://review.opendev.org/723653 | 18:57 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: add-build-sshkey: use failed_when: instead of ignore_errors: https://review.opendev.org/723654 | 18:57 |
avass | I think that's it | 18:57 |
avass | sorry for that last spam, I got a bit lost when I didn't stack them :) | 18:57 |
corvus | np, it's exciting :) | 18:57 |
corvus | mnaser, clarkb: https://review.opendev.org/721796 could use your eyes | 18:59 |
avass | corvus: 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 node | 18:59 |
avass | corvus: unless there's a better solution for that | 18:59 |
corvus | avass: 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 |
avass | corvus: do they need to be? | 19:03 |
avass | corvus: if so we should probably set the owner after synchronize instead of keeping it from the remote | 19:03 |
corvus | avass: 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 |
avass | corvus: we have the same problem with unarchive | 19:04 |
*** saneax has quit IRC | 19:04 | |
avass | corvus: by default synchronize keeps the owner/group of the files, if that owner doesn not exist on the executor the task fails | 19:05 |
corvus | right, 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 |
avass | corvus: yeah, I could update it to do that instead | 19:06 |
corvus | if 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 |
avass | i guessed so :) | 19:06 |
openstackgerrit | Merged zuul/zuul-jobs master: fetch-sphinx-tarball: use remote_src true https://review.opendev.org/721237 | 19:09 |
openstackgerrit | Merged zuul/zuul-jobs master: fetch-sphinx-tarball: Do not keep owner of archived files https://review.opendev.org/721248 | 19:20 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Set owner to executor user https://review.opendev.org/701381 | 19:28 |
avass | corvus: I'm not sure if there's a way to check the user running on the executor side in an untrusted context | 19:28 |
*** armstrongs has joined #zuul | 19:40 | |
AJaeger | corvus, 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 | |
avass | AJaeger: we should probably do that | 19:47 |
AJaeger | avass: can you do, link to the earlier zuul-discuss email and the review and give an additional 2 weeks time, please? | 19:48 |
avass | AJaeger: sure, I have to leave in a minute sicne it's getting late here. But I can do it tomorrow | 19:48 |
avass | and I want to get my i3 setup up on my laptop :) | 19:49 |
corvus | do 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 IRC | 19:50 | |
avass | corvus: you mean fail with a message to use ensure-* instead? yeah that could be good | 19: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 #zuul | 19:51 | |
AJaeger | avass: https://review.opendev.org/#/c/719401 needs rebaseing - I'm just ping dependencies | 19:52 |
AJaeger | And 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 |
AJaeger | corvus: could you merge https://review.opendev.org/#/c/719402/ for x/pbrx, please? | 19:53 |
openstackgerrit | Albin Vass proposed zuul/zuul-operator master: Use ensure-* roles https://review.opendev.org/719401 | 19:53 |
AJaeger | infra-root, could you review https://review.opendev.org/#/c/719404/ for gerrit-lib so that we can retire ensure roles, please? | 19:54 |
corvus | yeah, 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 |
openstackgerrit | Merged zuul/zuul-jobs master: tox: allow running default envlist in tox https://review.opendev.org/721796 | 19:56 |
corvus | we should maybe add a 'warnings' attr to zuul_return so we can return zuul warnings in jobs | 19:57 |
corvus | then we could have something show up on the report | 19:57 |
AJaeger | that sounds cool | 19:57 |
clarkb | in #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 |
clarkb | its 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 |
corvus | AJaeger: ++ | 19:59 |
corvus | clarkb: oh that's a good question -- mordred, tristanC: ping | 20:00 |
*** Shrews has left #zuul | 20:00 | |
corvus | we were serving the javascript-content tarball | 20:00 |
clarkb | the 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 noticeable | 20:00 |
avass | corvus, AJaeger: yeah that sounds cool | 20:00 |
AJaeger | avass: FYI, most of you ignore_error changes are in merge conflict now - something for tomorrow... | 20:02 |
corvus | tobiash: 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 |
avass | AJaeger: ah, yeah I'll fix that tomorrow as well | 20:03 |
* AJaeger signs off now as well - good night everybody | 20:03 | |
avass | same here, good night! | 20:05 |
tristanC | clarkb: corvus: iirc we are using create-react-app build toolchain which should produce a fairly optimized build | 20:05 |
clarkb | tristanC: it looks like whitespace is removed but var names are still expanded and the like | 20:05 |
clarkb | tristanC: https://zuul.opendev.org/static/js/main.7c3d47f8.js if you want to see what we are serving | 20:06 |
tobiash | corvus: thanks for the info. Did it clean too much or do you suspect some sort of race? | 20:07 |
tristanC | clarkb: i'm not sure what is suspicious in that link, what var names are you refering too? | 20:08 |
clarkb | tristanC: createElement etc | 20:08 |
clarkb | tristanC: it seems like the libraries and such aren't minimized too? | 20:08 |
clarkb | parentNode | 20:09 |
tristanC | those are standard js/dom function, iirc they are usually left as-is | 20:10 |
clarkb | tristanC: looks like we also have some fairly verbose error log messages? | 20:10 |
clarkb | tristanC: fwiw I've just pulled the old tarball and it is the same 3.2MB so we aren't a regression there | 20:12 |
clarkb | I wonder if our old apache config was serving that compressed though | 20:12 |
corvus | tobiash: 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 race | 20:12 |
tristanC | clarkb: there are probably more efficient packer, though iirc create-react-app pick one that enable runtime debugging. | 20:12 |
corvus | tobiash: 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 reverted | 20:14 |
corvus | tobiash: (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 |
corvus | tobiash: (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 |
clarkb | tristanC: 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 gdb | 20:17 |
clarkb | also for most users I expect they cache the file and are fine for a while | 20:18 |
tobiash | Hrm, interesting fetch_head is a ref which should inhibit pruning that object | 20:19 |
clarkb | I don't know why this particular user's browser was not caching the js file | 20:19 |
tobiash | Maybe we should set the prune threshold to a day instead of now | 20:19 |
corvus | tobiash: is it really a ref? | 20:20 |
corvus | https://static.opendev.org/user/corvus/oo.tgz has the git repo i saved on one of the failing executors | 20:22 |
tobiash | I assume it's a ref similar to head | 20:24 |
corvus | hrm, that looks like it's working -- let me double check that's the right copy | 20:24 |
*** zxiiro has quit IRC | 20:24 | |
corvus | drat, i'm unable to reproduce that error using the tarball; maybe the repo was just in the wrong state when i made it | 20:30 |
fungi | i suppose we could try reapplying that tuning to just one of our executors in opendev | 20:32 |
corvus | i 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_HEAD | 20:32 |
corvus | that last command is the command which failed | 20:32 |
clarkb | rereviewing 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 see | 20:32 |
fungi | it 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 them | 20:33 |
corvus | fungi: 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 |
clarkb | mordred: ^ 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 think | 20:33 |
corvus | fungi: good point, the retry logic should keep it at a low level | 20:33 |
clarkb | oh ok we are still doing that for json | 20:34 |
fungi | once we realized there was a problem, we were able to find evidence of it dating back on that one executor to when it got rebooted | 20:35 |
corvus | fungi: was that for the gc patch? because that merged very recently | 20:36 |
fungi | corvus: oh, right maybe it was the cleaning change | 20:36 |
corvus | yeah, the gc change only merged thursday | 20:37 |
fungi | okay, yeah it was the refs cleaning then | 20:37 |
fungi | sorry, we wound up dealing with both in the same window, i mixed them up | 20:37 |
*** Goneri has quit IRC | 21:05 | |
*** igordc has joined #zuul | 21:07 | |
*** jrichard13 has joined #zuul | 21:07 | |
*** jrichard13 has quit IRC | 21:07 | |
*** jrichard has joined #zuul | 21:08 | |
*** cdearborn has joined #zuul | 21:14 | |
*** jrichard has quit IRC | 22:35 | |
mordred | corvus: 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 IRC | 23:02 | |
mordred | corvus: I think we can just copy {{ ca_dir }}/buildset-registry.crt into the builder container and then run update-ca-certificates in there | 23:02 |
*** igordc has quit IRC | 23:14 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!