[12:53:13] cdanis: I don't recall what was your conclusion about s10 and dbctl and if you double checked if RO should work via dbctl? [12:53:26] s10 is wikitechwiki? [12:53:28] yep [12:53:29] labswiki? whatever [12:53:32] yeah, that will work [12:53:39] cool - thank you <3 [12:53:45] it's the wikitechlabsdevwikidev that won't [12:53:47] s11 [12:53:58] yeah, that's not an issue [13:34:16] <_joe_> I don't even [13:34:31] <_joe_> can we stop having all these unicorns? [13:35:11] <_joe_> on one side, I get asked to install php-ldap on all appservers (which I'm not happy about) to make wikitech less of a snowflake [13:35:23] <_joe_> and on the other, we keep adding ad-hoc stuff like this [13:35:39] I don't think there's a reason why s11 needs to be the way it is [13:35:43] <_joe_> ok, I think we will need a meeting [13:46:56] I think s11 only exists because labswiki and labtestwiki are on db servers [13:47:17] uh, on *different* db servers [13:47:27] s11 lives in codfw [13:48:06] that's still a different db server :P [13:48:49] <_joe_> I'm not sure why we need a test for wikitech to live in the production environment - I'm sure there are reasons, I just am unaware [13:58:06] I imagine that wiki is probably mostly redundant these days [13:58:33] Back when it was hosting the open stack manager stuff, it probably had more purpose to allow testing config and such [14:00:21] or does this wiki still do some management of the infrastructure in codfw? [14:00:54] https://labtestwikitech.wikimedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&limit=50&days=30&urlversion=2 [14:00:56] very active.. [14:53:38] so... anyone here familiar with debian packaging of python code? because i'm developing a severe case of hatred for all the various under-documented parts of it [14:56:06] I've done it kormat, but I'm no expert, if you want we can summon TheExperts ;) [14:57:34] <_joe_> kormat: which of the 25 ways you are following? [14:57:48] _joe_: dh_python3/pybuild/hate [14:58:35] <_joe_> kormat: ok if you're pouring hate into it, it should work out of the box [15:01:16] _joe_: https://gerrit.wikimedia.org/r/c/operations/software/wmfmariadbpy/+/616846 here's what i have so far [15:01:22] so if for some reason it *doesn't* work out of the box, try hating it more [15:01:30] i've been looking at the packaging for confctl [15:01:40] last I looked into it, with a working/sensible setup.py you should be able to sort of autogenerating the rest [15:01:44] but stuff it does does not work here [15:01:50] rzl: on it [15:02:02] godog: is there really such a thing as a sensible setup.py? working, sure. [15:02:13] working, sensible, setup.py: choose any two [15:02:19] :) [15:02:31] <_joe_> kormat: we have several debian devs here [15:02:34] haha fair, I'll reword that as "with enough metadata" [15:02:45] <_joe_> godog, moritzm, ema, paravoid, who else? [15:03:03] <_joe_> I will defer to their Superior Knowledge [15:03:38] kormat: I like the setup.py files that dephell generates from my poetry pyproject.tomls [15:03:43] in that I never have to think about them or look at them [15:03:46] that's pretty good for a setup.py [15:05:27] cdanis: the question is, does it work to generate multiple deb paclages from the same setup.py? :D [15:05:30] out of the box [15:05:42] poetry and setup.py know nothing about either of those things [15:25:26] kormat: what's the purpose of debian/osc-host.install? [15:25:48] I imagine you're trying to ship osc_host with the package, that should happen automagically [15:26:24] or at least, I've tried removing osc-host.install and things look good on deneb [15:27:39] ema: what i'm currently trying to do is to put the libraries in one package, and scripts in another [15:27:53] osc-host was a quick way to test [15:28:54] if you look at https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/conftool/+/refs/heads/master/debian/python3-conftool.install, you'll see a line like `usr/bin/confctl usr/bin`. i cannot get that sort of thing to work at all in this repo [15:29:27] oh, so you want a separate package shipping usr/bin/osc_host only? [15:29:44] ema: yes, that's the sort of thing i'm going for [15:29:53] why? :) [15:31:17] my thinking was that some scripts would only be needed on the cumin hosts, so those hosts would install the package containing those scripts (which depends on the library package) [15:31:36] (they would also only _work_ on cumin hosts) [15:33:56] kormat: I see! So it seems that the path to osc_host is not what dh_install wants [15:34:05] see dh_install(1) [15:34:21] you need: [15:34:22] debian/python3-wmfmariadbpy/usr/bin/osc_host usr/bin [15:34:28] ema: but.. why does it work for confctl above? [15:34:58] > The name of the files (or directories) to install should be given relative to the current directory, while the installation directory is given relative to the package build directory. [15:37:35] ema: that works! (though i'm still confused why) [15:37:35] kormat: I can only guess that at the end of the conftool build process you end up with a usr/bin/ relative to the current directory (ie: at the same level of where debian/ is) [15:39:06] hmm, ok [15:39:22] or who knows, maybe it does not work at all! [15:39:51] it does, i've built it/tested it [15:39:55] that's why i've been so confused [15:42:06] ema: how do i exclude osc_host from python3-wmfmariadbpy? [15:47:20] kormat: one way would be to rm the file after dh_install is called [15:47:32] kormat: something like https://unix.stackexchange.com/questions/445778/deb-multi-package-ignore-installation-of-some-files-during-packages-building [15:48:00] doesn't the .install file approach work too? [15:48:14] I think we do that in confctl to select only things in one and only things in the other [15:48:15] now I'll leave you alone with override_dh_install and go for a beer! ciao ciao [15:48:19] without explicit exclude [15:48:24] volans: it does for confctl. just not for me :) [15:48:34] ema: thanks, mostly :) [15:49:16] kormat: do you have a patch or code on deneb? I can have a look if you want [15:49:42] what i have is this: https://gerrit.wikimedia.org/r/c/operations/software/wmfmariadbpy/+/616846 [15:57:11] anyway, i'm out of brain quota for the day. o7 [15:57:23] kormat: ack, I'll have a look alter if possible [17:18:47] ryankemper: do you have a few minutes to chat about 20200723-wdqs-outage ? [18:46:36] cdanis: back now, I'm free in ~15 mins after search standup [18:46:39] or later today [19:01:35] ryankemper: it looks good overall! I just had one comment about there's no mention as to whether or not we were passing along a bug report re: the apparent deadlock to upstream [19:02:36] that's a good question, the thought hadn't occurred to me [19:03:14] I'll ask our devs if we've already submitted one, I assume not if there's no mention of it in https://phabricator.wikimedia.org/T242453 but will check [19:03:21] I think opening an upstream ticket probably makes sense [19:03:33] great :) [19:07:09] cdanis: so some context I just got from erik, blazegraph was acquired by amazon awhile back and is more or less not under active development [19:07:16] apparently they respond to our e-mails but not much else [19:07:31] so that might change the calculation on whether it's worth the effort of opening a report with them [19:08:39] ah [19:08:52] unfortunate [19:10:47] I'll update the incident report to include the above context [19:13:06] thanks! [19:35:25] if there is anyone who would like to review a change to our puppet-lint styleguide check (ruby/rspec) would be great - https://gerrit.wikimedia.org/r/c/operations/puppet-lint/wmf_styleguide-check/+/616895 optomistic thanks in advance :)