[04:38:35] (not for wikimedia but I'm lost as hell) Does anyone know why the jobrunner would simply stop showing jobs with no icinga alert and no logs showing anything unexpected? [04:39:14] It looks like there was a traffic spike around when it stopped based on user reports [08:24:21] dear gerrit, what's with the leading garbage (`)]}'`) at the start of queries like https://gerrit.wikimedia.org/r/changes/?q=616846 ? :P [09:00:13] js leaking ? [09:17:06] could be [09:17:12] filed a task anyway [09:17:19] kormat: not sure but i think its all gerrit API calls that have that. there is a hack in the pcc script https://github.com/wikimedia/puppet/blob/production/utils/pcc.py#L84 [09:17:27] whats task ID curious to follow [09:17:36] https://phabricator.wikimedia.org/T259333 [09:17:47] thx [09:19:57] jbond42: heh, makes me wonder how much stuff will break if this gets fixed :) [09:20:17] lol true :) [09:21:48] ye olde json hijacking [10:06:05] can i trick some debian experts into reviewing my first wmf package? :) ema, moritzm perhaps? https://gerrit.wikimedia.org/r/c/operations/software/wmfmariadbpy/+/616846 [10:10:58] sure thing, I'll have a look later [10:12:07] great, thanks :) [10:12:23] and it's hardly your first package, given that you're the most active partman developer these days :-) [10:12:33] i... *hides* [12:48:29] moritzm: i put `buster-wikimedia` in the changelog file for wmfmariadbpy, and now reprepro is complaining that the distro doesn't match `stretch-wikimedia` when i try to upload it for that release. is it safe to use `--ignore=wrongdistribution`? [12:55:08] it depends, if you're building something in C and C++, you should definitely rebuild per distro. and even for script languages there can be differences depending on external dependencies. e.g. debmonitor is also written in Python, but gets rebuilt for each one [12:55:37] so you can either do "--ignore=wrongdistribution" (which will most probably be fine for wmfmariadbpy) [12:55:38] moritzm: i have built the package twice, once with DIST=stretch-wikimedia, and once with DIST=buster-wikimedia [12:55:45] it's the former i'm trying to import here [12:55:55] ah, so this is just the stale changelog header [12:56:00] yeah [12:56:06] simply do "--ignore=wrongdistribution", then [12:56:13] grand. thanks :) [12:56:14] given it's just cosmetic [12:57:56] mm. i found a new way for it to hate me: https://phabricator.wikimedia.org/P12132 [12:58:27] i guess this makes sense, the pool is common to all releases [12:59:14] moritzm: i should be using reprepro copy instead, i assume? [13:02:19] you can use reprepro copy, yes, but normally if you rebuild a package for a different distros, best to make sure to let them have a unique version like 0.1+deb9u1 and 0.1+deb10u1 (first rebuild for Debian 9/10) [13:02:31] that way they can also be kept apart in dpkg/debmonitor etc. [13:02:45] but in this case, simply "reprepro copy" [13:02:57] does that end up requiring a git branch for each release? [13:03:11] or how is that normally maintained? [13:10:57] no need for branches, simply a matter of changing the target distro in debian/changelog and triggering the builds [13:11:17] there's also a script by R.iccardo for debmonitor [13:19:20] ah. you change it locally on the build machine. gotcha. [13:20:56] yes, exactly [14:12:28] qq - in our dear java world we need to use truststores and keystores for CA-certs and private TLS keys, that is always really handy and nice (). We (Analytics) are currently using self-signed certs for hadoop etc.., but I noticed an increased usage of base::expose_puppet_certs in puppet [14:12:48] so I am wondering if creating a similar define to materialize java keystores/truststores could be acceptable [14:13:11] (until we have a PKI etc...) [14:14:20] for example, if a jvm needs to connect to a TLS endpoint and trust the Puppet CA cert, it will need a truststore file containing the cert [14:14:34] hmm, elukey could we use cergen for that? I'm pretty sure the puppet cert is put in some truststores already. i guess you want the hosts certs automated in some way in a keystore too? [14:15:25] ottomata: yes correct, plus IIUC using the puppet CA with cergen I cannot have new TLS certs with the hostname of the host (since already there) [14:15:29] right? [14:15:42] this is why I was thinking about packing the host's ones [14:16:45] so for hadoop, we'd just need to expose the puppet certs via truststores/keystores [14:19:07] that would be really nice. [14:19:20] maybe we could just use some functions from cergen to pack them? [14:19:33] but put them in a canonical place outside of the secrets/certrificactes dir? [14:20:06] either cergen or an exec via puppet [14:20:15] (if the file is not in the location etc..)