[03:45:19] (PS1) Awight: Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) [03:46:52] (CR) jenkins-bot: [V: -1] Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [03:51:57] (PS1) Awight: Do not include the bannerChoiceData RL module from tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196986 (https://phabricator.wikimedia.org/T91763) [03:52:41] (CR) jenkins-bot: [V: -1] Do not include the bannerChoiceData RL module from tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196986 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [03:55:33] hehe, good thing we have tests. [03:57:14] awight: hi! yeah I tried that approach already [03:57:37] (PS2) Awight: Do not include the bannerChoiceData RL module from tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196986 (https://phabricator.wikimedia.org/T91763) [03:57:46] AndyRussG: hi :) which one? [03:57:58] 196986 [03:57:59] I'm sort of just thrashing in the shallow water a bit [03:58:52] I understand! yeah that was exactly the first thrash I tried too [03:59:06] it turns out that hook is not called just when the JS tests are run [03:59:12] It's called anytime JS tests are enabled [04:00:36] awight: didja see this one? [04:00:37] https://gerrit.wikimedia.org/r/#/c/196882/ [04:01:03] AndyRussG: but wait... 196986 works [04:01:22] awight: no, you're still getting the warning, which is what we need to get rid uv [04:01:25] ah nope [04:01:27] haha [04:01:53] I was even more surprised that my other patch fails... *all* the tests. I don't understand the subtle evil causing that. [04:02:01] https://integration.wikimedia.org/ci/job/mwext-CentralNotice-qunit/574/consoleFull [04:02:27] yeah totally [04:02:56] This makes me very sad tho: https://gerrit.wikimedia.org/r/#/c/196985/ [04:03:19] How can that possibly break everything... [04:05:51] awight: well, that one removes the QUni warning! https://integration.wikimedia.org/ci/job/mwext-CentralNotice-qunit/572/consoleFull [04:05:59] hehe [04:06:34] And the failing PHPunit is I think a defect of the PHPunit tests. I even made a card for that: [04:06:58] https://phabricator.wikimedia.org/T92000 [04:07:06] I do think the db config patch is worthwhile on its own, cos that's something that should work out of the box. [04:07:30] If you think that's the most reasonable default config, I'm all for it! [04:07:31] lol "derp out" [04:07:43] AndyRussG: well, it's the config that developers are expecting [04:07:55] also, people running a single wiki [04:07:58] OK... Sure sounds good [04:08:31] I guess if we can pull T92000 out of the derp-weeds we'd have our solution [04:08:41] do you mind explaining what you discovered wrt the efCentralNoticeResourceLoaderTestModules hook? [04:09:04] awight: sure! It's called all the time, so long as JS tests are enabled on a wiki [04:09:05] I don't understand how we can add dependencies, but not remove them [04:10:06] Note also that the actual calculating of dependencies doesn't happen on the main php call, but on the client using info obtained in the fetch of RL startup code [04:10:35] * awight scowls [04:10:42] So that hook is not a hook to say that we're on Special:JavaScriptTest [04:11:31] I think Krinkle|detached didn't like the approach of my draft patch for creating a real testing mode in RL [04:11:51] yuck, I just read our docstring: "Place CentralNotice ResourceLoader modules onto mobile pages." [04:12:46] strangely enuf, someone who knows what they're doing wrote that... [04:13:05] or maybe he or she copypasted it? [04:13:08] * AndyRussG looks up blame [04:13:55] I guess I must have merged my function into the file and missed that. [04:14:58] Meh I wouldn't worry about it... Git blame can be BS sometimes [04:15:43] ok, I agree with how you explained ResourceLoaderTestModules [04:16:11] awight: my brain is a bit soupy and sloshy after a day of garden variety family craziness etc etc [04:16:37] sleep! [04:16:46] I need to cook some things for family, too [04:17:15] (Abandoned) Awight: Do not include the bannerChoiceData RL module from tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196986 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [04:17:27] really appreaciate your taking a look at this, I think the DB default config may well be the road to go [04:17:43] awight: cya tomorrow, enjoy cooking! [04:18:07] see you! [07:06:31] ccogdill: hi! Are you not getting the Silverpop success emails? e.g. "Jenkins build is back to normal" [07:06:56] I get notifications from Silverpop when it tries the import daily [07:07:00] at like 3am or something like that [07:07:07] about the failure only, though? [07:07:13] so I don’t hear from Jenkins, only Silverpop [07:07:18] no it tells me when it’s successful too [07:07:30] but if you retry it at 3:30am, Silverpop has already tried the import [07:07:39] it won’t try again until the next day unless I do it manually [07:07:41] ok I see. I'll add you to the Jenkins emails. [07:07:45] cool, thanks! [07:12:53] ccogdill: Unfortunately, I can't make Jenkins email every time, but I've added you to the recipients list, at least. [07:13:25] fyi, the sending rules are that it will email whenever the job fails, or whenever the job succeeds if the previous run failed... [07:13:36] In other words, I'll keep emailing you that I'm retrying the job :) [07:17:26] haha okay awight, that sounds like all I need :) [07:17:27] thanks! [07:47:26] (PS1) Awight: Fix accidentally swapped docstring [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197002 [07:50:57] (PS8) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/181238 (https://phabricator.wikimedia.org/T92000) [07:50:59] (PS2) Awight: Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) [07:52:05] (CR) jenkins-bot: [V: -1] Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [08:00:32] (PS3) Awight: Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) [08:00:34] (PS1) Awight: Use the one-argument form of wfGetDB when fetching the primary db [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) [13:25:32] (CR) Pcoombe: "It's just the languages which get specifically labelled in the pgehres.bannerimpressions table. Everything else gets a language of 'other'" [wikimedia/fundraising/tools/DjangoBannerStats] - https://gerrit.wikimedia.org/r/195612 (owner: Pcoombe) [14:51:26] (CR) AndyRussG: "Woohoo, looks great, thanks!! I'm just curious about the answer to the second inline comment (not a blocker, though, I don't think)." (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [14:59:10] (CR) AndyRussG: [C: -1] "Nice! ;) Just a couple ideas... (see inline)" (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [15:01:28] (CR) AndyRussG: "Looks like we have a better solution!" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG) [16:38:55] * awight is not sure whether AndyRussG or I ever went to sleep :p [16:39:31] hey. One thing I should admit right off the bat about my patches--the "db switching cleanup" might not be at all necessary for the fix. [16:39:43] awight: I slept! slighly less than ideal duration, but it's OK [16:40:10] I snuck it in there cos there were a lot of changes to the CNdb::getdb function, which I felt lazy about rebasing across [16:40:22] awight: I just realized that patch was a dependency! sorry I didn't see it before [16:40:32] It'd be nice to get the cleanup thu at the same time [16:40:35] well, I'm happy to take it out of you have disagreements [16:40:58] Ah I doubt I will. I just looked it over superficially but have not understood the full implications... [16:43:21] My neither, I'm afraid :) [16:43:26] *me [16:44:30] Ah hmm! OK well let's take it slowly and do it right, sound good? [16:44:45] bassoon! [16:44:57] (apparently mobile works tho) [16:55:14] awight: dang, i was hoping a python/mysql query/session timeout would be as simple as setting a parameter and catching an exception. Nope: http://stackoverflow.com/questions/1507091/python-mysqldb-query-timeout [16:57:09] I can implement some of those suggestions in tools/database, unless you've got another idea [16:57:18] (CR) Awight: Use the one-argument form of wfGetDB when fetching the primary db (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [16:57:39] ejegg: hey. Yeah I didn't see anything either. reading yr link... [16:57:49] eff. [16:58:04] gnarly, huh? [16:58:18] This is... Jenkins's responsibility :( [16:58:59] I think u heard that Jeff looked for a plugin to retry and there was only some frayed thing, "Naginator" maybe [16:59:17] mostly... but the job should still be able to kill its own queries on sigabort [16:59:20] It required you to install the "yahoo toolbar in your navigator" or something :) not quite right for us [16:59:24] which doesn't seem to be working at all [16:59:47] ejegg: oh. Yeah that should work. I mean, that should be baked into the stupid pymysql lib. [16:59:56] this is nasty [17:00:12] yeah, i even added more signal handler stuff a couple months back [17:00:16] and it seemed to work locally [17:00:21] If you're gonna get all 4-wheel on this though, what about digging deeper into query #23? [17:00:42] I'm thoroughly mystified [17:00:59] yeah, i really hoped the geonames shrink would fix it [17:01:12] nothing looks too crazy about that particular update [17:01:46] I know!! [17:02:00] * awight stares at EXPLAIN [17:02:56] The thing is... sql-abort is more proper, and will help us with a retry solution, but won't help the job run correctly [17:03:05] and it's either dying 'cause we moved it to prod, or dying 'cause it's now updating a temp table. neither of which makes sense [17:03:53] sql-abort? [17:05:09] (CR) Awight: Default to single-database configuration (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [17:05:41] ejegg: sorry, I was short-handing the feature you're suggesting we fix, where a sig_abort handler kills our db connection explicitly. [17:06:20] oh, we have that signal handler already, but it doesn't seem to be doing its job [17:06:26] right [17:07:18] hmm, wait, do you think it might be a stalled query #23 that's killing future runs? [17:07:37] can't be helping, anyway [17:08:16] hmm, though it would be a different temp table being updated for each connection [17:08:36] wouldn't be locking the read tables against other reads [17:11:14] cmjohnson1: if you have a minute, could you get us a copy of the fundraising master mysql slow query log going back to at least 8AM UTC, this morning? [17:12:46] ejegg: lemme get out of your way wrt the sig_abort fix :) [17:13:12] ok, i'll have some fun with multithreading [17:13:25] that certainly sounds like fun [17:15:44] ejegg: fwiw, I've been pretty happy with the "subprocess" module [17:18:37] awight: thanks, I'll take a look! [17:19:10] ejegg: well, lemme qualify that by "pretty happy except OMG do I really have to poll and communicate like this? why so borken?" [17:19:50] heh [17:21:32] ejegg: Interesting that query #23 has no joins [17:21:46] i think maybe here we want to use thread.join(timeout) - wouldn't subprocess have the same problems as jenkins killing the job [17:21:49] ? [17:24:08] ejegg: How does threading kill the subprocess? [17:24:45] ah, those are not full processes? [17:25:47] Do you know what issue Jenkins has with killing the job? [17:26:14] hmm, not sure how threading/multiprocessing are different. [17:26:21] jenkins just sends sigterm [17:26:41] and that seems to interfere with the onexit code that cleans up the sql connection [17:27:12] atexit, rather [17:27:17] it looks like threading uses LWPs, so we're in the original process's memory etc. [17:27:33] cool, that should work [17:29:10] sort of... but uncool cos of the GIL, I hope to not wrap my head around that [17:30:44] shouldn't matter too much, if one 'thread' is just waiting on mysql and the other is just checking a timer [17:30:59] not like we're doing any heavy python computation at the same time [17:31:11] ejegg: oof, note this like from https://docs.python.org/2/library/signal.html -- "only the main thread can set a new signal handler" [17:31:25] oh? [17:31:44] Sounds like what you'd want to do anyway, luckily [17:32:10] I found some reference to "signals not handled by python" therefore not possible to catch using atexit, but I haven't found the list of which those are yet. [17:32:40] yeah, atexit doesn't catch sigterm [17:33:02] so my change was to add a signal handler that does and calls the same db cleanup code before re-emitting [17:33:18] looking... [17:33:22] https://gerrit.wikimedia.org/r/#/c/185351/ [17:33:43] the re-emit is a different change set [17:33:57] well the code looks good [17:34:05] to my naked eye [17:34:20] re-emit: https://gerrit.wikimedia.org/r/#/c/185351/ [17:34:50] err, no, that's the same one [17:35:14] https://gerrit.wikimedia.org/r/#/c/185352/ [17:37:03] ejegg: here's a weird theory... see how there's a traceback at the end of the failure emails? [17:37:11] yeah [17:37:25] Maybe that's causing exit via some other signal [17:37:54] hrm? [17:39:02] well, atexit should handle it. But I'm thinking, something in python catches the SIGTERM and converts it to an exception. [17:39:23] whoa, that would be odd [17:39:44] how else would we get the exception, though? [17:40:07] huh, good point. [17:40:51] so maybe your try...catch is worth a look, at least for cleanup purposes! [17:41:23] I'm writing a silly test script... but we could run this from jenkins with a short timeout, to debug the exact order of crap [17:41:43] certainly wasn't doing that locally. when i ran it in one terminal and send it sigterm from another, it ran thru the signal handler as i expected [17:44:35] creepy, the signal handler is not called when I ^C... pasting 4 u... [17:45:07] ejegg: https://phabricator.wikimedia.org/P403 [17:46:08] just tweaked it slightly to say "atexit" [17:46:17] adding a jenkins job... [17:46:21] ctrl-c is sigint, right? [17:47:19] riight thx [17:48:09] http://tunnel/job/One-off%20runs/ [17:48:23] taking a look [17:48:32] urgh, need a better scratch dir [17:49:15] /tmp? [17:49:38] yep [17:49:43] setting g+w for u [17:50:16] 60 seconds later... [17:52:32] oh, Jenkins didn't time it out [17:52:43] oh, huh [17:53:33] "at least 3 minutes" silently helping [17:57:02] ahh! https://issues.jenkins-ci.org/browse/JENKINS-17116 [17:57:37] "There is documentation which states that Jenkins uses SIGTERM to kill processes, but "... looks like it's actually sigkill instead! [17:58:20] good find! [17:58:40] here's the confirmation :) /job/One-off runs/8/console [17:59:13] can't be caught [17:59:44] hrmph [18:00:44] well, mystery solved, problem clarified [18:01:39] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising Sprint G: Regression: interstitial page with PayPal even when the amount is good. - https://phabricator.wikimedia.org/T92705#1122189 (atgo) [18:01:52] Wikimedia-Fundraising-CiviCRM, Fundraising-Backlog, Fundraising Sprint G: Spike: What happened with this JP Morgan import? - https://phabricator.wikimedia.org/T92463#1122191 (atgo) p:Triage>High [18:01:58] ejegg: that's quite a bug to sit open for 2 years :,-( [18:03:07] yah [18:24:26] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1122333 (atgo) Howdy! So it looks like the solutions in this task were sort of bandaids to just ki... [18:30:10] K4-713: Hi! Uuuu I'm a doufus and didn't check my calendar before I stepped out this afternoon.. I'm working from a car with my laptop tetherd to a phone, we could try the hangout but it might die midway due to excess data usage :( [18:30:36] AndyRussG: No worries. We can totally reschedule. [18:31:30] K4-713: it's not inconvenient for u? I seem to be able to join the hangout, I did leave the Web cam off, tho [18:32:50] AndyRussG: Not at all. Actually... if it's now, I couldn't make it anyway. [18:32:50] K4-713: most times standup today work for me and I'll be back to normal network conditions [18:33:00] lol "working from a car"--you guys make me feel like a couch potato [18:33:05] K4-713: ah ok! phew [18:33:18] K4-713: apologies in any case [18:33:27] K4-713: when is good for you? [18:33:44] AndyRussG: As usual, my calendar knows more about that than I do. [18:33:51] @_@ [18:34:11] heh I know the feeling, silly machines... [18:34:51] Also, people like to kidnap me for meetings these days. [18:34:51] awight: the car's not moving.... [18:34:59] (bahaha) [18:35:17] :) [18:35:27] |car|trunk [18:36:09] kidnapp? meeting? [18:36:26] K4-713: I see a spot at 3pm your time today [18:36:28] like in "Sneakers" (1992) [18:36:39] awight: I WAS JUST THINKING ABOUT THAT. [18:36:51] AndyRussG: Seems likely / reasonable. [18:36:59] Let me double-check... [18:37:00] :p I have a clone of your database [18:37:18] Oh crap. [18:37:22] Now I'm in for it. [18:37:42] (PS2) Awight: Use the one-argument form of wfGetDB when fetching the primary db [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) [18:37:48] K4-713: OK I'll reserve the time, of course np if something more important comes up :) [18:37:57] K4-713: it's okay, it hasn't been synced since the '70s [18:38:04] AndyRussG: It shouldn't. I think. [18:38:09] Sorry I missed the conflict for now. [18:38:46] np, rather I'm sorry I'm a bit soupybrained with my planning [18:42:10] atgo: also thanks! [18:42:36] and apologies 8p [18:42:53] AndyRussG: btw, I'm curious to have your thoughts on my second comment here, https://gerrit.wikimedia.org/r/#/c/196985/3/CentralNotice.hooks.php,unified -- I can rewrite once I know which approach to take... [18:43:10] awight: K, lemme see [18:45:51] no worries andyrussg [18:46:01] atgo: :) [18:54:52] (CR) AndyRussG: Default to single-database configuration (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [18:55:03] awight: ^ [18:55:08] mmmm, cello! [18:56:43] AndyRussG|whistl: thanks! [18:56:56] (CR) Awight: Default to single-database configuration (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [18:57:01] (PS4) Awight: Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) [19:31:47] (PS5) Awight: Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) [20:05:58] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising Sprint G: Regression: interstitial page with PayPal even when the amount is good. - https://phabricator.wikimedia.org/T92705#1122860 (Pcoombe) Ah, you beat me to it. This is also happening when donating from banners banners. I can't tell whe... [20:08:43] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1122884 (Ejegg) a:Ejegg [20:09:04] § Fundraising Sprint Devo, Fundraising Dash, Fundraising Sprint Flaming Lips: Finish refactoring of each already existing widget - https://phabricator.wikimedia.org/T89298#1122887 (Ejegg) a:pizzzacat>Ejegg [20:12:11] blarg! I did actually get here (almost) in time, but my network config had become wonky following tethering... [20:13:25] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising Sprint G: Regression: interstitial page with PayPal even when the amount is good. - https://phabricator.wikimedia.org/T92705#1122902 (awight) I'm pretty sure this was caused by a refactor I did of the DonationInterface forms layer, deployed... [20:15:54] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising Sprint G: Regression: interstitial page with PayPal even when the amount is good. - https://phabricator.wikimedia.org/T92705#1122906 (atgo) It's probably coming from the DI deploy last week. We'll look into it ASAP [20:17:29] Wikimedia-Fundraising-CiviCRM, § Fundraising Sprint Abba, § Fundraising Sprint Beastie Boys, § Fundraising Sprint the Cure, and 6 others: Run CiviCRM testing scripts during CI - https://phabricator.wikimedia.org/T89896#1122914 (awight) @hashar: Thanks for all your help on this! I wanted to menti... [20:33:08] hey ejegg - would you say this is done? https://phabricator.wikimedia.org/T86345 [20:33:16] i know a reminder email actually went out last week [20:39:38] omg, calendar explosion. [20:39:54] ejegg: Can we reschedule our weekly check-in? I'm apparently double-booked every week. [20:40:45] I am the confused. [21:06:34] (PS1) Ejegg: Add execute_timeout to limit query lifespan [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 [21:08:00] Wikimedia-Fundraising, Analytics, Fundraising Tech Backlog: Strategy banner impressions - https://phabricator.wikimedia.org/T90635#1123141 (awight) @Jalexander: Was this the information you needed, and is it usable? Do you need the numbers for any other date ranges? [21:11:11] K4-713: sure, no problem changing it! [21:15:59] (CR) Awight: "Looking good!" (2 comments) [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 (owner: Ejegg) [21:19:20] Wikimedia-Fundraising, Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips: Make Civi Reminders work in Staging - https://phabricator.wikimedia.org/T86345#1123243 (Ejegg) I think we can close this. Staging still isn't running anything... [21:30:09] Wikimedia-Fundraising, Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips: Make Civi Reminders work in Staging - https://phabricator.wikimedia.org/T86345#1123322 (RLewis) @atgo and @ejegg sounds good. I wasn't sure if you had to figure... [21:31:45] (PS2) Ejegg: Add execute_timeout to limit query lifespan [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 [21:33:00] (CR) Ejegg: Add execute_timeout to limit query lifespan (2 comments) [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 (owner: Ejegg) [21:41:25] (PS3) Ejegg: Add execute_timeout to limit query lifespan [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 [21:43:46] (CR) Awight: Add execute_timeout to limit query lifespan (1 comment) [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 (owner: Ejegg) [21:58:03] awight: hah. close_all wouldn't have helped us even if we did call it on shutdown. it only handles connections obtained via get_db, and sp export uses the Connection constructor [21:58:25] [21:59:41] btw, I tried an explain on query #23, it does look a bit funny, but I'm not good enuf at reading query plans to really know w/o having real data in there. [21:59:44] awight: are you suggesting I amend the standard execute call to add a timeout param rather than creating a new function? [21:59:51] ejegg: That was my thought. [22:00:02] or err, maybe not even bothering with the param. [22:00:02] OK, sounds good [22:00:11] but I suppose an override is smart. [22:00:29] yeah, i want to use it to get the process id initially [22:01:14] wait, you lost me. I just meant, an execute(timeout= param is probably a nice, forwards-thingking idea. [22:01:22] What override u talking about? [22:01:40] maybe coerce SP export to use the tools/db api? [22:01:55] i want to call execute to get the connection id in __init__ [22:02:06] cool. [22:02:31] then have execute not set the death clock when called with timeout=0 [22:02:46] nice [22:04:33] Wikimedia-Fundraising-CiviCRM: Turn Reminders on in production - https://phabricator.wikimedia.org/T92012#1123586 (atgo) [22:04:35] Wikimedia-Fundraising, Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips: Make Civi Reminders work in Staging - https://phabricator.wikimedia.org/T86345#1123584 (atgo) Open>Resolved a:atgo [22:09:29] ejegg: oops, I just reread database.db, please ignore my rambling about moving to the get_db api :) [22:09:37] ok [22:12:16] Now I see what you were saying, I guess db.Connection.__init__ can account for itself in db_conn, if you still want to keep the close_all feature [22:14:33] (PS4) Ejegg: Add timeout param to limit query lifespan [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197205 [22:18:49] Wikimedia-Fundraising-CiviCRM, Fundraising Sprint G: Turn Reminders on in production - https://phabricator.wikimedia.org/T92012#1123604 (atgo) [22:24:19] awight: unless we're sigkilled, i think the Dbi.connection should close itself on deallocation. Only need to add ourself to the global dict if we require commit (since that's all Connection.close does) [22:27:23] I think any read/write query does require explicit commit, cos that's how the py mysql module likes to play. [22:30:12] heh, so that whole close thing is useless [22:31:16] Useless cos of the Jenkins bug, or you mean generally? [22:32:20] I'm pretty sure the commit is necessary, under normal circumstances. [22:33:24] oh, derp,misread yr last message as 'does explicit commit' [22:33:51] ejegg: hehe [22:34:12] I have multiple burns from that behavior... [22:34:28] Surprise! nothing happened. [23:04:03] awight: I don't know if I ever said so explicitly before, but your emails have a high incidence of being amazing. [23:04:31] aww [23:05:06] Yeah the main reason I'm not actually writing him yet is, I need to ferment my questions or something, to take off the bitter edge [23:05:13] Seriously. [23:05:33] I was going to say something about "grumble grumble charging by the request grumble". [23:05:34] WHY THE--thanks for your contribution to this mystery, but WHAT THE [23:08:33] K4-713: oh, you distracted me... Can you bless or curse https://phabricator.wikimedia.org/T91458 ? [23:08:43] before I bother w/ creating new cards... [23:09:10] heh [23:09:17] * K4-713 gets out the chicken bones [23:09:32] I still don't understand what the difference is, that would make it okay to keep on pay1004 [23:10:09] Cos what I'm suggesting here is just a slightly more expensive version of, "wrap stomp in a write-only interface" [23:10:24] Dang. [23:10:50] So, we need to remove read access for the whole queue box, from all the payments boxes. [23:10:59] oh hrm right. I get this small angle now, that we don't want to *actually* read [23:11:04] yep. [23:11:13] OK nvm, that answers that. [23:11:19] So, unless we move the slayer to something that isn't a payments box, it has to go. [23:11:25] * awight waits for the tea leaves to settle [23:11:34] but wait, memcache would be ok? [23:11:37] yep [23:11:49] Wanna know why? :) [23:11:57] alright. Then I guess this plan is solid as cooked mud. [23:12:00] yes [23:12:01] please [23:12:05] It doesn't drag any new machines under the umbrella. [23:12:21] ok thx that makes a lot of sense [23:12:27] * K4-713 looks relieved [23:12:33] I always wonder if it's me. [23:12:46] although... I think you did make the point to Tom that one-way permissions !== one-way communication. [23:12:55] yep [23:12:58] ok. [23:13:00] weird [23:13:20] I guess we have to assume that our software does what we tell it to, at some point. [23:14:18] I want to argue with that. [23:14:39] Only I'm not going to. [23:14:57] I... think I had way, way too much coffee today. [23:15:22] integer overflow number of cups [23:17:27] anyone know the ADP login standard? is it my email..? [23:17:38] Oh, blarf. I just did this. [23:17:42] ...no. [23:18:17] Also, capitalization counts in the login. [23:21:11] Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog: Create a general Civi import function to reduce time for hand keying donations in Civi - https://phabricator.wikimedia.org/T88836#1123756 (RLewis) @atgo and @awight let me know if I need to create a separate task for this.... [23:21:33] back in an hour or two... [23:22:43] and i am off the hook for jury duty for another day [23:22:49] wooooooo [23:25:32] K4-713: do you agree with keeping the slayer on the payments cluster, btw? I like that it keeps all almost-donor info contained there. [23:25:45] Also, I think we should stop treating 1004 as a snowflake. [23:26:04] awight: On the first point: That was my first impulse. [23:26:21] k [23:26:23] Particularly because we don't know if these people actually turned in to donors or not, which is the whole point of the orphan thingy anyway. [23:26:29] yep [23:27:04] About 1004 not being a snowflake.... I'm not sure what you mean there. Are you thinking about distributing the job? [23:27:14] Because I don't know if that would... get us anywhere we want to go. [23:27:27] Or, do you just mean not more of one? [23:27:30] heh [23:27:36] nah, the job can stay on one machine. But what I was thinking was, there's no reason to waste the front-end capacity. [23:27:50] It still will need special, ah... antifraud rules anyway. To tolerate batch mode things. [23:27:57] oh. hrm [23:28:07] * awight coughs into sleeve [23:29:08] But hey: If it has special rules, why not make it more special so the office stops being blacklisted every time everybody tries to test a new thing in the same 3-minute window? [23:29:15] >_> [23:29:25] ....I realize this is the opposite of your first point. [23:30:02] Well, yeah the other thing that would make me happy is to have an actual staging box--but I'd rather do that the right way, with dummy data and public access... [23:30:18] We're still going to have the near-prod problem. [23:30:26] But, yes. That would help a ton, too. [23:31:49] I can finish this "forever home" business at least, but I think I'll make the last task, to figure out how to write batch-mode exceptions in a shared config file. [23:32:48] awight: Hmm... let me think about that. [23:33:05] I don't like the idea that people could then potentially fake batch mode on public prod boxes. [23:37:18] take yr time. I'll make this an even more general spike, "stop wasting the 1004 box" [23:38:56] atgo: can you make me one more private task, to implement T91458 ? [23:39:28] I wonder what it'll look like if I make subtasks of that? [23:40:26] that should work [23:40:38] we could just get you policy rights, too :) [23:40:50] no wait [23:40:52] that will not work [23:40:54] let me make one for you [23:40:58] It's silly... I think the individual tasks should all be public, anyway. [23:41:39] Feel free to take a quick look, https://phabricator.wikimedia.org/T91458 [23:42:42] raaaad! [23:43:15] :) I mean, to help decide whether the subtasks can be public. [23:43:40] i'm not totally sure.. that sounds like a jeff_green question [23:43:52] and/or a k4 question [23:44:35] OK I'll write tasks for everything that's clearly insensitive, and wait on the others. [23:45:31] cool [23:45:35] i made you one private one [23:45:37] i can make more [23:45:44] and i think we should get you policy [23:46:40] * K4-713 squints at insensitive tasks [23:48:58] awight: Were you thinking all the points would be their own subtasks? [23:49:13] K4-713: yep, pretty much [23:49:19] Or, am I missing something totally obvious... oh. Okay. [23:50:04] It all seems insensitive, other than the explanation for why we're doing this work :p [23:50:10] heh [23:51:09] Oh, but wait. [23:51:33] Actually... no. [23:51:35] But. [23:51:45] * K4-713 argues with self in public [23:52:24] :) [23:52:38] I was thinking: Do we really want to remove DI's ability to read? [23:52:54] ...because, there are other checkouts that are not in scope for PCI, and they do things too. [23:53:57] Then I think I started inventing problems. [23:54:24] Good question. I think the Drupal RGC job doesn't write to a queue. [23:54:34] I think you're right. [23:54:55] Will we ever want to? [23:55:48] We might... but we can do that by adjusting the config a la https://phabricator.wikimedia.org/T92919 [23:56:42] What am I not thinking of. [23:57:15] ...IPN/style notification messages are not DI, and neither are any of the nightly audit processors... [23:57:19] Yeah, okay. [23:57:32] + other Drupal stuff, which reads and writes... [23:57:36] mhm