Tuesday, 2021-11-02

*** ykarel|away is now known as ykarel04:29
*** jpodivin_ is now known as jpodivin06:43
*** ykarel is now known as ykarel|lunch09:39
*** jpena|off is now known as jpena10:10
*** rlandy is now known as rlandy|ruck10:32
*** ykarel|lunch is now known as ykarel10:54
opendevreviewMerged openstack/project-config master: kolla-cli: end gating for retirement  https://review.opendev.org/c/openstack/project-config/+/81458011:03
*** jcapitao is now known as jcapitao_lunch11:18
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: DNM Initial project commit  https://review.opendev.org/c/openstack/ci-log-processing/+/81560411:25
*** jpena is now known as jpena|lunch12:27
*** ykarel is now known as ykarel|afk12:33
*** jcapitao_lunch is now known as jcapitao12:38
*** jpena|lunch is now known as jpena13:26
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: DNM Initial project commit  https://review.opendev.org/c/openstack/ci-log-processing/+/81560414:09
*** ykarel|afk is now known as ykarel14:29
*** ykarel is now known as ykarel|away14:42
opendevreviewClark Boylan proposed openstack/pbr master: Add a PEP517 interface  https://review.opendev.org/c/openstack/pbr/+/79789815:29
clarkbstephenfin: ^ tahnks for the review. That also adds some docs as I realized we needed those when adding the release note15:30
clarkbfungi: ^ you may be interested in that as well15:30
*** sshnaidm_ is now known as sshnaidm15:49
efriedHey folks, I've got a colleague who's looking for some general support with zuul. What would be the best place/mechanism for him to engage?15:55
efried(To be clear: he's not in the OpenStack world.)15:55
fungiefried: the #zuul:matrix.org channel on matrix, or the zuul-discuss@lists.zuul-ci.org mailing list16:03
fungiefried: you could also send them to https://zuul-ci.org/start16:03
fungiefried: er, sorry, it's the #zuul:opendev.org matrix channel16:04
fungiefried: https://zuul-ci.org/community.html16:05
efriedThanks Jeremy!16:13
fungiyw16:13
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: DNM Initial project commit  https://review.opendev.org/c/openstack/ci-log-processing/+/81560416:28
fungidpawlik: it passed!16:43
dpawlikfungi: yeah, one more commit to push with test and should be ready to review16:44
dpawlikfungi: there is a PS made by tristanC that is using "Dependency injection" and I'm very curious wdyt about such approach: https://review.opendev.org/c/openstack/ci-log-processing/+/815969 16:45
funginote that unless you start out with noop jobs in the first change and add your real jobs in the later changes, you're not going to be able to merge those except by squashing into a single commit, since zuul will refuse otherwise16:45
dpawlikfungi: yup, I know :)16:46
fungii don't understand the dependency injection change, probably because it lacks any real commit message to provide context about what it's trying to accomplish16:47
dpawlikfungi: there is also another approach to use it with "classic" way by using mock, magic mock etc16:47
dpawlikfungi: can be, let me rebase it16:48
fungiit's a large enough change that if i just stare at it without some idea of what the goal is, i don't have enough background to guess if it's doing so effectively16:48
fungito be clear, i'm not much of a classical software developer, more like a sysadmin who sometimes scripts things, so even mock-based testing is a bit for me to wrap my head around16:49
fungii can attempt to review such things, but only when they come with clear explanations16:49
clarkbI think there should be two major considerations when building out this tooling (informed by the existing unmaintained version). 1) This software needs to be maintainable. Things like starting as a tool that gets deployed by config management instead of config management role/module that deploys a tool should help with that. 2) It should be something that openstack developers16:56
clarkbin particular are comfortable contributing to. They are the primary users and as such will be the primary pool of potential contributors16:56
clarkbgiven ^ my opinion is that you are better of sticking to openstack norms for building this out.16:57
fungiyeah, if i were to try to evaluate two potential implementations, my questions would be 1. which implementation is easier to read and understand? 2. which will be simpler to debug when there are errors? 3. which requires more effort to extend with future test additions?16:59
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: DNM demonstrate dependency injection testing technique  https://review.opendev.org/c/openstack/ci-log-processing/+/81596917:03
dpawlikimho test will be very helpful to avoid adding breaking changes. If I understand correctly, this tool needs to be working correctly all the time...Otherwise, developers may have issue to find where is a bug when opensearch will not have logs...17:05
dpawlikI like tristanC  approach, but I'm not familiar with such tests. Tomorrow I will propose new test base on mock - more common for python world17:07
dpawlikpatchset seems to be large, I will split it to few small 17:07
*** jpena is now known as jpena|off17:32
*** ianw_pto is now known as ianw19:00
mwhahahais zuul status page erroring for anyone else or just me?19:37
fungimwhahaha: it's being restarted should return momentarily19:38
mwhahahak19:38
rlandy|ruckfungi: hi - will our jobs be automatically queued again or should we recheck them?19:50
rlandy|ruckie: those in gate19:50
fungirlandy|ruck: they will be reenqueued19:50
rlandy|ruckgreat - thanks19:50

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