[13:54:50] volans: i have another python question to annoy you with! :) [13:56:06] volans: the code i'm currently writing has a dependency on a lib which uses a config file [13:56:39] the dependency has a test version of the config in its tree, and its tox.ini sets up an env var to point to it, so that you can run unit tests etc [13:57:10] but this doesn't help when code in a different repo uses that lib [13:58:57] kormat: go on [13:59:24] so.. one approach could be to do `ENV_VAR = /path/to/external/lib/test/config.ini` [13:59:30] but i'd have to know what that path is [14:00:02] is there some non-awful way out of this? [14:00:49] you're talking tox so I guess that tox is installing the dependency via pip in the venv created by tox itself, is that correct? [14:01:23] yeah [14:02:00] so first thing to check is if the lib ships the test config in the package installed via pip, often tests are not shipped [14:02:22] it does not :( [14:02:31] (for reference: the lib is wmfmariadbpy) [14:02:45] ahahahah, so self-inflicted pain [14:02:53] * kormat mutters [14:03:20] some random ideas [14:03:42] 1) ship a test config in you other package too, will be a pain to keep it up to date with the "original" [14:04:14] 2) change wmfmariadbpy to make the config optional and in case it's missing the defaults are those that makes the testing work [14:04:34] (if that makes any sense, might well not) [14:06:18] * kormat is waiting for the good idea [14:06:34] oh, i have a variation [14:06:44] right now the env var provides a path to a test config [14:06:48] 3) modify wmfmariadbpy to ship the test and then pass it loading it from {envdir}/lib/python3.X/site-packages/wmfmariadbpy/... [14:06:57] i could instead have the env var toggle _using_ a test config, which isn't an actual file on disk [14:07:06] sure [14:08:37] going to muck around with 3 to start with, as it doesn't require changing code behaviour [14:08:41] wish me luck.py [14:09:09] I'm not sure how easy would be to get 3.X from tox [14:10:30] but is only one per venv, so you could use globbing :D [14:10:45] the only variable that might help is {envpython} but would need to be mangled [14:10:56] `{envsitepackagesdir}` [14:11:05] looks promising [14:12:05] ohh nice, TIL [14:12:15] never used it :D [14:12:39] doesn't seem super safe/stable as solution (3) but is the one with probably least resistance [14:13:09] i'm confused. solution (3) is what i'm working on? [14:13:40] you said "going to muck around with 3" so I assumed so :) [14:13:52] what I meant is: [14:14:33] as solution 3 is loading a config file from the installed packages dir and depends anyway on how "upstream" ships the config file it might notbe the safest solution, but given that you manage upstream too it should be ok [14:15:29] I likes 2bis fwiw :) [14:17:15] *liked [14:21:20] looks like all solutions that aren't 1) require upstream changes, so leaning towards 2bis. i'm not even sure how to _test_ 3. [14:22:38] ok, fair enough [14:23:34] my drive by python advices is (2) as a clean approach that's a pretty common paradigm [14:23:40] s/advices/advice/ [14:23:54] ack ๐Ÿ‘ [14:24:33] i don't want to do pure-(2), as the config file is shipped by puppet in prod, and if it's missing, i don't want Weird Shitโ„ข to occur. but (2bis) seems pretty neat [14:26:53] right [15:37:05] volans: 2bis: https://gerrit.wikimedia.org/r/c/operations/software/wmfmariadbpy/+/744029 [15:38:13] kormat: in a meeting, will look at it shortly [15:38:22] ๐Ÿ‘ [16:33:59] kormat:drive-by comment! [17:33:49] kormat: {done} sorry for the delay [20:45:51] can you insert a text file into a google doc similar to the way we can insert pastebins in phabricator tickets? Like an inline long text file that is in the google doc, or like an attachment to the doc as if it was an email [20:46:45] I would probably just include a link to the text, either as another google doc or a phab paste or whatever [20:47:45] *nods*, I don't really want to make it public or I would use people.wm.org and link to it. [20:47:58] if you made it a second doc with "viewable to anyone with the link," that takes care of making sure the visibility matches [20:48:20] cool, yes, will do that [21:29:34] is it an 'incident follow-up' if you found it during the incident but besides "I had a reason to look at certain logs" there is no relation to the incident? just "if you look at anything too close you find a new thing" [22:12:44] mutante: I wouldn't consider it a follow-up, unless it was related to the actual incident [22:13:17] also, is there a cumin command I can use to figure out what hosts have puppet disabled? [22:13:59] I disabled puppet on all A:mw hosts, but my cumin to roll out my change slowly failed, so most hosts are re-enabled but not all [22:15:30] legoktm: if [ ! -f "/var/lib/puppet/state/agent_catalog_run.lock" ]; then [22:15:34] grep for the lock file [22:15:38] like the scripts do [22:15:47] and thanks for the other reply, ack [22:16:14] legoktm: also https://wikitech.wikimedia.org/wiki/Cumin#Run_Puppet_only_if_last_run_failed [22:17:13] modules/base/files/monitoring/check_puppetrun.rb:runlockfile = "/var/lib/puppet/state/agent_catalog_run.lock" [22:17:16] modules/base/files/monitoring/check_puppetrun.rb:adminlockfile = "/var/lib/puppet/state/agent_disabled.lock" [22:17:25] one is "is it running now" the other is "is it disabled" [22:17:49] perfect, the second one is exactly what I wanted [23:07:57] Error: The text you wanted to publish was blocked by the spam filter. This is probably caused by a link to a forbidden external site. The following text is what triggered our spam filter: google.com/url?q=https://icinga.wikimedia.org/cgi-bin/.... [23:08:01] :p [23:08:04] (on wikitech wiki) [23:08:29] oh, because google inserts itsself when I copy URLs from a doc.. groaaan [23:09:46] so it saved me from making that edit and google.com is the forbidden site. ok :) [23:50:36] I feel like I would ace a quiz that asked me how many servers are in each MW app/api/canary/etc. pool because of how many times I've had to type it in for cumin [23:52:22] ;) haha [23:53:02] https://wikitech.wikimedia.org/wiki/Incident_documentation/2021-12-03_mx