*** ikhan has joined #zuul | 00:02 | |
*** holser has quit IRC | 00:05 | |
*** paladox has quit IRC | 00:13 | |
*** paladox has joined #zuul | 00:15 | |
*** jamesmcarthur has quit IRC | 01:21 | |
*** jamesmcarthur has joined #zuul | 01:21 | |
*** armstrongs has joined #zuul | 01:30 | |
*** armstrongs has quit IRC | 01:39 | |
*** saneax has joined #zuul | 01:58 | |
*** jamesmcarthur has quit IRC | 02:39 | |
*** jamesmcarthur has joined #zuul | 02:41 | |
*** jamesmcarthur has quit IRC | 02:45 | |
*** bhavikdbavishi has joined #zuul | 02:54 | |
*** bhavikdbavishi1 has joined #zuul | 02:59 | |
*** bhavikdbavishi has quit IRC | 03:00 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 03:00 | |
*** jamesmcarthur has joined #zuul | 03:03 | |
*** jamesmcarthur has quit IRC | 03:04 | |
*** jamesmcarthur has joined #zuul | 03:04 | |
*** bhavikdbavishi has quit IRC | 03:22 | |
*** jamesmcarthur has quit IRC | 03:31 | |
*** jamesmcarthur has joined #zuul | 03:36 | |
*** jamesmcarthur has quit IRC | 03:36 | |
*** jamesmcarthur has joined #zuul | 03:36 | |
*** bhavikdbavishi has joined #zuul | 03:38 | |
*** bhavikdbavishi1 has joined #zuul | 03:40 | |
*** bhavikdbavishi has quit IRC | 03:42 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 03:42 | |
*** hamalq has quit IRC | 04:01 | |
*** bhavikdbavishi has quit IRC | 04:07 | |
*** bhavikdbavishi has joined #zuul | 04:09 | |
*** jamesmcarthur has quit IRC | 04:19 | |
*** jamesmcarthur has joined #zuul | 04:20 | |
*** jamesmcarthur has quit IRC | 04:25 | |
*** jamesmcarthur has joined #zuul | 04:26 | |
*** jamesmcarthur has quit IRC | 04:31 | |
*** jamesmcarthur has joined #zuul | 04:32 | |
*** ykarel has joined #zuul | 05:05 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #zuul | 05:33 | |
*** bhavikdbavishi has quit IRC | 05:47 | |
*** bhavikdbavishi has joined #zuul | 05:53 | |
*** bhavikdbavishi1 has joined #zuul | 05:55 | |
*** jamesmcarthur has quit IRC | 05:55 | |
*** jamesmcarthur has joined #zuul | 05:56 | |
*** bhavikdbavishi has quit IRC | 05:57 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 05:57 | |
*** jamesmcarthur has quit IRC | 06:01 | |
*** jamesmcarthur has joined #zuul | 06:15 | |
*** bhavikdbavishi has quit IRC | 06:31 | |
*** bhavikdbavishi has joined #zuul | 06:32 | |
*** bhavikdbavishi has quit IRC | 06:41 | |
*** jpena has joined #zuul | 07:41 | |
*** jcapitao has joined #zuul | 07:41 | |
*** zenkuro has joined #zuul | 07:47 | |
*** hashar has joined #zuul | 08:07 | |
*** snapiri has quit IRC | 08:15 | |
*** jamesmcarthur has quit IRC | 08:16 | |
*** rpittau|afk is now known as rpittau | 08:32 | |
*** ykarel is now known as ykarel|lunch | 08:39 | |
*** jamesmcarthur has joined #zuul | 08:47 | |
*** jamesmcarthur has quit IRC | 08:52 | |
*** tosky has joined #zuul | 08:56 | |
*** hashar has quit IRC | 09:28 | |
*** hashar has joined #zuul | 09:28 | |
*** ykarel|lunch is now known as ykarel | 09:54 | |
*** ttx has quit IRC | 10:16 | |
*** ttx has joined #zuul | 10:17 | |
*** hashar is now known as hasharLunch | 10:43 | |
*** jcapitao is now known as jcapitao_afk | 10:53 | |
*** jamesmcarthur has joined #zuul | 11:04 | |
*** jamesmcarthur has quit IRC | 11:09 | |
*** jcapitao_afk is now known as jcapitao | 12:31 | |
*** hasharLunch is now known as hashar | 12:32 | |
*** jpena is now known as jpena|lunch | 12:32 | |
*** SotK has quit IRC | 12:52 | |
*** SotK has joined #zuul | 12:52 | |
*** rlandy has joined #zuul | 13:03 | |
*** rfolco has joined #zuul | 13:09 | |
*** ikhan has quit IRC | 13:26 | |
*** jpena|lunch is now known as jpena | 13:29 | |
*** ikhan has joined #zuul | 13:30 | |
*** zenkuro has quit IRC | 13:51 | |
*** zenkuro has joined #zuul | 13:52 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 14:08 |
---|---|---|
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 14:15 |
*** rpittau is now known as rpittau|afk | 14:46 | |
*** jamesmcarthur has joined #zuul | 15:06 | |
*** jamesmcarthur has quit IRC | 15:10 | |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: user login with OpenID Connect https://review.opendev.org/c/zuul/zuul/+/734082 | 15:30 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add authentication-realm attribute to tenants https://review.opendev.org/c/zuul/zuul/+/735586 | 15:30 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: allow a privileged user to dequeue a change https://review.opendev.org/c/zuul/zuul/+/734850 | 15:30 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: allow a privileged user to re-enqueue a change https://review.opendev.org/c/zuul/zuul/+/736772 | 15:30 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Web UI: allow a privileged user to request autohold https://review.opendev.org/c/zuul/zuul/+/768115 | 15:30 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Example Docker compose: keycloak integration https://review.opendev.org/c/zuul/zuul/+/769943 | 15:30 |
mhu | is 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 |
mhu | at least the zuul-web container? | 15:32 |
mhu | also, 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 |
mhu | I only see 3.19.1 | 15:36 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Web UI: add Autoholds page https://review.opendev.org/c/zuul/zuul/+/768199 | 15:38 |
mhu | wow, 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-limit | 15:45 |
fungi | mhu: let me try to answer your questions in order | 15:45 |
fungi | mhu: 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 fit | 15:46 |
fungi | mhu: 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 that | 15:46 |
fungi | (at least the javascript/dashboard parts) | 15:47 |
mhu | fungi, 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 UI | 15:48 |
fungi | mhu: 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.2 | 15:48 |
mhu | ah, makes sense | 15:50 |
mhu | thanks fungi | 15:50 |
mhu | are 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 |
mhu | if you knew already, disregard this | 15:52 |
fungi | yes, 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 from | 15:55 |
fungi | a small allocation pool, we may see it if a previous job requested lots of things from dockerhub using that same address | 15:55 |
fungi | if 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 purpose | 15:57 |
*** jamesmcarthur has joined #zuul | 16:01 | |
clarkb | mhu: 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 version | 16:04 |
clarkb | `docker build --target zuul-web --tag mhu-testing` then in docker-compose.yaml set image: zuul-web:mhu-testing | 16:05 |
mhu | clarkb, awesome that's exactly what I need, thanks! | 16:05 |
clarkb | note I haven't tested that, but something along those lines should work | 16:06 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Pin pyjwt to 2.0.0 and fix issues due to version bump https://review.opendev.org/c/zuul/zuul/+/768312 | 16:16 |
zbr | clarkb: mhu: very low-hanging fix related to py39: https://review.opendev.org/c/zuul/zuul/+/766253 | 16:17 |
clarkb | zbr: left a question on that | 16:22 |
*** hashar has quit IRC | 16:25 | |
*** ykarel_ has joined #zuul | 16:26 | |
*** ykarel has quit IRC | 16:29 | |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul master: Remove importlib-resources pinning https://review.opendev.org/c/zuul/zuul/+/766253 | 16:34 |
zbr | clarkb: i wonder how can we get more eyes on https://review.opendev.org/c/opendev/gear/+/708267 | 16:36 |
zbr | the 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 |
clarkb | we also cannot test it on bsd so this isn't surprising (nor necessarily a bug) | 16:37 |
clarkb | I've tried to help but updating the revert with what I think would fix things but I was not really driving that | 16:38 |
clarkb | I was hoping people with bsd systems would pick it up | 16:38 |
clarkb | and ya looks like tobiash has rereviewed it which I think was a big thing we wanted to see happen | 16:38 |
zbr | in theory we could test on freebsd but nobody had time time make DIB change for adding it. | 16:39 |
corvus | to 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 |
clarkb | right so we can't :P | 16:40 |
zbr | i tried earlier this week but i never find enough time to invest in corner cases | 16:40 |
clarkb | zbr: 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 checked | 16:41 |
clarkb | I'm sure it is doable but not trivial | 16:41 |
zbr | i 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 |
corvus | if 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 |
zbr | there is a big difference between breaking unrelated jobs and making it effectively usable. | 16:41 |
corvus | no jobs are broken | 16:42 |
zbr | well, "tox -e docs" cannot run. | 16:43 |
corvus | it can't run on an unsupported platform. that's not a bug | 16:43 |
corvus | anyway, 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 |
corvus | zbr: 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 testing | 16:46 |
zbr | i checked and gear is imported only by 3 plugins, I could easily to if os-plaform check and evoid loading htem. | 16:46 |
corvus | i don't think we should merge a change like that to zuul | 16:46 |
zbr | the reality is that "zuul" has a dependency on "gear", including the cpi. | 16:46 |
zbr | cli | 16:46 |
zbr | if we make it weak, we can avoid the problem. | 16:46 |
clarkb | is that still true with the zuul-cli split out? I think not because that talks to the http api? | 16:50 |
clarkb | that seems like a reasonable path forwardwithout overthinking the gear stuff | 16:51 |
corvus | clarkb: you are correct | 16:51 |
zbr | which path? | 16:52 |
clarkb | zbr: "use zuul-cli on bsd and windows" | 16:52 |
mhu | zuul/zuul-client is indeed REST only | 16:52 |
clarkb | er use zuul-client | 16:52 |
mhu | the zuul admin CLI that is still in zuul/zuul uses gearman however | 16:53 |
clarkb | mhu: right but thats fine because you can run it on the zuul server directly | 16:53 |
corvus | yep, but its days are numbered | 16:53 |
mhu | exactly | 16:53 |
clarkb | and since zuul requires gear that requires linux and meh | 16:53 |
zbr | the only thing i wanted to address was to be able to build the docs. | 16:53 |
clarkb | zbr: 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 |
corvus | clarkb: --help output runs the zuul cli commands | 16:54 |
clarkb | ah | 16:54 |
zbr | there are two calls inside the docs, and gear is imported by gitlab, github and pagure connection plugins. | 16:59 |
zbr | if we skip them on unsupported platforms the cli starts to work. | 16:59 |
zbr | or at least --help works, which is enough for the docs. | 16:59 |
clarkb | `.. program-output:: zuul * --help` is what the docs contain that import gear | 16:59 |
zbr | yep | 17:00 |
*** rlandy is now known as rlandy|brb | 17:00 | |
zbr | IMHO, it would make sense to make these imports platform dependent. | 17:01 |
clarkb | I'm still not sure I agree with that. We publish the docs so they are publicly accessible without being built locally. | 17:01 |
clarkb | But also gear will be removed in the future so maybe effort shold be spent on that v4 and v5 work instead | 17:02 |
*** jpena is now known as jpena|off | 17:02 | |
*** jcapitao has quit IRC | 17:03 | |
*** jamesmcarthur has quit IRC | 17: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 | |
clarkb | I mea nyou can still test it locally right? Both windows and osx offer a linux containers system | 17:06 |
clarkb | I 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 testing | 17:07 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Example Docker compose: keycloak integration https://review.opendev.org/c/zuul/zuul/+/769943 | 17:10 |
mhu | clarkb, fungi fyi there's a "build" parameter in docker-compose files that lets you use a local container in the compose | 17:11 |
tristanC | zbr: perhaps this would work: `touch gear.py && PYTHONPATH=$(pwd) ./.tox/docs/bin/sphinx-build ..` | 17:11 |
zbr | tristanC: 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 |
zbr | in fact I would find even something like "try: import gear; except: pass" kind of trick as sorting the issue. | 17:14 |
zbr | but apparently even if gear is going away I do observe that nobody wants to agree on making that import weak. | 17:14 |
clarkb | zbr: 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 later | 17:15 |
tristanC | zbr: i agree we shouldn't make that import weak simply to support building the doc on an unsupported platform | 17:16 |
clarkb | when you actually need gear in the command a weak import will be a problem if there are actual failures | 17:16 |
zbr | i 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 |
zbr | i see it as bug: cli fails because an unneeded import is done, clearly gear is not needed for all CLI executions. | 17:19 |
zbr | clarkb: but how about if platform == 'linux' approach? we have lots of options. | 17:20 |
clarkb | zbr: 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 later | 17:20 |
clarkb | currently the gear import fails and its pretty clear why | 17:21 |
*** ykarel_ is now known as ykarel | 17:21 | |
tristanC | zbr: i would be happy to setup a shell account on a our devel node where you could build the docs and run zuul tests | 17:21 |
fungi | so can we update the docs build to not bother with program-output and instead just refer to the zuul-client docs? | 17:22 |
zbr | tristanC: is not that I do not have enough boxes around. | 17:22 |
corvus | fungi: there are other commands | 17:22 |
fungi | ahh | 17:22 |
*** rlandy|brb is now known as rlandy | 17:23 | |
fungi | okay so not everything will be covered by zuul-client i guess | 17:23 |
corvus | fungi: zuul-scheduler, zuul-executor.... | 17:23 |
fungi | right, i forgot about the various entrypoints | 17:23 |
clarkb | one option might be to do the gear import late so that help commands work. Rather than making it conditional | 17:25 |
clarkb | (I havne't looked at the import paths so dunno if that is possible) | 17:25 |
corvus | clarkb: i don't think failing after --help is an improvement | 17:25 |
fungi | right, lazy importing is what i assumed was meant by "weak dependency" | 17:26 |
clarkb | fungi: the examples given were try except and platform checks | 17:26 |
corvus | if the program is run on an unsupported platform, it should say so asap. | 17:26 |
tristanC | could we trick the tox docs target to use a fake gear module to mitigate zbr's problem? | 17:28 |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul master: POC: Make gear importing lazy https://review.opendev.org/c/zuul/zuul/+/769968 | 17:28 |
zbr | the example above fixes the docs building. now is up to you to decide on how to achieve it. | 17:30 |
corvus | i have decided | 17:30 |
corvus | several 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 |
corvus | our review time is limited, let's spend it wisely. | 17:31 |
mhu | hmm 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 |
clarkb | mhu: I wonder if you need a clean tree? | 17:37 |
mhu | clarkb, possible. the problem is clearly on my side, there's been a build uploaded to dockerhub not 2 days ago | 17:38 |
*** ykarel has quit IRC | 17:42 | |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul master: Clarify supported platforms https://review.opendev.org/c/zuul/zuul/+/769972 | 17:57 |
openstackgerrit | Merged zuul/zuul master: Remove importlib-resources pinning https://review.opendev.org/c/zuul/zuul/+/766253 | 18:10 |
*** saneax has quit IRC | 18:21 | |
*** hamalq has joined #zuul | 19:10 | |
*** jamesmcarthur has joined #zuul | 19:23 | |
*** holser has joined #zuul | 19:31 | |
*** hamalq has quit IRC | 19:33 | |
*** hamalq has joined #zuul | 19:33 | |
*** jamesmcarthur has quit IRC | 20:11 | |
*** jamesmcarthur has joined #zuul | 20:22 | |
*** jamesmcarthur has quit IRC | 20:39 | |
openstackgerrit | lotorev vitaly proposed zuul/zuul-jobs master: Clarity tox_environment accepts dictionary not list https://review.opendev.org/c/zuul/zuul-jobs/+/769433 | 20:43 |
openstackgerrit | lotorev vitaly proposed zuul/zuul-jobs master: Document Python siblings handling for tox role https://review.opendev.org/c/zuul/zuul-jobs/+/768823 | 20:43 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: Get executor job params https://review.opendev.org/c/zuul/zuul/+/607078 | 20:54 |
*** rfolco has quit IRC | 21:11 | |
*** ikhan has quit IRC | 21:11 | |
*** ikhan has joined #zuul | 21:14 | |
*** cloudnull has quit IRC | 21:18 | |
*** rlandy has quit IRC | 21:19 | |
*** hashar has joined #zuul | 21:24 | |
*** ikhan has quit IRC | 21:27 | |
*** cloudnull has joined #zuul | 21:28 | |
*** hashar has quit IRC | 21:29 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: Separate out executor server from runner https://review.opendev.org/c/zuul/zuul/+/607079 | 21:30 |
*** ikhan has joined #zuul | 21:32 | |
*** holser has quit IRC | 21:45 | |
*** sduthil has quit IRC | 21:50 | |
*** jamesmcarthur has joined #zuul | 22:14 | |
*** jamesmcarthur has quit IRC | 22:17 | |
*** ikhan has quit IRC | 23:08 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!