Monday, 2020-12-07

*** tosky has quit IRC00:20
*** wuchunyang has joined #zuul01:00
*** wuchunyang has quit IRC03:12
*** bhavikdbavishi has joined #zuul03:15
*** bhavikdbavishi1 has joined #zuul03:18
*** bhavikdbavishi has quit IRC03:20
*** bhavikdbavishi1 is now known as bhavikdbavishi03:20
*** bhavikdbavishi has quit IRC04:26
*** bhavikdbavishi has joined #zuul04:27
*** evrardjp has quit IRC05:33
*** evrardjp has joined #zuul05:33
*** bhavikdbavishi has quit IRC06:04
*** bhavikdbavishi has joined #zuul06:04
*** bhavikdbavishi1 has joined #zuul06:07
*** bhavikdbavishi has quit IRC06:08
*** bhavikdbavishi1 is now known as bhavikdbavishi06:08
*** vishalmanchanda has joined #zuul06:15
openstackgerritSimon Westphahl proposed zuul/zuul master: Driver event ingestion  https://review.opendev.org/c/zuul/zuul/+/71729906:36
openstackgerritSimon Westphahl proposed zuul/zuul master: Component Registry in ZooKeeper  https://review.opendev.org/c/zuul/zuul/+/75918706:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Move management and result events to model  https://review.opendev.org/c/zuul/zuul/+/76116306:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Allow (de-)serialization of management events  https://review.opendev.org/c/zuul/zuul/+/76116406:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Allow (de-)serialization of result events  https://review.opendev.org/c/zuul/zuul/+/76116506:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Add and fix fields in driver trigger event models  https://review.opendev.org/c/zuul/zuul/+/76116606:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Allow (de-)serialization of trigger events  https://review.opendev.org/c/zuul/zuul/+/76116706:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Interface to get a driver's trigger event class  https://review.opendev.org/c/zuul/zuul/+/76116806:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Clear list of Zookeeper connections after tests  https://review.opendev.org/c/zuul/zuul/+/76116906:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Increase default test wait timeout to 120s  https://review.opendev.org/c/zuul/zuul/+/76375406:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Implementation of Zookeeper backed event queues  https://review.opendev.org/c/zuul/zuul/+/76117006:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Implementation of Zookeeper event watcher  https://review.opendev.org/c/zuul/zuul/+/76117106:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Switch to Zookeeper backed trigger event queues  https://review.opendev.org/c/zuul/zuul/+/76117206:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Switch to Zookeeper backed management event queues  https://review.opendev.org/c/zuul/zuul/+/76173806:37
openstackgerritSimon Westphahl proposed zuul/zuul master: Use logical timestamp to detect outdated changes  https://review.opendev.org/c/zuul/zuul/+/76375506:37
*** saneax has joined #zuul06:37
*** ikhan has quit IRC06:52
*** mach1na has joined #zuul07:03
*** mach1na has quit IRC07:07
*** bhavikdbavishi has quit IRC07:10
*** jfoufas1 has joined #zuul07:18
*** mach1na has joined #zuul07:27
*** bhavikdbavishi has joined #zuul07:33
*** mach1na has quit IRC07:41
openstackgerritFelix Edel proposed zuul/zuul master: Switch to using zookeeper instead of gearman for jobs  https://review.opendev.org/c/zuul/zuul/+/76250608:02
openstackgerritFelix Edel proposed zuul/zuul master: WIP Switch to ZooKeeper backed result event queues  https://review.opendev.org/c/zuul/zuul/+/76434408:02
*** Phoenikzz has joined #zuul08:04
*** mach1na has joined #zuul08:06
*** jcapitao has joined #zuul08:06
Phoenikzztobiash: Regarding  https://review.opendev.org/c/zuul/zuul-jobs/+/764062, I had the thought that "lets do this as a concept, if you need a file tree in your tests, this is how you do it". If that concept is not wanted, I have no problem with doing it for the problematic files only. Just a bit messier to pack the files together, but if "only the problematic files" are what's wanted, I'll fix that.08:09
tobiashPhoenikzz: I think having the files in fixture folders is the much simpler concept than having those in a json file so I'd prefer to stick to that generally. However I also see that it's generally desirable to have one common approach.08:16
tobiashPhoenikzz: what do you think about combining those two concepts in terms of stage the files from the fixture tree into a tmp dir and having the filenames urlencoded/decoded in that process if needed?08:17
tobiashthen we would have the simple filesystem layout and still the option to have funky names as filenames08:17
PhoenikzzGood idea. I'll find the time to fix it that way. I was myself a bit concerned about the extra step of running the script whenever the file tree needed changes.08:19
*** savihou has quit IRC08:23
*** fdegir has quit IRC08:34
*** fdegir has joined #zuul08:34
*** rpittau|afk is now known as rpittau08:46
*** hashar has joined #zuul09:02
*** wuchunyang has joined #zuul09:02
*** mgoddard has joined #zuul09:20
*** nils has joined #zuul09:33
openstackgerritGuillaume Chauvel proposed zuul/zuul master: Fix zuul-client enqueue-ref when oldrev/newrev aren't provided  https://review.opendev.org/c/zuul/zuul/+/76576709:33
*** mach1na has quit IRC09:53
*** mach1na has joined #zuul09:55
*** bhavikdbavishi has quit IRC10:05
*** bhavikdbavishi has joined #zuul10:06
openstackgerritJonas Sticha proposed zuul/nodepool master: WIP: aws: add support for uploading diskimages  https://review.opendev.org/c/zuul/nodepool/+/73521710:08
*** bhavikdbavishi has quit IRC10:16
openstackgerritGuillaume Chauvel proposed zuul/zuul master: Fix zuul-client enqueue-ref when oldrev/newrev aren't provided  https://review.opendev.org/c/zuul/zuul/+/76576710:27
*** mgoddard has quit IRC10:33
*** bhavikdbavishi has joined #zuul10:37
*** wuchunyang has quit IRC10:37
*** jcapitao has quit IRC10:39
*** bhavikdbavishi1 has joined #zuul10:40
*** bhavikdbavishi has quit IRC10:41
*** bhavikdbavishi1 is now known as bhavikdbavishi10:41
*** jcapitao has joined #zuul10:45
*** mgoddard has joined #zuul10:49
*** mgoddard has quit IRC10:52
*** mgoddard has joined #zuul10:53
openstackgerritJonas Sticha proposed zuul/nodepool master: WIP: aws: add support for uploading diskimages  https://review.opendev.org/c/zuul/nodepool/+/73521710:55
*** wuchunyang has joined #zuul11:02
*** wuchunyang has quit IRC11:06
*** tosky has joined #zuul11:22
*** bhavikdbavishi has quit IRC11:22
*** wuchunyang has joined #zuul11:29
*** wuchunyang has quit IRC11:29
*** kgz has quit IRC11:48
*** bhavikdbavishi has joined #zuul11:51
*** savihou has joined #zuul11:51
*** rfolco has joined #zuul11:54
*** bhavikdbavishi1 has joined #zuul11:54
*** kgz has joined #zuul11:54
*** bhavikdbavishi has quit IRC11:56
*** bhavikdbavishi1 is now known as bhavikdbavishi11:56
*** jcapitao is now known as jcapitao_lunch12:09
*** ikhan has joined #zuul12:17
*** mach1na has quit IRC12:39
*** hashar has quit IRC12:40
*** hashar has joined #zuul12:40
*** hashar has quit IRC12:42
*** mach1na has joined #zuul12:51
sshnaidmcores, can we merge this? https://review.opendev.org/c/zuul/zuul/+/68127712:54
*** rlandy has joined #zuul13:00
*** mach1na has quit IRC13:02
*** hashar has joined #zuul13:05
*** saneax has quit IRC13:14
*** jcapitao_lunch is now known as jcapitao13:17
*** bhavikdbavishi has quit IRC13:22
*** bhavikdbavishi has joined #zuul13:23
tobiashsshnaidm: see http://lists.zuul-ci.org/pipermail/zuul-discuss/2020-December/001416.html13:24
sshnaidmtobiash, great13:25
tobiashtldr it will be merged on friday if nobody objects13:25
*** mach1na has joined #zuul13:31
*** bhavikdbavishi has quit IRC13:42
*** Goneri has joined #zuul13:48
openstackgerritGuillaume Chauvel proposed zuul/zuul master: Fix zuul-client enqueue-ref when oldrev/newrev aren't provided  https://review.opendev.org/c/zuul/zuul/+/76576713:51
openstackgerritGuillaume Chauvel proposed zuul/zuul master: Fix exception when using enqueue-ref (gitlab test)  https://review.opendev.org/c/zuul/zuul/+/76580913:51
*** savihou has quit IRC14:00
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Enable installing nimble siblings  https://review.opendev.org/c/zuul/zuul-jobs/+/76567214:24
avassif anyone wants to do a round of reviews later the Zuul Cache role is ready: https://review.opendev.org/c/zuul/zuul-jobs/+/764808 :)14:25
avassare we okay with a simple role as https://review.opendev.org/c/zuul/zuul-jobs/+/749706 zbr says that it will be expanded to do more things later but at this stage it seems like it could be causing more problems that it's worth maintaining14:28
zbravass: what are these problems?14:29
avassa future role would need to default to installing ansible with pip that way and support all of those parameters since it's just a wrapper around the pip module14:30
zbravass: let me describe what i want to achieve in the end, maybe we can find alternatives ways to implement it14:31
zbri want to enable zuul to build and test collections, that means make use of ansible-galaxy and ansiblet-test. the second one has some very pelicular requirements for testing.14:32
avassI'm not sure what the role currently enables14:34
zbrboth of them are included with ansible, but especially for building collections we need to be sure we use ansible >=2.10, even if you may later want to test the installed collections with a different version.14:35
zbrat this moment i see it incomplete, as it does cover only for the "pip" install path.14:36
avasszbr: so something like 1) install ansible 2.10 2) build collection 3) install ansible <2.10 4) test?14:36
zbralso known as upstream (if we follow our terminology)14:36
zbris bit more complex that this but the idea is right (probably we would want to use a special venv only for building collection), to avoid tainting other things.14:37
zbri was considering proposing a collection_build and collection_install roles.14:38
avassI guess what the role does is make it easier to set variables on a higher scope14:39
*** bhavikdbavishi has joined #zuul14:41
avassI'm not convinced it needs to be a role at this stage, is it okay if we wait with that change until it covers a broader usecase?14:42
zbravass: sure, that one can clearly wait.14:46
zbri do find your worries as valid, at least in current form it does not have a strong bussiness case ;)14:46
*** bhavikdbavishi has quit IRC15:04
*** bhavikdbavishi has joined #zuul15:06
*** bhavikdbavishi has quit IRC15:50
*** bhavikdbavishi has joined #zuul15:50
*** holser has joined #zuul16:21
openstackgerritAndy Ladjadj proposed zuul/zuul master: [web][config] move timezone component to preferences  https://review.opendev.org/c/zuul/zuul/+/75592916:26
*** mach1na has quit IRC16:29
*** bhavikdbavishi has quit IRC16:29
*** bhavikdbavishi has joined #zuul16:37
*** bhavikdbavishi1 has joined #zuul16:42
*** bhavikdbavishi has quit IRC16:43
*** bhavikdbavishi1 is now known as bhavikdbavishi16:43
*** hashar has quit IRC16:53
*** rpittau is now known as rpittau|afk16:58
*** jcapitao has quit IRC17:49
*** zenkuro has joined #zuul18:15
zenkurohi, Im curious if success-url and failure-url(job properties) are working18:17
clarkbzenkuro: I believe the idea is to get away from those and rely on the build dashboard urls18:18
clarkbbut I don't recall the specific reasons for that anymore18:18
zenkuroclarkb: I suspect that marketing is the core idea, since showing dashboard will advertise the project.18:19
*** hamalq has joined #zuul18:19
zenkuroclarkb: but have you guys kicked out this nice properties?18:19
clarkbI thought there was some technical limitation too though, but ya could be18:19
clarkbzenkuro: the other thing to check is that maybe the interpolation is failing beacuse the vars you're trying to map aren't properlyn amed?18:20
zenkuroI was using them, and now my CI is failing after update, with very strange error message related to reporting to gerrit18:21
*** hamalq_ has joined #zuul18:21
clarkbzenkuro: looking at zuul/zuul/model.py the success-url handling is still there (search for success_url and pattern)18:24
clarkbit hasn't been removed at least as far as I can tell. Not sure if there have been other changes that may affect it though18:24
corvuszenkuro: the report-build-dashboard tenant config option controls whether they are used18:24
zenkuromany thanks clarkb!18:24
clarkbcorvus: aha18:24
corvuszenkuro: the reason is not marketing -- it's because if you direct-link to something other than the dashboard, there is no way for the user to get to the dashboard18:24
corvuszenkuro: so instead, we now suggest that you add interesting urls (like doc builds, previews, etc) as artifacts so they will show prominently on the build page.  it is one extra click, but at least it makes everything accessible18:25
*** hamalq has quit IRC18:25
fungia prime example is that in opendev we used to link to draft documentation builds for successful runs of docs jobs, but to the logs in the case of failures. it was fine most of the time, but if you wanted to see the logs of a successful run of some docs job that became a lot harder18:27
zenkurohm... hm... Oh what if I create a job that do ssh -i secret-key some-third-party-ci@review.opendev.org "SUCCESS http://my-logs.com" and place it as a separate job that runs locally after main job end?18:32
zenkuroby locally I mean on CI itself18:33
fungiit would be slightly inefficient since an executor would need to handle that rather than the scheduler taking care of it automatically, but also it would result in you needing to maintain two separate copies of your ssh credentials for that account18:35
zenkurofungi: yes, but it should work. Because I can't imagine any better approach.18:37
fungizenkuro: why is that better than unsetting report-build-dashboard and using success-url et cetera?18:38
fungii'm going to assume the reason you don't want to report the build dashboard is that your zuul-web service can't be exposed for some reason18:39
zenkurofungi: I will have to expose CI that have access to local network, while currently I expose some VPS with logs18:39
fungizenkuro: you shouldn't have to expose anything if you use success-url and failure-url instead of report-build-dashboard18:40
fungi(well, shouldn't have to expose anything other than what you provide success/failure links for)18:40
corvuszenkuro: ah, more context helps.  you didn't mention this was for 3rd-party ci behind a firewall.  i agree that in that case unsetting report-build-dashboard makes sense.  that will use the old behavior of just reporting the log url.  you don't have to use success-url or failure-url unless you want something other than the log url.18:43
corvuszenkuro: https://zuul-ci.org/docs/zuul/reference/tenants.html#attr-tenant.report-build-page18:44
corvuszenkuro: it's likely we will set that default to true in or around the v4.0 release, so if that's what you want, you should probably explicitly set it to false now.  however, we haven't changed that recently, so if something you had stopped working, i don't know what would have caused it.18:45
*** bhavikdbavishi has quit IRC18:45
zenkurofungi: you are correct.18:46
zenkurocorvus: thanks for clarification, I will check report-build-page18:46
*** bhavikdbavishi has joined #zuul18:47
*** bhavikdbavishi has quit IRC18:51
*** jfoufas1 has quit IRC19:09
*** imtiazc has joined #zuul19:10
zenkurocorvus: thanks again for pointing out report-build-page. it was set to true in one place and false in the other!19:10
*** imtiazc has quit IRC19:12
corvuszenkuro: great, it's always nice to be able to explain confusion :)19:15
*** hashar has joined #zuul19:25
avassthere's no way to check if the a build is in a pre-review pipeline or not right? it's only possible to check the name of the current pipeline?20:16
clarkbavass: zuul knows internally but ya I don't know if that info is shared with the job contexts20:17
avasswas thinking of checking that in Zuul cache and add zuul.build to the path for the artifact if it was running in a pre-review context20:18
avassthat way zuul-cache could still be used in pre-review to share artifacts between jobs with zuul_return20:18
fungiwhy not just do that always?20:31
avassfungi: so it can work as a cache for dependencies as well :)20:32
fungicouldn't it do the same in some post-review pipelines too though?20:32
fungiwhy limit it to pre-review?20:32
avassoh it's so you don't need to rebuild external dependencies. the idea came from when I had to build the nim compiler from source on alpine20:33
avassso that would be part of ensure-nimble20:34
avassif that's already been done for a specific version you could check if it's cached for every build and not need to rebuild it20:34
avassbut that would be a problem if a pre-review pipeline could modify that artifact20:34
clarkbtristanC: can you take a look at https://storyboard.openstack.org/#!/story/2008427 which is nodepool having trouble with pip's new dep solver due to openshift and urllib incompatibilities20:35
clarkbtristanC: I think I've managed to track down the problem but I don't have the background to understand what updating the openshift dep to 0.11.2 is likely to entail20:35
fungiavass: not all post-review artifacts are guaranteed final either though20:35
fungiavass: consider the use case where jobs are run for a change after a trusted reviewer has acknowledged it, but not approved it20:36
avassso a pre-review pipeline should only be able to pass artifacts between jobs with zuul-cache while a post-review should be able to cache external dependencies so they won't need to be rebuilit20:36
avasswhat do you mean with acknowledged but not approved?20:37
fungiavass: oh got it, so the ccache example would be that builds within the same buildset could take advantage of cached object files, but only once changes are run in a post-review context can they add objects to a global ccache?20:38
avassyeah like that20:38
avassor with depends-on it could also work cross changes20:38
avasssince it would fetch it with zuul.artifacts20:38
fungiavass: hard to put into context without knowing your workflow, but for example let's say relative to the gerrit workflow followed for the zuul tenant in opendev... we've got a check pipeline which is pre-review running on any uploaded change and a gate pipeline which is post-review running when any change is approved to merge, but we could also have something along the lines of a "reviewed" pipeline which runs20:40
fungiafter a zuul maintainer adds their +2 vote to an unapproved change20:40
avasswould there be a problem with that?20:41
avasssince in that case it has been reviewed20:41
funginope, it's a relevant use case, i was just trying to understand how that fit with your use of post-review in caching. you're saying any builds run in the context of that "reviewed" pipeline should also be able to update the global cache, and yeah that sounds reasonable20:42
corvusindeed, we've contemplated similar "post-review, pre-merge" pipelines before.  eg: run tests against a production service (like a cloud) if a core reviewer okay's the change20:43
avassyeah. and the names are configurable so if needed they could do things like <artifact>-<zuul.pipeline> if the caches should be separate per pipeline20:43
corvusavass: adding a post-review zuul inventory var should be trivial20:43
corvusthe only thing is i'm sad we didn't do "zuul.pipeline.name" instead of "zuul.pipeline"  :(20:43
avassfungi: if you got time over and you're interested in the current implementation the change is ready for review: https://review.opendev.org/c/zuul/zuul-jobs/+/764808 :)20:44
corvuswe could switch that the same way we did zuul.project: make zuul._pipeline a dict, then deprecate zuul.pipeline, make it a copy, then drop zuul._pipeline20:45
avasscorvus: maybe a good time to do that with 4.0 :)20:46
openstackgerritClark Boylan proposed zuul/nodepool master: Bump openshift dep  https://review.opendev.org/c/zuul/nodepool/+/76587320:46
clarkbtristanC: ^ thats a naive change pushed up to try and gather more data on what breaks20:47
avasscorvus: though technically, isn't it the job that is post-review or not? https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.post-review20:48
avassoh I might have read that wrong20:49
corvusnah its https://zuul-ci.org/docs/zuul/reference/pipeline_def.html#attr-pipeline.post-review20:49
corvusjob attr just prevents job from running20:49
tristanCclarkb: thanks, updating shouldn't be an issue, for example ansible kubernetes collection is using `>=0.6.2`21:05
*** hashar has quit IRC21:15
clarkbtristanC: git history shows we capped beacuse 0.9.0 broke things21:23
clarkbthat change should tell us if 0.11.2 is in the same situation and if so I can try and look into fixing it, though this portion of the code is less familiar to me21:24
clarkbtristanC: ya looks like openshift.config doesn't exist anymore at least21:25
clarkbI think I see what that was converted to. I'll whittle away at this for a bit and see if I can make any progress21:28
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add zuul-ensure-own-config role  https://review.opendev.org/c/zuul/zuul-operator/+/76588221:40
*** msuszko has joined #zuul21:42
*** sshnaidm has quit IRC21:49
*** zenkuro has quit IRC21:51
clarkbtristanC: this is quickly getting out of my depth it seems that we need to create a dynamic openshift client and using that we then have to explicitly call .get or .post etc on various resources to do those operations. I'll try to continue to fumble my may through this in hopes someone can clean it up but it isn't the most straightforward thing21:51
tristanCclarkb: could this work in place https://github.com/ansible-collections/community.kubernetes/blob/2474ef1b2ca5640cd1ff040ebb2b562457049608/plugins/module_utils/common.py#L252 ?21:55
clarkbtristanC: yes, but openshift's api too ahs completely changed21:57
clarkbthey really seemed to have rewritten the entire api around 0.9.021:57
clarkbI'll get an incomplete update up so you can see what I mean21:57
clarkbcurrently trying to udnerstand what the difference between a ProjectRequest and a Project is22:01
*** mordred has quit IRC22:02
*** odyssey4me has quit IRC22:02
*** johnsom has quit IRC22:02
tristanCclarkb: i'd say we don't want ProjectRequest22:02
*** jhesketh has quit IRC22:06
clarkbtristanC: the current drivers seem to use it to createa  project but there is a separate project creation request api too22:07
*** jhesketh has joined #zuul22:08
*** sshnaidm has joined #zuul22:08
openstackgerritClark Boylan proposed zuul/nodepool master: Bump openshift dep  https://review.opendev.org/c/zuul/nodepool/+/76587322:09
clarkbtristanC: see ^ nodepool/driver/openshift/provider.py in particular22:09
clarkbI'm not sure I'm a fan of this new api they provide22:09
clarkbthe old one generated from the swagger was a lot more direct22:09
clarkbalso you could read the swagger and figure out the api22:10
clarkbbut now it requires much better understanding of the underlying datastructures22:10
*** fdegir has quit IRC22:14
*** tobberydberg has quit IRC22:14
*** fdegir has joined #zuul22:15
*** tobberydberg has joined #zuul22:19
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add zuul-ensure-own-config role  https://review.opendev.org/c/zuul/zuul-operator/+/76588222:21
openstackgerritAndy Ladjadj proposed zuul/zuul master: [web][config] move timezone component to preferences  https://review.opendev.org/c/zuul/zuul/+/75592922:23
tristanCclarkb: oh we do use project request, i see in the api doc that this is correct (`end users should use the requestproject resource.`)22:26
clarkbtristanC: I see is that difference between admin and normal user then?22:26
*** bolg has quit IRC22:30
*** johnsom has joined #zuul22:30
*** odyssey4me has joined #zuul22:30
*** mordred has joined #zuul22:30
clarkbhttps://groups.google.com/g/repo-discuss/c/A4AhqursMYo/m/riTwt6COBwAJ Gerrit 3.3.0 will break zuul22:34
clarkbor at least some bits of zuul? we need to listen to new types of events looks like22:34
*** rfolco has quit IRC22:34
clarkbfungi: ianw ^ fyi we shoudl ensure that zuul is updated before we upgrade to 3.3.0 I guess22:34
ianwindeed22:40
clarkbtristanC: also looks like we need to update all the fakes in testing :/22:43
*** rfolco has joined #zuul22:43
clarkbis it bad that I wonder if forking 0.8 and using the swagger generation would be less work22:43
clarkb(I don't seriously think we should do that)22:44
*** rfolco has quit IRC22:48
openstackgerritAndy Ladjadj proposed zuul/zuul master: [web][config] move timezone component to preferences  https://review.opendev.org/c/zuul/zuul/+/75592923:05
clarkbtristanC: it does look like the changes I have made work with kubernetes functioanlly though, which makes esnse as it is a bit less tied to the openshift client23:11
*** vishalmanchanda has quit IRC23:24
openstackgerritClark Boylan proposed zuul/nodepool master: Bump openshift dep  https://review.opendev.org/c/zuul/nodepool/+/76587323:28
clarkbthat latest ps makes some of the testing happier but I'm not sure that it is making tests happier correctly if that makes sense. We have fakes that we use that aren't lining up with at least the new openshift library client23:30
clarkb(on the k8s side we may be fine though)23:30
*** nils has quit IRC23:33
clarkbya now we are running into problems with the fakes23:39
*** ikhan has quit IRC23:43

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