fungi | SpamapS: agreed, digest auth by itself is only robust against sniffing, not traffic manipulation (like mitm) | 00:00 |
---|---|---|
fungi | client certs issued by an internal ca would be robust against both | 00:01 |
clarkb | I think tristanC has asserted sasl is useful for them in order to reject new connections with bad auth at connection time | 00:02 |
clarkb | without sasl you can still connect and interact with the server | 00:02 |
fungi | client cert auth would also have that property | 00:03 |
fungi | it's done during ssl/tls handshake | 00:03 |
clarkb | can't that still be delayed? | 00:03 |
clarkb | ah | 00:03 |
corvus | yeah, when i botched my certs earlier, it got rejected with "unknown_ca" real quick | 00:03 |
fungi | it can be delayed if you support "optional" authentication via a mechanism like starttls | 00:04 |
fungi | for example this is how tls is negotiated on 25/tcp for opportunistic encryption between smtp peers | 00:04 |
fungi | or for an imap service to offer plaintext and encrypted sessions on the same socket | 00:05 |
fungi | but if you do it like 443/tcp for https, you don't get past the tls handshake | 00:05 |
*** Defolos has quit IRC | 00:22 | |
fungi | circling back around, removing the version cap for python-daemon seems to have solved the tox-py38 failures | 00:31 |
fungi | so 712489 and 712494 should be ready to go now | 00:32 |
*** openstackstatus has joined #zuul | 00:45 | |
*** ChanServ sets mode: +v openstackstatus | 00:45 | |
*** erbarr has quit IRC | 00:55 | |
*** dangtrinhnt has joined #zuul | 01:16 | |
*** dangtrinhnt has quit IRC | 01:31 | |
*** dangtrinhnt has joined #zuul | 01:32 | |
*** dangtrinhnt has quit IRC | 01:51 | |
*** swest has quit IRC | 02:15 | |
*** rlandy|bbl is now known as rlandy | 02:15 | |
*** jamesmcarthur has joined #zuul | 02:18 | |
*** swest has joined #zuul | 02:28 | |
*** jamesmcarthur has quit IRC | 02:56 | |
*** jamesmcarthur has joined #zuul | 02:58 | |
*** jamesmcarthur has quit IRC | 03:03 | |
*** bhavikdbavishi has joined #zuul | 03:03 | |
*** jamesmcarthur has joined #zuul | 03:06 | |
*** jamesmcarthur has quit IRC | 03:34 | |
*** jamesmcarthur has joined #zuul | 03:35 | |
*** jamesmcarthur has quit IRC | 03:40 | |
*** rlandy has quit IRC | 03:44 | |
*** jamesmcarthur has joined #zuul | 03:56 | |
*** tobiash has quit IRC | 04:16 | |
*** tobiash has joined #zuul | 04:17 | |
*** jamesmcarthur has quit IRC | 04:23 | |
*** jamesmcarthur has joined #zuul | 04:27 | |
*** jamesmcarthur has quit IRC | 04:32 | |
*** jamesmcarthur has joined #zuul | 04:33 | |
*** tobiash has quit IRC | 04:43 | |
*** tobiash has joined #zuul | 04:46 | |
*** bolg has joined #zuul | 04:56 | |
*** raukadah is now known as chandankumar | 05:16 | |
*** zxiiro has quit IRC | 05:25 | |
*** jamesmcarthur has quit IRC | 05:30 | |
*** evrardjp has quit IRC | 05:35 | |
*** evrardjp has joined #zuul | 05:36 | |
*** reiterative has quit IRC | 05:40 | |
*** reiterative has joined #zuul | 05:40 | |
*** saneax has joined #zuul | 06:27 | |
*** bolg has quit IRC | 06:50 | |
*** smcginnis has quit IRC | 07:03 | |
*** dpawlik has joined #zuul | 07:04 | |
*** smcginnis has joined #zuul | 07:04 | |
*** Defolos has joined #zuul | 07:17 | |
openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Use a fake zuul_return and an .ansible-lint file https://review.opendev.org/712547 | 07:30 |
*** avass has joined #zuul | 07:48 | |
*** bolg has joined #zuul | 07:48 | |
*** hashar has joined #zuul | 07:58 | |
*** jcapitao has joined #zuul | 08:15 | |
*** tosky has joined #zuul | 08:18 | |
*** jpena|off is now known as jpena | 08:45 | |
*** sshnaidm|afk is now known as sshnaidm | 09:39 | |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Declare support for Python3.8 https://review.opendev.org/712480 | 09:45 |
fbo | fungi: ^ I've duplicated your change for zuul | 09:46 |
*** TomConte has joined #zuul | 09:51 | |
*** avass has quit IRC | 10:44 | |
*** TomConte has quit IRC | 10:59 | |
*** jcapitao is now known as jcapitao_afk | 11:02 | |
*** sshnaidm has quit IRC | 11:18 | |
*** sshnaidm has joined #zuul | 11:19 | |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Declare support for Python3.8 https://review.opendev.org/712480 | 11:20 |
*** sshnaidm has quit IRC | 11:22 | |
*** sshnaidm has joined #zuul | 11:30 | |
*** sshnaidm has quit IRC | 11:30 | |
*** jpena is now known as jpena|lunch | 11:49 | |
*** sshnaidm has joined #zuul | 11:52 | |
*** sshnaidm has quit IRC | 11:53 | |
*** sshnaidm has joined #zuul | 11:54 | |
*** rlandy has joined #zuul | 12:01 | |
*** avass has joined #zuul | 12:05 | |
openstackgerrit | Albin Vass proposed zuul/nodepool master: Enable setting label and instance name separately https://review.opendev.org/712666 | 12:15 |
*** avass has quit IRC | 12:25 | |
*** jpena|lunch is now known as jpena | 12:32 | |
*** jcapitao_afk is now known as jcapitao | 12:46 | |
tristanC | clarkb: i haven't tried TLS, it was not an option when i first implemented SASL. If it can be used in-place of SASL, then we should drop the initial implementation and replace it with TLS. | 12:51 |
*** avass has joined #zuul | 12:54 | |
tristanC | i mean, it seems like using a private ca to issue client cert should prevent anon connection too, if that's the case, i'm not sure why do we bother with sasl. Afterall, that's what we do for gearman, so why not just do the same with zk? | 13:07 |
tristanC | corvus: SpamapS: fungi: ^ | 13:08 |
Shrews | fungi: Since we had the python-daemon cap for a reason, maybe we need to work to figure out which versions matching 2.1.0 and above do not work and have some != for those rather than just uncap? | 13:12 |
*** ianychoi has quit IRC | 13:13 | |
Shrews | corvus: i think being able to support both sasl and tls is very reasonable. because as soon as we decide to not support one or the other, someone is going to request that we do. | 13:28 |
openstackgerrit | Albin Vass proposed zuul/nodepool master: Enable setting label and instance name separately https://review.opendev.org/712666 | 13:32 |
openstackgerrit | Albin Vass proposed zuul/nodepool master: Enable setting label and instance name separately https://review.opendev.org/712666 | 13:33 |
tristanC | Shrews: as an operator, i would wait for tls and not bother with sasl (assuming tls can also prevent anon connection). Perhaps we could ask on zuul-discuss if anyone would requires sasl? | 13:34 |
tristanC | or maybe using the zuul survey to gather zookeeper usage (self hosted, managed service, other?) would be good info? | 13:45 |
avass | anyone want to take a look at this ^ it's a quite small change :) | 13:47 |
*** kmalloc has joined #zuul | 13:47 | |
*** TomConte has joined #zuul | 14:20 | |
*** TomConte has quit IRC | 15:02 | |
*** bolg has quit IRC | 15:12 | |
*** hashar has quit IRC | 15:18 | |
*** Goneri has joined #zuul | 15:18 | |
openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Support buildkit backend when building docker images https://review.opendev.org/712716 | 15:35 |
openstackgerrit | Daniel Pawlik proposed zuul/zuul-jobs master: Add phoronix-test-suite job https://review.opendev.org/679082 | 15:39 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Use buildkit to mount instead of copy /output https://review.opendev.org/712717 | 15:41 |
fungi | fbo: why did it need duplicating? was the one i pushed for zuul incorrect? | 15:44 |
mordred | avass: the change looks fine - but I'm curious as to why that's a desirable thing? | 15:45 |
*** rlandy is now known as rlandy|afk | 15:46 | |
fbo | fungi: alright I haven't check you proposed one already for Zuul. Let me abandon the patch then. | 15:48 |
*** avass has quit IRC | 15:51 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 15:51 |
fungi | yeah, sorry, i pushed the changes for nodepool and zuul at the same time | 15:52 |
fungi | and tristanC's suggestion on your version is already met in my version | 15:52 |
fbo | fungi: sorry as well I though you did it only for nodepool w/o checking | 15:52 |
fungi | no need to apologize, i just thought i might have been missing something important there | 15:53 |
*** kmalloc has quit IRC | 15:57 | |
corvus | SpamapS: when you have a second, can you give https://review.opendev.org/712666 a look? that seems good and safe to me, but i want to make sure that hard-coding the name tag wasn't an intentional decision. | 15:59 |
*** jamesmcarthur has joined #zuul | 16:06 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 16:11 |
*** avass has joined #zuul | 16:14 | |
Shrews | corvus: last PS added a "with with" to the zookeeper.rst if you find another reason for another PS, but looking pretty good to me | 16:15 |
openstackgerrit | Albin Vass proposed zuul/nodepool master: Enable setting label and instance name separately https://review.opendev.org/712666 | 16:15 |
Shrews | i like that entire doc being there | 16:17 |
Shrews | corvus: does the new quorum format really use ";2181" and not ":2181" in the normal case? | 16:18 |
*** jamesmcarthur has quit IRC | 16:20 | |
corvus | Shrews: yep: https://zookeeper.apache.org/doc/r3.5.2-alpha/zookeeperReconfig.html | 16:22 |
corvus | i think the semicolon separates the server from the client info | 16:23 |
Shrews | hrm, how... odd (at least to the eye) | 16:23 |
corvus | (because serverip:port:port;clientip:port is also valid) | 16:23 |
corvus | yeah, if anything ever called out for a yaml file, this is it :) | 16:24 |
*** jamesmcarthur has joined #zuul | 16:24 | |
*** dpawlik has quit IRC | 16:28 | |
*** dpawlik has joined #zuul | 16:28 | |
*** bolg has joined #zuul | 16:34 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 16:36 |
*** hashar has joined #zuul | 16:37 | |
mordred | corvus: are you sure it shouldn't be TOML? | 16:39 |
corvus | /kick mordred | 16:39 |
* mordred hasn't made a toml crack in months so figures his quota is built up high enough to be able to use one | 16:39 | |
corvus | nope | 16:39 |
*** jcapitao is now known as jcapitao_afk | 16:40 | |
openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Support buildkit backend when building docker images https://review.opendev.org/712716 | 16:42 |
mordred | corvus: in the zuul dockerfile we're adding the stretch-backports repo - but python-base is buster now | 16:44 |
mordred | corvus: do we know what target version of bubblewrap and socat we were looking for? | 16:44 |
mordred | I'm thinking we might be able to drop that section | 16:45 |
mordred | buster has bubblewrap 0.3.1-4 and socat 1.7.3.2-2 | 16:45 |
mordred | stretch-backports has bubblewrap 0.3.1-4~bpo9+1 and socat 1.7.3.1-2+deb9u1 | 16:47 |
mordred | so I'm going to say yes | 16:47 |
corvus | mordred: that sounds plausible | 16:48 |
openstackgerrit | James E. Blair proposed zuul/nodepool master: Add ZooKeeper TLS support https://review.opendev.org/712733 | 16:48 |
corvus | Shrews: ^ the other half | 16:48 |
corvus | with both of those, i think we can update quick-start to use it | 16:49 |
corvus | should be a nice test of containerized depends-on | 16:49 |
mordred | corvus: incidentally - debian buster ALSO has yarn and nodejs 10 in it | 16:49 |
mordred | corvus: so it's also conceivable we're at the point where we can express nodejs and yarn in bindep as well and not need install-js-tools in the dockerfile | 16:50 |
tristanC | corvus: i'm testing TLS with the operator, hopefully we can see it in action soon using two depends-on | 16:50 |
mnaser | shower thoughts: wouldn't it make life easier to put nodepool and zuul in the same codebase, esp with all of these changes that are happening now | 16:51 |
mnaser | (and also, given that right now we don't have awareness of tenants in nodepool and there might be a whole lot of duplicated code if we were to ever think about that) | 16:51 |
corvus | mnaser: well, zuul is pretty much designed to avoid needing a monorepo, so it'd be a bit of a disappointment to give up and pack it in on that one. | 16:52 |
mnaser | corvus: yeah, but maybe we can think about zuul_lib or something to share the common zk code | 16:53 |
corvus | yes | 16:53 |
corvus | someone suggests that just about every day | 16:53 |
mnaser | oh, i see | 16:53 |
mnaser | it's me today :) | 16:53 |
corvus | it's not that much common code as it turns out :) | 16:53 |
corvus | it's like 40 lines or something | 16:53 |
corvus | (and those lines are not the lines that are changing) | 16:54 |
mnaser | ah, fair | 16:54 |
*** jamesmcarthur has quit IRC | 16:54 | |
corvus | i don't object to moving it into a lib, but i think we should do that after zuulv5, because heavy changes like that would make the zuulv4/v5 work take longer and about 2x as many changes | 16:56 |
*** jamesmcarthur has joined #zuul | 16:56 | |
corvus | most of the upcoming work is going to be only in zuul, so we're already in a situation where we only need to change one repo for most of that | 16:57 |
mnaser | i see | 16:57 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Remove stretch-backports from docker build https://review.opendev.org/712737 | 16:59 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Install javascript tools in docker via bindep https://review.opendev.org/712738 | 16:59 |
mordred | fungi: ^^ | 17:03 |
*** sshnaidm is now known as sshnaidm|afk | 17:07 | |
*** jcapitao_afk is now known as jcapitao | 17:12 | |
*** jamesmcarthur has quit IRC | 17:19 | |
*** rlandy|afk is now known as rlandy | 17:19 | |
*** hashar has quit IRC | 17:33 | |
clarkb | mordred: whats the risk with using experimental dockerfile syntax? | 17:34 |
*** evrardjp has quit IRC | 17:35 | |
*** evrardjp has joined #zuul | 17:36 | |
clarkb | mordred: left a ocmment on https://review.opendev.org/#/c/712737/1 | 17:38 |
*** jamesmcarthur has joined #zuul | 17:47 | |
*** paladox has quit IRC | 18:07 | |
*** paladox has joined #zuul | 18:09 | |
mordred | clarkb: sholdn't be much risk these days - it just doesn't work with OOOOLD docker | 18:13 |
clarkb | mordred: ok, I think we can definitely land the first two in the stack to enable buildkit but then the socat thing is probably worth an update | 18:14 |
mordred | clarkb: kk. also - I thnk the javascript one is bong and I need to do a little more work there | 18:14 |
clarkb | fwiw I kinda like being able to install from nodsource so that we use a consistent version of nodejs everywhere | 18:15 |
tristanC | corvus: running the zk-ca.sh and adding the ssl configuration to the zoo.cfg doesn't seem to be enough to make the container listen on 2281. Is there JAVA environment to set too? | 18:15 |
mordred | clarkb: oh yeah? kk. I'm fine keeping that | 18:15 |
clarkb | mordred: at one point we were using node 6,8 and 10 in different places :/ | 18:15 |
mordred | clarkb: which is not good | 18:16 |
tristanC | corvus: here is my current config: http://paste.openstack.org/show/790625/ | 18:18 |
*** jcapitao has quit IRC | 18:20 | |
corvus | tristanC: the main difference i see compared to my test config (i'll paste in a min) is maybe change the server.1 line to: server.1=0.0.0.0:2888:3888 | 18:20 |
corvus | tristanC: this is my config for the first node of a 3 node cluster: http://paste.openstack.org/show/790626/ | 18:21 |
corvus | (the ssl quorum is commented out just because i wasn't testing that in the most recent iteration) | 18:22 |
mordred | clarkb: the zuul-jobs update doesn't seem to have actually resulted in the env var being passed - did I just do something stupid? | 18:23 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 18:24 |
clarkb | mordred: https://review.opendev.org/#/c/712716/2/roles/build-docker-image/tasks/build.yaml that bit? | 18:25 |
mordred | clarkb: oh - it's because I fixed the env thing before that built | 18:25 |
mordred | I thnik | 18:26 |
mordred | maybe I didn't | 18:26 |
mordred | clarkb: but yeah - that's the bit | 18:26 |
clarkb | it looks like it should work to me | 18:27 |
corvus | tristanC: hrm, i changed my config to be the hostname too, and it still seems to work | 18:28 |
tristanC | corvus: are you using the docker.io/library/zookeeper image? | 18:29 |
corvus | tristanC: yes | 18:30 |
tristanC | i had to disable the entrypoint because it tried to write to /conf which is not readonly as it is now provided as a volume | 18:30 |
tristanC | perhaps it's silently failing because of the missing myid file? | 18:30 |
corvus | tristanC: yeah, that could be a problem; i think it gets upset if that is not there | 18:30 |
mordred | clarkb: is it possible command doesn't do environment and you have to do shell? | 18:41 |
clarkb | mordred: oh yup that could be it | 18:41 |
mordred | clarkb: sigh | 18:42 |
clarkb | ansibles docs have command tasks examples using environment though | 18:42 |
clarkb | but it wouldn't surprise me if that was the issue | 18:42 |
openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Support buildkit backend when building docker images https://review.opendev.org/712716 | 18:42 |
mordred | clarkb: let's try it and see | 18:42 |
*** jpena is now known as jpena|off | 18:51 | |
mnaser | ooou | 18:51 |
mnaser | install-k8s role is currently "broken" because it looks like newer minikube is trying to download a preloaded image of k8s | 18:51 |
mnaser | and then it fails to extract is cause its compressed with lz4 which is not on the image | 18:52 |
mordred | mnaser: uhm. | 18:52 |
clarkb | using docker? | 18:52 |
mnaser | so its just taking up 2 minutes for no reason (and slows down the eventual deployment too because its doing the pull twice, technically, i think) | 18:52 |
mnaser | yes, see: https://a9558da425ae6df3e759-67674e607a46c69293c37e4affbebdc2.ssl.cf1.rackcdn.com/712763/1/check/lodgeit-helm-functional/a675357/job-output.txt | 18:52 |
mnaser | i will push up a patch which should hopefully fix it | 18:52 |
clarkb | why would docker compress things in a format it can't decompress | 18:52 |
mnaser | maybe i misunderstood the error | 18:52 |
mnaser | but certainly it looks like it downloads something, fails to lz4 decompress, and then tries some other way | 18:53 |
mordred | why wouldn't it just docker pull? | 18:53 |
mnaser | looks like this preload thing is new | 18:54 |
mnaser | https://github.com/kubernetes/minikube/pull/6720 | 18:54 |
clarkb | oh this is out of band of docker | 18:56 |
clarkb | nice | 18:56 |
fungi | it knows what's best for you | 18:57 |
mordred | I don't see anywhere that adds an option "please don't do that" | 18:57 |
mnaser | yeah i'm looking at the code | 18:58 |
mnaser | and im not finding that either | 18:58 |
mordred | same | 18:58 |
mnaser | maybe a follow-up pr.. | 18:58 |
fungi | why would anyone want to turn off such a helpful feature? | 18:58 |
mordred | fungi: because we hate freedom and bunnies and awesomeness | 18:58 |
clarkb | installing lz4 seems fine for us fwiw | 18:58 |
clarkb | its just weird to have a tool that handles all this then bypass it and break things | 18:58 |
*** erbarr has joined #zuul | 18:59 | |
mnaser | ok let me push up a change | 18:59 |
fungi | yeah, seems like with all their preferences for bundling stuff, they'd bundle the decompressor for their implementation | 18:59 |
mordred | sure. it's just an annoying feature given we have caching proxy mirrors for docker and not for "some random object store bucket for a tarball" | 18:59 |
mnaser | i _really_ hope lz4 is the same package name across different platforms | 18:59 |
clarkb | mordred: ya that too | 18:59 |
mordred | so - while I could see this being "better" for some people, it's going to result in more network bandwidth for us | 18:59 |
mordred | and will be less reliable | 18:59 |
*** gmann is now known as gmann_lunch | 19:00 | |
fungi | and i agree, this does make caching things (if you're doing it over and over on different systems in the same environment) a pain | 19:00 |
fungi | then again, they already designed dockerhub to be uncacheable, right? so not a regression | 19:00 |
clarkb | mnaser: liblz4-tool on ubuntu I doubt its that on red hat distros :) | 19:00 |
avass | mordred: You should be able to use command with env, I use it when running go here: https://review.opendev.org/#/c/691114/10/roles/go/tasks/main.yaml | 19:00 |
mnaser | well instal-kubernetes seems to be pretty oriented to debian-based distros... | 19:00 |
mnaser | it uses apt_key/apt_repository/apt so | 19:01 |
avass | mordred: just saw the update and I was a bit confused why you switched to shell | 19:01 |
mordred | avass: I'm also confused ... mostly stabbing in the dark about why it didn't seem to pick up the env var | 19:03 |
openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: install-kubernetes: install lz4 packages https://review.opendev.org/712771 | 19:04 |
mnaser | clarkb, fungi, mordred: ^ | 19:04 |
mordred | avass: https://zuul.opendev.org/t/zuul/build/fbba2c5409644d0e86cd07bd4ce866ed/console - the failure there is what you get if you don't put DOCKER_BUILDKIT=1 in the env | 19:05 |
clarkb | mordred: if it fails with shell you could update the zuul-jobs change to hardcode buildkit on then we'll see if its the jinja there | 19:05 |
mordred | clarkb: good call | 19:06 |
tristanC | corvus: finally got an exception: `java.lang.UnsupportedOperationException: SSL isn't supported in NIOServerCnxn` | 19:10 |
tristanC | using `docker.io/library/zookeeper latest bbebb888169c 2 days ago 229 MB` | 19:10 |
avass | mordred, clarkb: the jinja seems to be correct | 19:12 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 19:13 |
clarkb | avass: I agree | 19:13 |
*** jamesmcarthur has quit IRC | 19:15 | |
mordred | yah | 19:15 |
mordred | clarkb, avass: it's possible I should just give up on this for now - this started as a nerdsniping this morning from looking at something else and remembering that I'd been meaning to see about trimming things down with mounts instead of copies ... but it seems like maybe the fates are not having it and I'm not sure its value is worth our continued effort | 19:16 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Remove stretch-backports from docker build https://review.opendev.org/712737 | 19:18 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Be explicit about source of base images https://review.opendev.org/712772 | 19:18 |
mordred | clarkb: ^^ both of those should still be solid and not related to the buildkit stuff | 19:21 |
Shrews | does anyone know how to stop the licensing messages I'm seeing from a 'tox -epep8' run on nodepool now? e.g., http://paste.openstack.org/show/790628/ | 19:21 |
Shrews | there are dozens more than what i pasted, so it's quite annoying | 19:22 |
mordred | uhm | 19:22 |
mordred | no - but let me go check | 19:22 |
*** bhavikdbavishi has quit IRC | 19:23 | |
openstackgerrit | Merged zuul/zuul-jobs master: install-kubernetes: install lz4 packages https://review.opendev.org/712771 | 19:27 |
corvus | tristanC: wow, maybe i have a jvmflags setting of "-Dzookeeper.serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory" -- i'll look into that after lunch | 19:28 |
openstackgerrit | David Shrewsbury proposed zuul/nodepool master: Add options to CLI info command https://review.opendev.org/712539 | 19:33 |
openstackgerrit | David Shrewsbury proposed zuul/nodepool master: WIP: Support uploads in 'info' CLI command https://review.opendev.org/712775 | 19:33 |
*** jamesmcarthur has joined #zuul | 19:35 | |
mordred | Shrews: it's hacking doing it - I don't know what changed to cause this to start being printed out - .... | 19:36 |
mordred | what in the ... | 19:37 |
mordred | Shrews: congratuations! you have just found mordred's afternoon rage-nerdsnipe | 19:37 |
Shrews | \o/ | 19:37 |
tristanC | corvus: that flags seems to fix the issue indeed | 19:38 |
Shrews | mordred: it's not like you could go watch ACC basketball anyway | 19:38 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 19:41 |
tristanC | also, it doesn't seems like any zookeeper operator/helm-char/ansible-roles are able to manage TLS | 19:44 |
mordred | Shrews, clarkb, corvus: remote: https://review.opendev.org/712778 Remove hacking from requirements <-- | 19:45 |
clarkb | mordred: somehow that is in merge conflict | 19:45 |
mordred | dib apparently has hacking in real requirments, not just test-requirements.txt. | 19:45 |
mordred | hah | 19:45 |
clarkb | maybe you didn't update dib before committing? | 19:46 |
mordred | updated | 19:46 |
mordred | yeah | 19:46 |
clarkb | mordred: also maybe flake8 should be in requirements? | 19:46 |
mordred | clarkb: no, I don't think it should be | 19:47 |
mordred | I don't think someone installing diskimage-builder needs to install linting tools | 19:47 |
mordred | that's _way_ inappropriate | 19:47 |
corvus | tristanC: i just recreated everything without that env var, and it still works | 19:48 |
mordred | clarkb: I could add a check in dib-lint and print an error message "you need to install flake8 to use dib-lint" | 19:48 |
clarkb | mordred: ya that might be a good option, just so its clear what changed and why things have failed (if they do) | 19:49 |
corvus | tristanC: so just having it in zoo.cfg should be sufficient | 19:49 |
clarkb | mordred: we run that linter on project-config iirc so may be able to test it there | 19:49 |
tristanC | corvus: oh, i had it commented from the zoo.cfg when i disabled the quorum setting | 19:50 |
openstackgerrit | Monty Taylor proposed zuul/nodepool master: Stop using hacking for anything https://review.opendev.org/712781 | 19:50 |
mordred | clarkb: ++ will do | 19:50 |
mordred | Shrews: ^^ once we release a new dib with that patch applied, the license lines will disappear | 19:51 |
clarkb | what does it think is wrong with the license? | 19:51 |
clarkb | (I'm too lazy to run tox -re pep8) | 19:51 |
corvus | tristanC: ah. i think that setting is really needed for either client or server. | 19:52 |
mnaser | clarkb: i think this is what Shrews pasted - http://paste.openstack.org/show/790628/ | 19:53 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 19:53 |
corvus | tristanC: ^ updated to clarify that | 19:53 |
clarkb | seems like that is a legit bug in hacking? it shouldn't care about whitespace being ' ' or '\n' | 19:54 |
mordred | clarkb: updated dib patch | 19:54 |
Shrews | mordred: woohoo! | 19:54 |
mordred | clarkb: sdague decided that only chekcing the first 11 lines was ok | 19:54 |
mordred | clarkb: apparently some of our files in nodepool have chosen to use 12 lines | 19:55 |
mordred | clarkb: but what's worse is that it spews the message EVEN THOUGH WE IGNORE H | 19:55 |
mordred | which is completely inappropriate | 19:55 |
clarkb | ya I guess my point is, lets stop running it inappropriately but maybe also we should file a bug or fix hacking? | 19:56 |
clarkb | I dunno | 19:56 |
mordred | clarkb: it is a legit bug in hacking ... but I think the first step is to de-hacking nodepool since it doesn't even actually use hacking ... but it turns out removing it from our test-requirements has no effect. also - it means our pin on the version to an old one was being ignored | 19:56 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 19:57 |
mordred | so the first step is to make it POSSIBLE to stop using hacking in nodepool, which is currently impossible to do | 19:57 |
clarkb | ++ | 19:57 |
corvus | not for nothin', but the literal text of the "how to apply" appendix of the actual apache license as published by the asf is 12 lines, so i feel like that's a not unreasonable choice. | 19:57 |
mordred | sorry - I meant 12- https://opendev.org/openstack/hacking/src/branch/master/hacking/checks/comments.py#L137-L170 | 19:59 |
clarkb | ya nodepool is doing it in 11 and tripping the error | 20:00 |
mordred | but still - in some of our files we're wrapped slightly differently ... and I don't think we should care :) | 20:00 |
clarkb | but changing a \n to a ' ' doesn't change the meaning of the license | 20:00 |
mordred | nope | 20:00 |
mordred | this is mostly one of those "maybe let's get ourselves out of the path of needing to chase such things" | 20:00 |
corvus | yes, i support the dehackification | 20:01 |
tristanC | corvus: alright thanks. i also add issue with running the zk-ca.sh script on fedora. it seems like it is loading /etc/pki/tls/openssl.cnf and failing because of a missing new_certs_dir option. | 20:01 |
*** gmann_lunch is now known as gmann | 20:01 | |
tristanC | had issues* | 20:01 |
corvus | we could bundle an openssl.conf, but it's huge | 20:03 |
openstackgerrit | Monty Taylor proposed zuul/nodepool master: Stop using hacking for anything https://review.opendev.org/712781 | 20:03 |
tristanC | corvus: here is what i wrote in the end: https://review.opendev.org/#/c/712759/4/roles/zuul-ensure-zookeeper-tls/tasks/main.yaml | 20:03 |
corvus | tristanC: in k8s, cert-manager may be helpful -- but ideally there would be a zk operator with cert-manager integration | 20:04 |
corvus | tristanC, mordred: we may need to decide soon whether we can rely on an external zk operator, or if we need to implement it in zuul-operator | 20:05 |
tristanC | corvus: i haven't find an existing thing that can deploy zookeeper with tls yet | 20:06 |
mordred | corvus: maybe, given all the work you and tristanC have been doing to get this right for how we're using it, it might be better to just do it in ours? | 20:07 |
corvus | maybe so? at this point, just having zuul-operator also spin up 3 zk nodes is probably not crazy | 20:07 |
mordred | yeah. and we could also take a parallel task to find a "good" operator and maybe work with them to add the support we need? | 20:08 |
tristanC | how about creating a regular ansible role using the zk-ca.sh script, and then use that in the zuul-operator? | 20:08 |
mordred | maybe? but maybe it would be better to use cert-manager inside of k8s? | 20:09 |
corvus | tristanC: where does the ca end up in your operator patch? | 20:09 |
tristanC | corvus: in the operator work dir | 20:10 |
corvus | tristanC: and that's a persistent volume? | 20:11 |
corvus | (so we'd only lose the ca and certs if the operator was deleted?) | 20:11 |
tristanC | the certs are saved as secrets | 20:12 |
corvus | right, but the CA is a directory that contains a bunch of files | 20:12 |
tristanC | well, in that initial PS, i only saved the file needed by zk and zuul/nodepool | 20:13 |
corvus | so if you issue a cert for a new host, you'd want to keep that around, otherwise you're going to end up with a different root cert | 20:13 |
tristanC | right, at the moment the operator doesn't manage more than one zk pod | 20:13 |
corvus | tristanC: if it's easy to keep that around permanently, using the script long-term might be okay, but if we go too much further than that, we'd probably end up re-implementing cert-manager, so it might be worth a look to see if we can use it here. | 20:14 |
mordred | ++ | 20:14 |
*** Goneri has quit IRC | 20:18 | |
corvus | tristanC: in fedora 31 i see a new_certs_dir option | 20:19 |
corvus | tristanC: oh, it's because it sets this: dir = /etc/pki/CA | 20:20 |
tristanC | corvus: i understand. though i don't know cert-manager, are we going to require that for zuul? | 20:20 |
corvus | tristanC: i don't think zuul has any use for it | 20:20 |
tristanC | and what about non k8s user, is there other tool we can use instead to setup zk tls? | 20:21 |
corvus | tristanC: i'm unaware of any which is why i wrote one | 20:21 |
mordred | corvus: well - unless we decided that it's better to use cert-manager than zk-ca.sh inside of k8s - at which point I'd think we should just require it | 20:21 |
mordred | (for k8s) | 20:21 |
corvus | mordred: yes... maybe i'm not following the conversation? | 20:21 |
mordred | maybe *I*'m not following the conversation | 20:22 |
corvus | i thought the question was: "should zuul require cert-manager?" and zuul (the python application) doesn't use certs for anything... | 20:22 |
mordred | right. I agree | 20:22 |
tristanC | arg, well, `org.apache.zookeeper.common.X509Exception$SSLContextException: Failed to create KeyManager` in https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_36d/712759/4/check/zuul-operator-functional-k8s/36d27e5/docker/k8s_zk_zuul-zk-0_default_5abf63cc-83a7-4b60-a1b5-985777c338ed_0.txt | 20:23 |
corvus | i think the question of whether zuul-operator should require/use cert-manager is a good, relevant question and is open for discussion, and i don't know the answer. | 20:23 |
mordred | I thought the question was asking if the zuul k8s operator was going to or should require cert-manager | 20:23 |
mordred | yeah | 20:23 |
mordred | I tink it's one of the options we could decide on | 20:23 |
corvus | tristanC: looks like | 20:23 |
corvus | Caused by: java.io.IOException: Invalid keystore format | 20:23 |
corvus | is the underlying error | 20:23 |
mordred | I think the zuul-operator should have one and only one mechanism to manage certs for zk - and right now it seems like either an ansible role using zk-ca and using cert-manager are the two possibilities we've identified | 20:24 |
tristanC | i guess we should check if cert-manager does work for zk certs. | 20:24 |
corvus | tristanC: i know that cert-manager can make self-signed certs. what i don't know without more research is whether it can operate as a ca (so all the certs are signed by a single root cert) and how difficult it would be to get those either into a JKS or a pcks8 pem encoded format (with an encrypted key) -- those are the 2 formats zk can handle. | 20:26 |
tristanC | corvus: (failure to create KeyManager may be related to an invalid when resulting in a skip task) | 20:26 |
corvus | the first thing would be a requirement for us. the second is probably something we could bridge in zuul-operator if we needed to. we can fetch a pem cert and do the keytool import like zk-ca.sh is doing. | 20:26 |
mordred | corvus: yes to the first: https://cert-manager.io/docs/configuration/ca/ | 20:27 |
mordred | corvus: experimental support for JKS has been added: https://github.com/jetstack/cert-manager/commit/98bc0d52f9f5c99ec58703b93d72af5b34408641 | 20:28 |
corvus | mordred, tristanC: then i would recommend that we try "porting" zk-ca.sh to zuul-operator as tasks that integrate with cert-manager. | 20:28 |
corvus | it'd be cool if cert-manager could generate the key for us | 20:29 |
mordred | yah | 20:29 |
corvus | mordred: oh, you might be able to use a SelfSigned Issuer to get a key to then give to a CA Issuer | 20:29 |
mordred | corvus: oh yeah - good point | 20:30 |
corvus | see 2nd pgraph of https://cert-manager.io/docs/configuration/selfsigned/ | 20:30 |
mordred | corvus: there is also an article about doing this in openshift: https://developers.redhat.com/blog/2017/11/22/dynamically-creating-java-keystores-openshift/ | 20:30 |
corvus | those are all steps in zk-ca.sh -- the first is create a keypair, the second is make a ca from the keypair, etc. i think it may be pretty straightforward | 20:31 |
mordred | ++ | 20:31 |
mordred | corvus: apparently in openshift there is a CA already | 20:31 |
corvus | honestly, at the end of the day, it probably won't be much different than using zk-ca.sh, except that the resulting data are all k8s objects which may be more convenient for k8s users | 20:32 |
mordred | yeah. may make debugging something more transparent to folks operating in that environment and stuff | 20:32 |
mordred | and/or friendlier for things like doing a gerrit+zuul install in the same k8s with the gerrit also using the new zookeeper-based HA stuff | 20:33 |
mordred | (obviously not our first concern here - but if we're using k8s primitives maybe that's a friendly future step) | 20:34 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 20:34 |
corvus | tristanC: fwiw, zk-ca.sh is expecting the default openssl.cnf: https://github.com/openssl/openssl/blob/master/apps/openssl.cnf#L45 | 20:35 |
tristanC | but is cert-manager already available, or is this something we now have to worry about installating and maintaining? | 20:35 |
corvus | tristanC: it looks like fedora has changed that; i'm not sure what we should do to better support fedora -- we may just have to bundle our own conf file? | 20:36 |
clarkb | re k8s CA that will allow any k8s issued cert from that CA to talk to zk if doing client cert auth | 20:36 |
clarkb | (potentially similar issue to using LE) | 20:37 |
*** hashar has joined #zuul | 20:37 | |
mordred | clarkb: yeah - that would be in teh openshift case of using the existing CA | 20:37 |
corvus | that might be a good reason to use cert-manager even in openshift | 20:38 |
tristanC | corvus: as said on the review, i think most (non-k8s) user are going to use zk-ca to configure their zookeeper. Thus if it doesn't work on some system, we should at least document that, or fix it | 20:38 |
mordred | clarkb: I thnk for normal k8s cert-manager we'd be creating our own CA as a cert-manager resource | 20:38 |
mordred | corvus: yeah | 20:38 |
corvus | tristanC, mordred: i think we expected zuul-operator to interact with other operators. i think the general approach is to expect someone to install cert-manager before installing zuul-operator. but as long as zuul-operator has permissions to install cluster-wide objects (part of cert-manager is non-namespaced), i guess it could. | 20:38 |
corvus | mostly, i've seen instructions like: run this kubectl to apply cert-manager, then run this kubectl to apply zuul-operator | 20:39 |
mordred | corvus: yah. I think there are some mechanisms where we can express that we want zuul-operator to install cert-manager - but I think as step one just having the instructions be "install cert-manager then install zuul-operator" should be fine | 20:39 |
mordred | yeah | 20:40 |
mordred | that seems to be perfectly acceptable for folks | 20:40 |
corvus | tristanC: okay, i think we can put a copy of openssl.cnf in zuul/tools and have zk-ca.sh reference $TOOLDIR/openssl.cnf | 20:41 |
tristanC | corvus: i left a couple comment about usability issue in PS10 | 20:45 |
corvus | tristanC: thanks, i took notes on cert-manager in https://review.opendev.org/712759 | 20:47 |
tristanC | corvus: yeah, i'm trying to use cert-manager... it's a whole new world -_- | 20:48 |
tristanC | corvus: what keytool version are you using in your test? using the one from java-11-openjdk-11.0.6.10-0.fc30.x86_64 seems to result in an invalid keystore | 20:52 |
corvus | tristanC: one important concept to note is that a ClusterIssuer works across namespaces, but since this is for zuul only, we can use regular Issurers which exist inside just the zuul namespace | 20:53 |
corvus | tristanC: openjdk-11-jre-headless from ubuntu | 20:54 |
corvus | 11.0.6+10-1ubuntu1~18.04.1 | 20:54 |
corvus | wow. those look they should really be the same. | 20:54 |
mordred | openjdk version "1.8.0_222" is the jdk that's in the zookeeper image | 20:55 |
corvus | mordred: i ran zk-ca.sh locally and bind-mounted the results in | 20:55 |
mordred | corvus: and it's working for you but not for tristanC? | 20:55 |
corvus | appears that way | 20:55 |
mordred | o_O | 20:56 |
* mordred returns to being less useful | 20:56 | |
corvus | i may be able to repeat this on a fedora container | 20:56 |
clarkb | mordred: AJaeger has a good comment on that dib change | 21:00 |
corvus | tristanC: the files i created under fedora work fine | 21:00 |
tristanC | corvus: arg, ok. thanks for confirming | 21:01 |
corvus | tristanC: see the comment i just left on 712759 -- that may be the problem | 21:03 |
tristanC | corvus: oh good catch, but i think that's only used client side | 21:05 |
tristanC | i'm trying with a fqdn | 21:05 |
corvus | tristanC: oh yep, that's right. | 21:05 |
tristanC | corvus: does nodepool needs to know about EXPORT_PASSWORD=foobar ? | 21:14 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 21:15 |
corvus | tristanC: no, that's a temporary password for the pkcs12 export, which is no longer used after it's imported into the keystore | 21:16 |
tristanC | then i don't understand why there is an `Invalid keystore format` when using zk-ca and keytool from the operator-sdk image | 21:18 |
corvus | tristanC: i don't either, but it could be as simple as the file isn't there or has the wrong perms; do you have an environment where you can run it locally and log into the pod and check? | 21:20 |
corvus | (i believe supplying the wrong password does give a different error, so it's probably not that) | 21:21 |
openstackgerrit | Monty Taylor proposed zuul/nodepool master: Be explicit about base image source https://review.opendev.org/712798 | 21:25 |
*** rlandy is now known as rlandy|afk | 21:32 | |
*** hashar has quit IRC | 21:40 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 21:40 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 21:43 |
tristanC | corvus: indeed, so the issue was caused by the k8s secret using `stringData`, which doesn't work for jks file | 21:44 |
tristanC | now, onto testing cert-manager experimental jks support :) | 21:45 |
corvus | \o/ | 21:45 |
mordred | woot! | 21:45 |
mordred | yay b64encode! | 21:45 |
corvus | fwiw, i believe we can use a pem-encoded file instead of jks, but zk still wants the key to be encrypted, so i didn't see much of a reason to fully test that code path. but if anything would be easier that way, we can try it. | 21:46 |
corvus | (ie, a file with "--BEGIN ENCRYPTED PRIVATE KEY--") | 21:47 |
mnaser | is it a good time for me to start the process of changing https://zuul-ci.org/docs/zuul-jobs/python-roles.html#rolevar-ensure-tox.tox_prefer_python2 to 'false' by default (im thinking propose a patch changing it, send an email to zuul-discuss, wait 2 weeks and then get it merged?) | 21:47 |
mnaser | i ask because there's a lot of other changes in flight and in case we wanted to stagger changes | 21:47 |
clarkb | mnaser: ++ | 21:48 |
clarkb | that shouldn't really affect opendev. Our tox is already python3 most places and once we switch off preinstalling tox we'll set prefer_python2 to false (if not yet default) to repserve that behavior | 21:48 |
openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: ensure-tox: use python3 by default https://review.opendev.org/712804 | 21:50 |
mnaser | corvus: if that seems sane to you, i can also shoot off the email and start the 2 week timer ^ | 21:51 |
corvus | mnaser: sounds like a plan | 21:57 |
*** etp has quit IRC | 22:15 | |
*** etp has joined #zuul | 22:16 | |
openstackgerrit | Merged zuul/nodepool master: Be explicit about base image source https://review.opendev.org/712798 | 22:25 |
*** jamesmcarthur has quit IRC | 22:30 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add missing zuul service volumes https://review.opendev.org/712811 | 22:44 |
*** rlandy|afk is now known as rlandy | 22:55 | |
tristanC | corvus: found an issue with the scheduler config, which looks like that when a kazoo client connect without the use_ssl option: https://zuul.opendev.org/t/zuul/build/a4a3fe41171a4133a9a35bdc40836e4e/log/docker/k8s_zk_zuul-zk-0_default_2a009824-2213-4dac-a488-5665a91fd217_0.txt#61 | 22:56 |
corvus | tristanC: what does zuul.conf look like? | 22:58 |
tristanC | corvus: i mean here: https://review.opendev.org/#/c/712531/13/zuul/cmd/scheduler.py@162 | 22:59 |
corvus | tristanC: oh i see | 23:00 |
corvus | tristanC: the argument is set here: https://review.opendev.org/#/c/712531/13/zuul/zk.py | 23:01 |
corvus | so if it's not being used, we should check the zuul.conf | 23:01 |
tristanC | searching for zuul.conf in https://zuul.opendev.org/t/zuul/build/a4a3fe41171a4133a9a35bdc40836e4e/log/docker/k8s_ansible_zuul-operator-5d8c859999-7mflj_default_d3c055c0-5f53-40a3-a6eb-fed418675921_0.txt#87 shows this content: http://paste.openstack.org/show/790652/ | 23:02 |
tristanC | arg, so it maybe something else | 23:02 |
*** Defolos has quit IRC | 23:06 | |
*** Goneri has joined #zuul | 23:08 | |
tristanC | or perhaps the depends on zuul image didn't work, according to some bug report, that `not an SSL/TLS record: 00000` error usually means a non ssl connection attemps | 23:18 |
tristanC | and running a minimal kazoo client works with these args {'hosts': 'zk:2281', 'use_ssl': True, 'keyfile': '/etc/zookeeper-tls/clientkey.pem', 'certfile': '/etc/zookeeper-tls/client.pem', 'ca': '/etc/zookeeper-tls/cacert.pem'} | 23:19 |
corvus | tristanC: yep, i think i missed zuul-operator in a recent change; 1 sec | 23:20 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Use explicit provides/requires for container jobs https://review.opendev.org/712816 | 23:21 |
*** jamesmcarthur has joined #zuul | 23:22 | |
mordred | ++ | 23:22 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Update to dhall lang v14 https://review.opendev.org/710649 | 23:23 |
openstackgerrit | James E. Blair proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 23:23 |
corvus | tristanC: ^ rebased your changes on that one; that should fix the depends-on. | 23:23 |
tristanC | oh right, thanks! | 23:24 |
corvus | tristanC: i've been working on a change to quick-start and have run into "javax.net.ssl.SSLHandshakeException: no cipher suites in common". i'm stumped there, and am going to stop for today and resume this tomorrow | 23:25 |
tristanC | corvus: i haven't seen that one. my latest result is "2020-03-12 23:17:14,865 [myid:1] - INFO [nioEventLoopGroup-4-1:X509AuthenticationProvider@172] - Authenticated Id 'CN=client,OU=Org,O=Company Name,L=Oakland,ST=California,C=US' for Scheme 'x509'" | 23:26 |
openstackgerrit | James E. Blair proposed zuul/zuul master: WIP: use ZK TLS in quickstart https://review.opendev.org/712817 | 23:27 |
corvus | tristanC: that looks correct :) | 23:27 |
*** jamesmcarthur has quit IRC | 23:27 | |
corvus | there's the WIP on quickstart | 23:27 |
tristanC | i'm not sure how zuul-operator upgrade should looks like, iiuc we need to tag and manage upgrade with the OLM or something, but in the end, i think that's great how the zuul-operator can manage things like zookeeper tls transparently for the user. | 23:29 |
corvus | yeah, maybe we can not worry too much before we tag a 1.0 :) | 23:34 |
*** jamesmcarthur has joined #zuul | 23:37 | |
mordred | I agree with both of you | 23:42 |
ianw | i just changed a bunch of node types in jobs @ https://review.opendev.org/712819 but it seems that zuul hasn't decided to run those jobs | 23:45 |
ianw | they all have specific files: matches, but i feel like this is something that should gate ... you could potentially break the job when it commits if it never ran? | 23:46 |
*** jamesmcarthur has quit IRC | 23:49 | |
*** threestrands has joined #zuul | 23:50 | |
mordred | ianw: I thought zuul would treat changes to a job as a reason to run the job | 23:51 |
ianw | mordred: me too, i wonder if this is a corner case that slips through somehow | 23:51 |
fungi | possible it doesn't consider node changes in that | 23:55 |
ianw | https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L2989 updatesJobConfig would be about where i'd expect it; if that returns it overrides the files matcher | 23:55 |
tristanC | corvus: mordred: not sure what's going on, but the depends-on doesn't show the same zuul registry tag name, see the references i commented in https://review.opendev.org/#/c/712816/1 | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!