Friday, 2021-01-08

*** ikhan has joined #zuul00:02
*** holser has quit IRC00:05
*** paladox has quit IRC00:13
*** paladox has joined #zuul00:15
*** jamesmcarthur has quit IRC01:21
*** jamesmcarthur has joined #zuul01:21
*** armstrongs has joined #zuul01:30
*** armstrongs has quit IRC01:39
*** saneax has joined #zuul01:58
*** jamesmcarthur has quit IRC02:39
*** jamesmcarthur has joined #zuul02:41
*** jamesmcarthur has quit IRC02:45
*** bhavikdbavishi has joined #zuul02:54
*** bhavikdbavishi1 has joined #zuul02:59
*** bhavikdbavishi has quit IRC03:00
*** bhavikdbavishi1 is now known as bhavikdbavishi03:00
*** jamesmcarthur has joined #zuul03:03
*** jamesmcarthur has quit IRC03:04
*** jamesmcarthur has joined #zuul03:04
*** bhavikdbavishi has quit IRC03:22
*** jamesmcarthur has quit IRC03:31
*** jamesmcarthur has joined #zuul03:36
*** jamesmcarthur has quit IRC03:36
*** jamesmcarthur has joined #zuul03:36
*** bhavikdbavishi has joined #zuul03:38
*** bhavikdbavishi1 has joined #zuul03:40
*** bhavikdbavishi has quit IRC03:42
*** bhavikdbavishi1 is now known as bhavikdbavishi03:42
*** hamalq has quit IRC04:01
*** bhavikdbavishi has quit IRC04:07
*** bhavikdbavishi has joined #zuul04:09
*** jamesmcarthur has quit IRC04:19
*** jamesmcarthur has joined #zuul04:20
*** jamesmcarthur has quit IRC04:25
*** jamesmcarthur has joined #zuul04:26
*** jamesmcarthur has quit IRC04:31
*** jamesmcarthur has joined #zuul04:32
*** ykarel has joined #zuul05:05
*** evrardjp has quit IRC05:33
*** evrardjp has joined #zuul05:33
*** bhavikdbavishi has quit IRC05:47
*** bhavikdbavishi has joined #zuul05:53
*** bhavikdbavishi1 has joined #zuul05:55
*** jamesmcarthur has quit IRC05:55
*** jamesmcarthur has joined #zuul05:56
*** bhavikdbavishi has quit IRC05:57
*** bhavikdbavishi1 is now known as bhavikdbavishi05:57
*** jamesmcarthur has quit IRC06:01
*** jamesmcarthur has joined #zuul06:15
*** bhavikdbavishi has quit IRC06:31
*** bhavikdbavishi has joined #zuul06:32
*** bhavikdbavishi has quit IRC06:41
*** jpena has joined #zuul07:41
*** jcapitao has joined #zuul07:41
*** zenkuro has joined #zuul07:47
*** hashar has joined #zuul08:07
*** snapiri has quit IRC08:15
*** jamesmcarthur has quit IRC08:16
*** rpittau|afk is now known as rpittau08:32
*** ykarel is now known as ykarel|lunch08:39
*** jamesmcarthur has joined #zuul08:47
*** jamesmcarthur has quit IRC08:52
*** tosky has joined #zuul08:56
*** hashar has quit IRC09:28
*** hashar has joined #zuul09:28
*** ykarel|lunch is now known as ykarel09:54
*** ttx has quit IRC10:16
*** ttx has joined #zuul10:17
*** hashar is now known as hasharLunch10:43
*** jcapitao is now known as jcapitao_afk10:53
*** jamesmcarthur has joined #zuul11:04
*** jamesmcarthur has quit IRC11:09
*** jcapitao_afk is now known as jcapitao12:31
*** hasharLunch is now known as hashar12:32
*** jpena is now known as jpena|lunch12:32
*** SotK has quit IRC12:52
*** SotK has joined #zuul12:52
*** rlandy has joined #zuul13:03
*** rfolco has joined #zuul13:09
*** ikhan has quit IRC13:26
*** jpena|lunch is now known as jpena13:29
*** ikhan has joined #zuul13:30
*** zenkuro has quit IRC13:51
*** zenkuro has joined #zuul13:52
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation.  https://review.opendev.org/c/zuul/zuul-jobs/+/76480814:08
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation.  https://review.opendev.org/c/zuul/zuul-jobs/+/76480814:15
*** rpittau is now known as rpittau|afk14:46
*** jamesmcarthur has joined #zuul15:06
*** jamesmcarthur has quit IRC15:10
openstackgerritMatthieu Huin proposed zuul/zuul master: web UI: user login with OpenID Connect  https://review.opendev.org/c/zuul/zuul/+/73408215:30
openstackgerritMatthieu Huin proposed zuul/zuul master: Add authentication-realm attribute to tenants  https://review.opendev.org/c/zuul/zuul/+/73558615:30
openstackgerritMatthieu Huin proposed zuul/zuul master: web UI: allow a privileged user to dequeue a change  https://review.opendev.org/c/zuul/zuul/+/73485015:30
openstackgerritMatthieu Huin proposed zuul/zuul master: web UI: allow a privileged user to re-enqueue a change  https://review.opendev.org/c/zuul/zuul/+/73677215:30
openstackgerritMatthieu Huin proposed zuul/zuul master: Web UI: allow a privileged user to request autohold  https://review.opendev.org/c/zuul/zuul/+/76811515:30
openstackgerritMatthieu Huin proposed zuul/zuul master: Example Docker compose: keycloak integration  https://review.opendev.org/c/zuul/zuul/+/76994315:30
mhuis there a way to build the docker compose in the documentation from my current branch rather than fetching the zuul container from dockerhub?15:32
mhuat least the zuul-web container?15:32
mhualso, quick question: how come zuul.opendev.org is running 3.19.2 yet that tag doesn't seem to exist in the repo?15:36
mhuI only see 3.19.115:36
openstackgerritMatthieu Huin proposed zuul/zuul master: Web UI: add Autoholds page  https://review.opendev.org/c/zuul/zuul/+/76819915:38
mhuwow, I just had a job fail because of docker's rate limiting ... quote: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit15:45
fungimhu: let me try to answer your questions in order15:45
fungimhu: the zuul containers published to dockerhub are build by zuul jobs, so the commands those run should be able to be integrated as you see fit15:46
fungimhu: for zuul-web in particular though, there's a separate developer document explaining how to test it locally from source without needing to do all that15:46
fungi(at least the javascript/dashboard parts)15:47
mhufungi, right, I've been developing this way, but I wanted to test https://review.opendev.org/c/zuul/zuul/+/769943 with the full docker compose. The idea is to provide an easy way for others to test/experiment with the authenticated web UI15:48
fungimhu: zuul.opendev.org is continuously deployed from the containers built using the zuul/zuul master branch state, and pbr "guesses" what the next possible version will be. since the most recent tag is 3.19.1 and there are additional commits merged after, it's guessing the next version will need to be at least 3.19.215:48
mhuah, makes sense15:50
mhuthanks fungi15:50
mhuare you aware of the dockerhub throttling? I hit this on a zuul-build-image job, logs are https://84bcfe3395935572b3b7-c14a90bb632d28bbb550a801b65dbbaa.ssl.cf1.rackcdn.com/735586/14/check/zuul-build-image/15e4d3c/15:52
mhuif you knew already, disregard this15:52
fungiyes, we see it from time to time. jobs using our dockerhub proxy in each provider may see it if dockerhub has decided that proxy has queried too many manifests recently. jobs not using the proxies may hit it in our ipv6-only providers because the nodes there share an ipv4 nat for egress and dockerhub doesn't have aaaa records in dns. also in other providers where our nodes tend to reuse the same addresses from15:55
fungia small allocation pool, we may see it if a previous job requested lots of things from dockerhub using that same address15:55
fungiif it gets bad, we've talked about trying to do some fancy tricks with mod_proxy (or switching to squid) to proxy authenticated manifest requests. barring that, there's the possibility of extending zuul-registry to be able to serve as a smarter passthrough cache and running an instance of that for the purpose15:57
*** jamesmcarthur has joined #zuul16:01
clarkbmhu: fungi: you should be able to docker build a zuul-web locally and then tag it appropriate or otherwise identify it and then tell docker-compose to use that version16:04
clarkb`docker build --target zuul-web --tag mhu-testing` then in docker-compose.yaml set image: zuul-web:mhu-testing16:05
mhuclarkb, awesome that's exactly what I need, thanks!16:05
clarkbnote I haven't tested that, but something along those lines should work16:06
openstackgerritMatthieu Huin proposed zuul/zuul master: Pin pyjwt to 2.0.0 and fix issues due to version bump  https://review.opendev.org/c/zuul/zuul/+/76831216:16
zbrclarkb: mhu: very low-hanging fix related to py39: https://review.opendev.org/c/zuul/zuul/+/76625316:17
clarkbzbr: left a question on that16:22
*** hashar has quit IRC16:25
*** ykarel_ has joined #zuul16:26
*** ykarel has quit IRC16:29
openstackgerritSorin Sbârnea proposed zuul/zuul master: Remove importlib-resources pinning  https://review.opendev.org/c/zuul/zuul/+/76625316:34
zbrclarkb: i wonder how can we get more eyes on https://review.opendev.org/c/opendev/gear/+/70826716:36
zbrthe current state of gear is that it does not even import on bsd, side effect being that i cannot build docs or even run zuul-* cli tools with --help.16:37
clarkbwe also cannot test it on bsd so this isn't surprising (nor necessarily a bug)16:37
clarkbI've tried to help but updating the revert with what I think would fix things but I was not really driving that16:38
clarkbI was hoping people with bsd systems would pick it up16:38
clarkband ya looks like tobiash has rereviewed it which I think was a big thing we wanted to see happen16:38
zbrin theory we could test on freebsd but nobody had time time make DIB change for adding it.16:39
corvusto be clear, i (as the original author of gear) don't see that as a bug -- it's intentionally designed to be non-portable (linux-only) in order to be exceptionally high-performance.  i don't object to bsd support, but it adds a lot of complexity (as evidenced by the fact that when someone added it, we had to revert it due to bugs).16:40
clarkbright so we can't :P16:40
zbri tried earlier this week but i never find enough time to invest in corner cases16:40
clarkbzbr: its actually fairly complicated beacuse bsd tools use a different executable format than linux iirc. And you need bsd tools for bsd fs operations last I checked16:41
clarkbI'm sure it is doable but not trivial16:41
zbri neither care about using gear on bsd, but i find a huge PITA to not be able even build zuul docs on my desktop.16:41
corvusif someone wants to continue to drive that, i continue to not object, but i'd expect a high level of commitment from them, and once again, if there's an issue, we'll revert the whole thing back out again until it's fixed.  personally, i don't think it's worth anyone's time since zuul is likely to move away from gearman anyway.16:41
zbrthere is a big difference between breaking unrelated jobs and making it effectively usable.16:41
corvusno jobs are broken16:42
zbrwell,  "tox -e docs" cannot run.16:43
corvusit can't run on an unsupported platform.  that's not a bug16:43
corvusanyway, i don't think we're going to merge any bsd changes to gear only for the purpose of making the zuul docs job run on bsd.  i think we would only merge bsd support in gear if someone really wanted bsd support in gear for its own purpose.  that's the kind of commitment we'd need, but i don't think we have that right now, so i'd suggest looking into an alternative.16:45
corvuszbr: maybe there's some way to build docs without running the commands?  maybe an extra arg to sphinx-build or something to turn them off?  then you could build locally for testing16:46
zbri checked and gear is imported only by 3 plugins, I could easily to if os-plaform check and evoid loading htem.16:46
corvusi don't think we should merge a change like that to zuul16:46
zbrthe reality is that "zuul" has a dependency on "gear", including the cpi.16:46
zbrcli16:46
zbrif we make it weak, we can avoid the problem.16:46
clarkbis that still true with the zuul-cli split out? I think not because that talks to the http api?16:50
clarkbthat seems like a reasonable path forwardwithout overthinking the gear stuff16:51
corvusclarkb: you are correct16:51
zbrwhich path?16:52
clarkbzbr: "use zuul-cli on bsd and windows"16:52
mhuzuul/zuul-client is indeed REST only16:52
clarkber use zuul-client16:52
mhuthe zuul admin CLI that is still in zuul/zuul uses gearman however16:53
clarkbmhu: right but thats fine because you can run it on the zuul server directly16:53
corvusyep, but its days are numbered16:53
mhuexactly16:53
clarkband since zuul requires gear that requires linux and meh16:53
zbrthe only thing i wanted to address was to be able to build the docs.16:53
clarkbzbr: gear doesn't appear to be in the docs tox target dep list (and I don't think another dep is pulling it in). Do you know where in the docs it needs gear?16:54
corvusclarkb: --help output runs the zuul cli commands16:54
clarkbah16:54
zbrthere are two calls inside the docs, and gear is imported by gitlab, github and pagure connection  plugins.16:59
zbrif we skip them on unsupported platforms the cli starts to work.16:59
zbror at least --help works, which is enough for the docs.16:59
clarkb`.. program-output:: zuul * --help` is what the docs contain that import gear16:59
zbryep17:00
*** rlandy is now known as rlandy|brb17:00
zbrIMHO, it would make sense to make these imports platform dependent.17:01
clarkbI'm still not sure I agree with that. We publish the docs so they are publicly accessible without being built locally.17:01
clarkbBut also gear will be removed in the future so maybe effort shold be spent on that v4 and v5 work instead17:02
*** jpena is now known as jpena|off17:02
*** jcapitao has quit IRC17:03
*** jamesmcarthur has quit IRC17:04
* zbr finds hard to understand the logic: better to wait for an hour or more to discover that you docs contribution does not render correctly, instead of testing it locally in a minute or less.17:05
clarkbI mea nyou can still test it locally right? Both windows and osx offer a linux containers system17:06
clarkbI think it is more an acknowledgement of limited resources. We are able to support linux because it is where the service runs and most of the developers develop. Expanding beyond that adds quite a bit of complicate particularly for testing17:07
openstackgerritMatthieu Huin proposed zuul/zuul master: Example Docker compose: keycloak integration  https://review.opendev.org/c/zuul/zuul/+/76994317:10
mhuclarkb, fungi fyi there's a "build" parameter in docker-compose files that lets you use a local container in the compose17:11
tristanCzbr: perhaps this would work: `touch gear.py && PYTHONPATH=$(pwd) ./.tox/docs/bin/sphinx-build ..`17:11
zbrtristanC: yeah but it means you need to mess the code to build, is not that it would make it work for anyone cloning the code.17:13
zbrin fact I would find even something like "try: import gear; except: pass" kind of trick as sorting the issue.17:14
zbrbut apparently even if gear is going away I do observe that nobody wants to agree on making that import weak.17:14
clarkbzbr: beacuse it could introduce bugs with the tools. If you import gear and it fails for a valid reason but the command doesn't break until later17:15
tristanCzbr: i agree we shouldn't make that import weak simply to support building the doc on an unsupported platform17:16
clarkbwhen you actually need gear in the command a weak import will be a problem if there are actual failures17:16
zbri feel frustrated because on one hand i am told that improving the docs is welcome but on the other hand.... i do not see much openness when it comes to what a user may want to use. I guess I should forget about touching the docs.17:17
zbri see it as bug: cli fails because an unneeded import is done, clearly gear is not needed for all CLI executions.17:19
zbrclarkb: but how about if platform == 'linux' approach? we have lots of options.17:20
clarkbzbr: how do you handle the case where someone on os x is trying to use those commands, the import silently "succeeds" but then things fail oddly later17:20
clarkbcurrently the gear import fails and its pretty clear why17:21
*** ykarel_ is now known as ykarel17:21
tristanCzbr: i would be happy to setup a shell account on a our devel node where you could build the docs and run zuul tests17:21
fungiso can we update the docs build to not bother with program-output and instead just refer to the zuul-client docs?17:22
zbrtristanC: is not that I do not have enough boxes around.17:22
corvusfungi: there are other commands17:22
fungiahh17:22
*** rlandy|brb is now known as rlandy17:23
fungiokay so not everything will be covered by zuul-client i guess17:23
corvusfungi: zuul-scheduler, zuul-executor....17:23
fungiright, i forgot about the various entrypoints17:23
clarkbone option might be to do the gear import late so that help commands work. Rather than making it conditional17:25
clarkb(I havne't looked at the import paths so dunno if that is possible)17:25
corvusclarkb: i don't think failing after --help is an improvement17:25
fungiright, lazy importing is what i assumed was meant by "weak dependency"17:26
clarkbfungi: the examples given were try except and platform checks17:26
corvusif the program is run on an unsupported platform, it should say so asap.17:26
tristanCcould we trick the tox docs target to use a fake gear module to mitigate zbr's problem?17:28
openstackgerritSorin Sbârnea proposed zuul/zuul master: POC: Make gear importing lazy  https://review.opendev.org/c/zuul/zuul/+/76996817:28
zbrthe example above fixes the docs building. now is up to you to decide on how to achieve it.17:30
corvusi have decided17:30
corvusseveral alternatives have been suggested, they seem quite reasonable and achievable.  i don't think the tail needs to wag the dog on this.17:31
corvusour review time is limited, let's spend it wisely.17:31
mhuhmm I can't seem to be able to build the zuul-web container locally on master, it ends with error: [Errno 17] File exists: '../zuul/web/static' -> 'web/build'17:34
clarkbmhu: I wonder if you need a clean tree?17:37
mhuclarkb, possible. the problem is clearly on my side, there's been a build uploaded to dockerhub not 2 days ago17:38
*** ykarel has quit IRC17:42
openstackgerritSorin Sbârnea proposed zuul/zuul master: Clarify supported platforms  https://review.opendev.org/c/zuul/zuul/+/76997217:57
openstackgerritMerged zuul/zuul master: Remove importlib-resources pinning  https://review.opendev.org/c/zuul/zuul/+/76625318:10
*** saneax has quit IRC18:21
*** hamalq has joined #zuul19:10
*** jamesmcarthur has joined #zuul19:23
*** holser has joined #zuul19:31
*** hamalq has quit IRC19:33
*** hamalq has joined #zuul19:33
*** jamesmcarthur has quit IRC20:11
*** jamesmcarthur has joined #zuul20:22
*** jamesmcarthur has quit IRC20:39
openstackgerritlotorev vitaly proposed zuul/zuul-jobs master: Clarity tox_environment accepts dictionary not list  https://review.opendev.org/c/zuul/zuul-jobs/+/76943320:43
openstackgerritlotorev vitaly proposed zuul/zuul-jobs master: Document Python siblings handling for tox role  https://review.opendev.org/c/zuul/zuul-jobs/+/76882320:43
openstackgerritTristan Cacqueray proposed zuul/zuul master: Get executor job params  https://review.opendev.org/c/zuul/zuul/+/60707820:54
*** rfolco has quit IRC21:11
*** ikhan has quit IRC21:11
*** ikhan has joined #zuul21:14
*** cloudnull has quit IRC21:18
*** rlandy has quit IRC21:19
*** hashar has joined #zuul21:24
*** ikhan has quit IRC21:27
*** cloudnull has joined #zuul21:28
*** hashar has quit IRC21:29
openstackgerritTristan Cacqueray proposed zuul/zuul master: Separate out executor server from runner  https://review.opendev.org/c/zuul/zuul/+/60707921:30
*** ikhan has joined #zuul21:32
*** holser has quit IRC21:45
*** sduthil has quit IRC21:50
*** jamesmcarthur has joined #zuul22:14
*** jamesmcarthur has quit IRC22:17
*** ikhan has quit IRC23:08

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!