Wednesday, 2020-01-29

*** yolanda has quit IRC00:06
*** tosky has quit IRC00:08
*** yolanda has joined #zuul00:09
*** jamesmcarthur has joined #zuul00:28
*** jamesmcarthur has quit IRC00:38
*** threestrands has joined #zuul00:50
*** jamesmcarthur has joined #zuul01:14
*** jamesmcarthur has quit IRC01:16
*** jamesmcarthur has joined #zuul01:19
*** jamesmcarthur has quit IRC01:21
*** igordc has quit IRC01:23
SpamapShrm, does zuul enqueue work to enqueue things in "post" pipelines?01:25
SpamapSIt seems to want something with a , with change#/patch# and my github push trigger just gives a ref#01:26
SpamapS(hash)01:26
clarkbSpamapS: enqueue-ref01:45
*** jamesmcarthur has joined #zuul01:47
*** jpena|off has quit IRC01:57
*** pabelanger has quit IRC01:57
*** nhicher has quit IRC01:57
*** migi has quit IRC01:58
fungiyeah, zuul enqueue for change-oriented pipelines, zuul enqueue-ref for git-ref-oriented pipelines02:01
fungithough if i found time i'd look into what it would take to make enqueue support the same options02:02
*** jamesmcarthur has quit IRC02:03
*** jpena|off has joined #zuul02:05
*** jamesmcarthur has joined #zuul02:14
*** nhicher has joined #zuul02:20
*** rfolco has joined #zuul02:31
*** rfolco has quit IRC02:36
*** jamesmcarthur has quit IRC02:53
*** bhavikdbavishi has joined #zuul03:01
*** bhavikdbavishi1 has joined #zuul03:04
*** bhavikdbavishi has quit IRC03:05
*** bhavikdbavishi1 is now known as bhavikdbavishi03:05
*** rlandy|bbl is now known as rlandy03:29
*** jamesmcarthur has joined #zuul03:29
*** jamesmcarthur has quit IRC03:38
*** rlandy has quit IRC03:42
*** armstrongs has joined #zuul03:56
*** armstrongs has quit IRC04:06
*** zxiiro has quit IRC04:37
*** raukadah is now known as chkumar|rover05:13
*** saneax has joined #zuul05:19
*** bhavikdbavishi has quit IRC07:39
*** saneax has quit IRC07:55
*** hashar has joined #zuul08:07
*** bhavikdbavishi has joined #zuul08:12
openstackgerritAntoine Musso proposed zuul/zuul master: gear: remove support for custom MASS_DO packet  https://review.opendev.org/70474208:34
*** tosky has joined #zuul08:35
*** bolg has joined #zuul08:43
bolghashar: I've commented on https://review.opendev.org/c/671674/ . I've tried using selectors there, but since it's a bit different api it did not seem to me worth the effort.08:45
hasharbolg: hi :)08:45
hasharbolg: yes sorry about my comment from yesterday, that 'selectors' suggestion I have made distracted everyone08:46
hasharShrews and I talked a bit about it yesterday and indeed introducing 'selectors' is a lot of changes08:47
hasharand also I forgot to CR +1 on my first comment there!08:48
*** jpena|off is now known as jpena08:54
bolghashar: (y)08:59
*** bhavikdbavishi has quit IRC09:28
*** bhavikdbavishi has joined #zuul09:28
openstackgerritMohammed Naser proposed zuul/zuul master: Start ignoring certain Gerrit events  https://review.opendev.org/70475609:38
*** bhavikdbavishi has quit IRC09:40
openstackgerritSimon Westphahl proposed zuul/zuul master: Allow skipping child jobs from paused job again  https://review.opendev.org/70475809:47
*** threestrands has quit IRC09:47
reiterativeHi fbo. I'm testing your WIP on the Gitlab driver, and would be grateful if you can give me some guidance. It reads branches from my Gitlab repo and picks up job definitions from a test branch, but jobs are not triggered when I add or update an MR. What might I be missing?10:02
mnaserreiterative: did you setup your pipeline to have the appropriate triggers?10:20
*** hashar has quit IRC10:30
fboreiterative: hi, please make sure the events are well received by zuul. With debug log level, you could see them in the zuul web or scheduler logs.10:43
fboit could also maybe due to the webhook token different between your zuul config and what is configured in the project settings.10:44
reiterativemnaser I have a check: item in the project definition if that's what you mean (I'm relatively new to Zuul)10:51
reiterativefbo Thanks for the suggestions. I've been trying to turn on debug logging (using the logging.conf-sample from zuul/zuul for reference), but haven't managed to get it working yet.10:54
fboreiterative: mnaser means about the pipeline defintion. Do you have this (line 1) https://review.opendev.org/#/c/698964/3/tests/fixtures/layouts/basic-gitlab.yaml in a trusted repo ?10:56
reiterativeAha! No I hadn't found that. I'm sure that will help :-)10:57
*** pcaruana has quit IRC10:57
fboyes it will :)10:59
*** bhavikdbavishi has joined #zuul11:03
*** bhavikdbavishi has quit IRC11:09
openstackgerritMatthieu Huin proposed zuul/zuul master: JWT drivers: Deprecate RS256withJWKS, introduce OpenIDConnect  https://review.opendev.org/70197211:12
openstackgerritMatthieu Huin proposed zuul/zuul master: OIDCAuthenticator: add capabilities, scope option  https://review.opendev.org/70227511:12
openstackgerritMatthieu Huin proposed zuul/zuul master: admin REST API: zuul-web integration  https://review.opendev.org/64353611:12
*** saneax has joined #zuul11:18
*** saneax has quit IRC11:19
*** saneax has joined #zuul11:20
*** saneax has quit IRC11:25
*** pcaruana has joined #zuul11:40
*** bolg has quit IRC11:58
*** bolg has joined #zuul12:02
*** bhavikdbavishi has joined #zuul12:08
*** rfolco has joined #zuul12:10
*** hashar has joined #zuul12:10
*** bhavikdbavishi1 has joined #zuul12:11
*** bhavikdbavishi has quit IRC12:12
*** bhavikdbavishi1 is now known as bhavikdbavishi12:12
*** sshnaidm is now known as sshnaidm|afk12:15
*** bolg has quit IRC12:17
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Replace existing operator tasks with the new dhall function  https://review.opendev.org/70210612:29
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Generate TLS certificats for the gearman service  https://review.opendev.org/70271612:29
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Handle service restart when connections are changed  https://review.opendev.org/70362412:29
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add tenant reconfiguration when main.yaml changed  https://review.opendev.org/70363112:29
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add OpenShift SCC and functional test  https://review.opendev.org/70275812:30
*** jpena is now known as jpena|lunch12:31
*** hashar has quit IRC12:34
openstackgerritMohammed Naser proposed zuul/zuul master: Start ignoring certain Gerrit events  https://review.opendev.org/70475612:44
*** avass has joined #zuul13:00
*** rlandy has joined #zuul13:02
*** avass has quit IRC13:05
*** bolg has joined #zuul13:10
*** avass has joined #zuul13:10
*** jpena|lunch is now known as jpena13:29
*** avass has quit IRC13:35
*** saneax has joined #zuul13:44
*** bolg has quit IRC13:49
*** jamesmcarthur has joined #zuul13:49
reiterativefbo I tried adding that pipeline definition to my zuul.config, but I get an error:13:51
reiterativeextra keys not allowed @ data['trigger']['gitlab']13:51
reiterative(Note that I added it to an existing gerrit config)13:51
*** zxiiro has joined #zuul14:05
fboreiterative: the gitlab connection must have been defined first. Then the pipeline definition must be stored in a .zuul.yaml in a config-project repository (tenants.yaml).14:08
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role  https://review.opendev.org/68204414:11
reiterativeOK. I'm defining my gitlab connection in zuul.conf at the moment, not as part of a config repo.14:17
*** jamesmcarthur has quit IRC14:38
*** jamesmcarthur has joined #zuul14:40
*** saneax has quit IRC14:43
*** jamesmcarthur has quit IRC14:45
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add OpenShift SCC and functional test  https://review.opendev.org/70275814:53
*** sshnaidm|afk is now known as sshnaidm14:56
*** swest has quit IRC15:03
*** swest has joined #zuul15:05
*** swest has quit IRC15:05
*** pabelanger has joined #zuul15:07
*** jamesmcarthur has joined #zuul15:09
*** jamesmcarthur has quit IRC15:14
fungii know this is probably a long-shot, but is anyone here interested in speaking about zuul at open infrastructure days turkey in istanbul on march 17? they only just told the osf they're organizing it or i'd have asked much sooner15:42
*** jamesmcarthur has joined #zuul15:47
*** jamesmcarthur has quit IRC15:53
*** bhavikdbavishi has quit IRC15:59
*** bhavikdbavishi has joined #zuul15:59
*** chkumar|rover is now known as raukadah16:04
*** bhavikdbavishi has quit IRC16:36
*** bhavikdbavishi has joined #zuul16:37
*** jamesmcarthur has joined #zuul16:39
dmsimardnoticed a small inconsistency issue with zuul's inventory variables in the post and periodic pipelines .. in check and gate there is both "zuul.change" and "zuul.change_url" -- in post there is no zuul.change, only zuul.change_url and in periodic, there is no zuul.change and zuul.change_url has a "None" in the URL (likely because zuul.change is17:14
dmsimardNone in periodic)17:14
fungiwhat do you think the missing vars should contain in those cases?17:18
fungithere isn't a "change" provided in ref-triggered gerrit stream events17:19
fungiand the periodic trigger has no gerrit context at all, just project/branch17:19
fungiif you have suggestions for reasonable dummy values, they're probably not hard to add17:20
corvusdmsimard: most of that sounds correct and as documented (see https://zuul-ci.org/docs/zuul/reference/jobs.html#zuul-variables ) but the "None" in the url sounds like a bug17:20
fungiand yeah, i suspect the intent was to not include change_url for those triggers17:21
fungibut instead we provide it with invalid content17:21
corvusfungi: yeah they are intentionally missing; i think it's better that way since it's easy to check whether it's defined in ansible.  and if a playbook uses them, without a default, then it's probably better to fail.17:21
fungimakes sense17:22
dmsimardfungi: I think it'd expected that there's no change or change_url for periodic -- for post, there should be zuul.change which is currently missing17:22
corvusbut clearly a url that looks like "http://something/None" isn't good for anyone :)17:22
fungidmsimard: why would there be a change for post?17:22
corvusdmsimard: actually, post is not a change-based pipeline, so it only gets a branch17:22
dmsimardfungi: because it originates from a change ?17:22
fungiit doesn't though17:22
corvuspromote otoh, is change-based, so it does get a change17:22
fungiit originates from an event about a branch tip updating17:22
fungiwhich gerrit doesn't map to an event17:23
fungihence the promote pipeline triggering on a change-merged event (which *does* map to a change)17:23
corvusin gerrit, this is tricky: the ref-updated event (post) gets you the actual commit sha after the change merges, but no info about the change.  the change-merged event (promote) tells you about the change, but not the actual commit sha that results from the merge.17:23
dmsimardfungi: but there is a change_url though17:23
fungis/which gerrit doesn't map to an event/which gerrit doesn't map to a change/17:23
corvusideally we would have an event with both, but we'd need a change to gerrit.17:23
dmsimardfwiw, a periodic inventory (with None in change_url and no change): https://b711d185688da3b864bc-5593d50c131879f6a486eeedbad80e3c.ssl.cf2.rackcdn.com/periodic/opendev.org/openstack/oslo.log/master/requirements-check/91e1e33/zuul-info/inventory.yaml17:24
dmsimardand a post inventory with a working change_url but no change: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_aa0/57e5a31f3721a46ad4d9394c2efb4cbe58de10e1/post/publish-stx-releasenotes/aa0c6c4/zuul-info/inventory.yaml17:24
corvusah yep.  that first url should probably point to the branch17:25
corvusthe post looks correct17:25
corvusprobably the closest thing there is that it says "change_url" and not "item_url"17:25
fungii would argue the change_url is misnamed in the post example because it points to a (often merge) commit not a change17:25
dmsimardcorvus: so we have a change_url but not a change ? the change_url is built using the change no ?17:25
fungithe change_url is not built on a change17:25
fungiit's the git ref provided in the gerrit event17:26
fungiin the case of your post pipeline example anyway17:26
dmsimardfungi: ah, you're correct it's a git link, not a gerrit link17:26
corvusyeah, i think that's the crux of the confusion.  i think change_url is an ancient variable we probably should have renamed in v317:26
fungihttps://opendev.org/starlingx/config/commit/57e5a31f3721a46ad4d9394c2efb4cbe58de10e117:26
fungiis what it links to in your example17:26
funginot a change, it's a merge ref17:26
corvuswe could start the process of renaming it now17:26
dmsimardcorrect, my bad17:26
corvusbut at this point, we'd have to keep both names around for a while17:26
fungialso yes, thinking about it harder, we wouldn't want to include dummy values for information not provided by the trigger if for no other reason than that would be a massive number of possibly useless information if we made it a habit across every possible trigger zuul supports17:29
fungias zuul grows an every increasing number of connection drivers, i expect the number of driver-specific bits of information to increase17:30
dmsimardmakes sense, so then my understanding is that it is working as intended but the None issue should be looked at17:30
fungiand maybe the change_url should be renamed or split17:30
fungi(with a lengthy deprecation cycle)17:31
corvusclarkb: do you have your link to the draft wiki etherpad handy?17:33
clarkbcorvus: https://etherpad.openstack.org/p/zuul-wikipedia17:34
corvusthx; replying to jamesmcarthur17:34
jamesmcarthurhello!17:35
corvusjamesmcarthur: i have sent an email in reply to your email!17:42
corvusto which you replied, and to which reply i shall subsequently reply17:42
jamesmcarthurlol17:43
fungithis meta-discussion is riveting17:48
*** jpena is now known as jpena|off17:58
*** mattw4 has joined #zuul18:01
*** jamesmcarthur has quit IRC18:09
*** michael-beaver has joined #zuul18:10
*** jamesmcarthur has joined #zuul18:18
*** tosky has quit IRC18:22
*** jamesmcarthur has quit IRC18:26
*** bhavikdbavishi has quit IRC18:33
*** jamesmcarthur has joined #zuul18:55
*** igordc has joined #zuul19:02
*** hashar has joined #zuul19:10
zbrsorry to bother, but can we deal with the last 4 CRs on gear? https://review.opendev.org/#/q/project:opendev/gear+status:open19:15
corvuszbr: that's on my list but not at the top.  i should be able to take a look next week.19:16
corvustobiash: (and bolg) i reviewed https://review.opendev.org/621479  -- i think there are a couple of things to clarify.  one of them is directly applicable to mandatory sql, so we should agree on that before proceeding with that patch.19:18
corvustobiash: i think we're almost there! :)19:18
tobiash\o/19:19
zbri mentioned it because i faced these while trying to more intresting work on zuul.19:20
zbrfor example i am unable to install zuul_return module on macos in order lint zuul playbooks, the latest verison of ansible-lint checks for module presence.19:21
zbror maybe we need an alternative way to distribute the module, installing zuul package is a bit of a BFG kind of approach, as it brings a huge amount of uneeded depds by default.19:23
tristanCcorvus: would `mandatory sql` results in the reporter be automatically setup for every pipeline?19:24
corvustristanC: yes19:24
tristanCnice, that's great to hear :)19:24
corvus++19:25
tobiashcorvus: I agree with the sql comment, I also don't have such a use case19:26
*** hashar has quit IRC19:26
corvustristanC: starts at line 202 of  https://review.opendev.org/621479  -- maybe you want to take a look at that and see if you agree with my comment or have a use case for multiple dbs19:26
tobiashHowever I think I remember that the current system was designed with this as a theoretical use case19:27
tobiashBut I doubt as well that anyone uses multiple sal connections19:27
tristanCcorvus: that's what i was reading, and that make sense to me, we have not seen such a use case19:27
corvustobiash: yeah, all the use cases i know of that drove the original design should be able to be handled by queries19:27
*** jamesmcarthur has quit IRC19:27
corvus(ie, just query for "status=failed and project=foo")19:28
tobiashcool makes it easier19:28
corvuswe could ask jhesketh to take a look and see if he can think of any reasons too19:29
*** mattw4 has quit IRC19:29
tristanCactually one sql per zuul should be enough for most use-case, but since zuul already support multiple sql connection, one sql per tenant sounds good too19:29
tobiashcorvus: regarding multithreaded popeline processors, we thought that we habe them anyway and the according locking with multiple schedulers and adding more threads per scheduler would be easy then19:29
*** mattw4 has joined #zuul19:30
tobiashAt least what I observe is that also today we face quite some slowdowns when a big tenant performs tenant reconfigs19:30
corvustobiash: well, with more threads, it won't run any faster, (it will actually just run slower) except while waiting for cat jobs during a reconfig19:31
corvustobiash: but to a user, it would appear that progress was being made19:31
tobiashyes, it would slow down the reconfig while still allowing other tenants to procerd19:32
corvusi'm not strongly opposed to multi-threaded scheduler if folks think it's worthwhile, because i agree, it's not going to add much complexity  (but i don't)19:32
tobiashbut you're right, we can just add more schedulers then19:32
corvusyeah, more scheduler processes are the only way to make the overall system to run faster (under normal, non-reconfigure) conditions19:33
tobiashk let's stay single threaded and see how it works for us then19:33
corvusthis is also easy to change later :)19:33
tobiashprobably having like 4 schedulers will be enough for quite some tenants19:34
tobiashmost of our stalls are caused by our busiest tenant19:34
tobiashIm that case there would still be three other processors left19:35
*** plaurin has joined #zuul19:35
plaurinhello irc people19:36
corvustobiash: we could add some metrics around how much time is spent reconfiguring a tenant, how much busy/idle time for each scheduler, etc, to be able to measure the effect of adding more scheds19:36
corvusplaurin: hello19:36
tobiashgood idea19:36
*** jamesmcarthur has joined #zuul19:38
plaurincorvus, tristanC: Hey I have been fiddeling around with the prepare-workspace-openshift and general kubernetes integration in zuul19:38
tristanCplaurin: hello19:39
plaurinI have this issue where the prepare-workspace-openshift does not have the concept of "{{ zuul_workspace_root }}" like in the regular prepare-workspace. Basically, it always put the src directory into the /tmp of my container in kubernetes19:40
plaurinI will try to add that variable to the workspace openshift locally19:41
tristanCplaurin: iirc that depends on the image WORKDIR19:42
plaurinyes, but in all cases it seems to fall into the /tmp dir anyways19:42
openstackgerritMerged zuul/zuul master: Change default Gerrit HTTP auth method  https://review.opendev.org/70406819:43
plaurinbut I will double check double test this19:43
pabelangerin the case of non-voting jobs, how could be better enforce not allowing them for a pipeline? For example, gate. Historically, we've viewed the results in that pipeline useless however it usually requires humans to manage that policy. Could we enfore some sort of pipeline stanza setting to not allow them, and report error?19:47
mordredcorvus, tristanC: do we even have a usecase for sql-per-tenant vs one global (agree about not specifying a sql per tenant if a global default is present) - mostly thinking about dashboard. .... oh, maybe it would be valuable from a scaleout perspective?19:54
pabelangerwhat is a tenant, doesn't want logs to be public (if global default exists)?19:56
pabelangers/log/results19:57
*** gmann is now known as gmann_afk19:57
clarkbpabelanger: you could acl that off at the application rather than the db19:58
tobiashmordred: I could think about requirements in the enterprise context, but I don't have that use case myself (yet)19:58
clarkbI think either way a zuul operator would be able to see all the results19:58
clarkbpabelanger: for non voting jobs, another option might be to force voting when in a pipeline with $flag set19:59
clarkbpabelanger: the job would then still run as instructed but with a vote19:59
mordredtobiash: yeah - I could imagine that too - and also don't have it20:00
clarkboperationally sql per tenant may make sense for scaling reasons?20:01
clarkbwe still don't expire old data right?20:01
mordredyeah. that's the use case that seems most compelling in my brain20:01
pabelangerclarkb: re: acl, yah an option. I am just thinking some people might not want that info into databae at all20:01
pabelangerclarkb: re: non-voting, right I'm more looking for, if job is non-voting, don't equeue it20:02
pabelangerbut know that go against zuul config settings20:02
clarkbpabelanger: I think its usually best to be conservative and run jobs if they are asked for20:02
clarkbusers can remove the job from the pipeline to stop running the job20:03
clarkbbut an implicit removal could be dangerous20:03
tobiashpabelanger, clarkb: I think the best would be to make nonvoting jobs a config error if some flag is set on a pipeline20:04
pabelangerclarkb: yah, I'm looking for a way to help monitor that, but agree removal shouldn't happen. Maybe raise config error if proposed20:04
clarkbya error would work too20:04
tobiashthat is the way of least surprise :)20:05
mordred++20:05
tobiashand with no implicit behavior20:05
*** hashar has joined #zuul20:05
tobiashBut validation can get tricky20:06
tobiashBecause you only know if a job is voting after job freezing20:07
AJaegerdocker image build is broken in periodic pipeline, https://review.opendev.org/704680 is a fix - reviews welcome20:07
tobiashSo the easiest while still with little surprise would be a job frezing error returning a good error message20:08
pabelangertobiash:++20:08
corvusi agree with the consensus on both pabelanger and mordred's points20:17
*** mattw4 has quit IRC20:25
openstackgerritMerged zuul/zuul-jobs master: Fix periodic image build jobs  https://review.opendev.org/70468020:34
plaurincorvus, tristanC: I tested with a docker container that has WORKSPACE set to "/home/ubuntu", but everything that happens in zuul happens in the "/tmp" dir20:37
plaurinhowever I have an ansible variable set to "ansible_remote_tmp: /tmp", because else I have permissions issue20:40
tristanCplaurin: found the reason: https://opendev.org/zuul/nodepool/src/branch/master/nodepool/driver/kubernetes/provider.py#L277 , that should override the image WORKSPACE20:43
plaurinohhh that's hardcoded in the source20:44
plaurinin your opinion should this be a 'bug' or should I adapt my jobs to work with this?20:44
tristanCplaurin: hard to tell... perhaps the workingDir should be configurable per label, with a default to /tmp ?20:46
tristanCplaurin: what's the issue when using /tmp ?20:47
plaurinimho default /tmp is fine as long as it's configurable. Well, I need to migrate jobs from static nodes to k8s. Many of my jobs 'rely' on the ubuntu home directory right now20:47
plaurinthere's some 'hardcode' on our side too in that manner ...20:48
plaurinbut I guess an interesting discussion20:48
plaurinI would definitely be comfortable with a providers.[kubernetes].pools.labels.workdir in nodepool20:52
corvusthat sounds like a reasonable option20:55
corvusnote also that many zuul-jobs jobs (and our jobs in opendev) use "ansible_user_dir" instead of assuming cwd or hardcoding a path.  i wonder if adapting your jobs to use that, and then setting that for the k8s jobs explicitly would work too?20:55
plaurina bit similar to "zuul_workspace_root:" in the prepare-workspace module, yeah20:58
*** jamesmcarthur has quit IRC21:05
fungipabelanger: clarkb: i've had a lingering item on my to do list to file a story for a pipeline option to automatically exclude non-voting jobs21:11
fungi"write story about option to strip non-voting jobs from a zuul pipeline"21:11
fungii'm happy to cross that off if someone's on it21:11
fungithere were some arguments in favor of that around being able to do things like define a list of job names in a yaml anchor and then reuse a pointer to that in other pipelines21:13
fungiand also situations where a project may apply a project-template but then want to switch a single job to non-voting without having to duplicate the contents of the template minus one entry in another pipeline21:14
*** gmann_afk is now known as gmann21:17
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role  https://review.opendev.org/68204421:25
*** jamesmcarthur has joined #zuul21:32
*** mattw4 has joined #zuul21:40
pabelangerfungi: ack, thanks!21:43
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role  https://review.opendev.org/68204421:43
pabelangeralso, https://dashboard.zuul.ansible.com/t/ansible/build/48a8693d652e4de090bd8cfd46197ef2 is our pypi release job for zuul.a.c21:44
*** tosky has joined #zuul22:10
*** jamesmcarthur has quit IRC22:18
*** jamesmcarthur has joined #zuul22:19
*** hashar has quit IRC22:25
openstackgerritJames E. Blair proposed zuul/zuul master: Add gcloud_service auth option for Gerrit driver  https://review.opendev.org/70490422:26
*** rfolco has quit IRC22:33
openstackgerritJames E. Blair proposed zuul/zuul master: Add gcloud_service auth option for Gerrit driver  https://review.opendev.org/70490423:12
*** rlandy is now known as rlandy|bbl23:14
*** plaurin has quit IRC23:31
*** sshnaidm is now known as sshnaidm|afk23:45
*** tosky has quit IRC23:52

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