[00:09:29] Fundraising-Backlog, Recurring-Donations: Update recurring QC for tokenized subscriptions - https://phabricator.wikimedia.org/T227048 (Ejegg) [00:34:06] Fundraising-Backlog, FR-Ingenico, Recurring-Donations: Update SmashPig recurring processor to handle first payments - https://phabricator.wikimedia.org/T227051 (Ejegg) [00:54:14] (PS2) Ejegg: WIP RecurringConversion API [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/519729 (https://phabricator.wikimedia.org/T216560) [00:54:16] (PS1) Ejegg: Add RecurringConversion interface [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/520149 (https://phabricator.wikimedia.org/T216560) [00:54:18] (PS1) Ejegg: WIP Ingenico implements RecurringConversion [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/520150 (https://phabricator.wikimedia.org/T216560) [00:57:31] (CR) jerkins-bot: [V: -1] WIP RecurringConversion API [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/519729 (https://phabricator.wikimedia.org/T216560) (owner: Ejegg) [00:57:42] (CR) jerkins-bot: [V: -1] WIP Ingenico implements RecurringConversion [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/520150 (https://phabricator.wikimedia.org/T216560) (owner: Ejegg) [04:19:42] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Security-Team-Reviews: CentralNotice: Security review of banner preview feature - https://phabricator.wikimedia.org/T226963 (AndyRussG) >>! In T226963#5298080, @sbassett wrote: > Just to confirm, these patch sets: > Rename and move update prev... [13:27:46] morning ejegg! Question on the unit tests, everything is working except for the control parameter in testNewInvoiceRequest, what is that exactly? [13:33:17] (Abandoned) Hashar: Jenkins job validation (DO NOT SUBMIT) [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/517986 (owner: Hashar) [13:39:30] (CR) Hashar: [C: +1] "I have mentioned it to scrum of scrum" [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/517393 (https://phabricator.wikimedia.org/T225796) (owner: Hashar) [13:39:33] (CR) Hashar: [C: +1] "I have mentioned it to scrum of scrum" [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/517397 (https://phabricator.wikimedia.org/T225496) (owner: Hashar) [13:41:54] hi cstone [13:42:03] so, the control parameter is a signature [13:42:24] to prove we're the ones making the request [13:42:48] it's a hash of some of the values plus our secret key [13:43:10] so it'll change with every change in the values [13:43:17] ahh okay that makes sense [13:43:28] for the tests, you can just change the expected value to the actual value [13:43:37] since we haven't messed with the signature code [13:43:54] ok cool [13:50:17] PROBLEM - check_minfraud_primary on payments2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:50:18] PROBLEM - check_minfraud_secondary on payments2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:52:17] PROBLEM - check_minfraud_primary on payments2002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:52:18] PROBLEM - check_minfraud_secondary on payments2002 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:52:18] PROBLEM - check_minfraud_primary on payments1003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:52:19] PROBLEM - check_minfraud_secondary on payments1003 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:53:17] PROBLEM - check_minfraud_primary on payments1001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:53:18] PROBLEM - check_minfraud_primary on payments1002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:53:18] PROBLEM - check_minfraud_secondary on payments1001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:53:18] PROBLEM - check_minfraud_secondary on payments1002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:54:17] PROBLEM - check_minfraud_primary on payments2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:54:18] PROBLEM - check_minfraud_primary on payments2003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:54:18] PROBLEM - check_minfraud_secondary on payments2003 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:54:18] PROBLEM - check_minfraud_secondary on payments2001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:54:18] PROBLEM - check_minfraud_primary on payments1004 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:54:19] PROBLEM - check_minfraud_secondary on payments1004 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:54:43] oh jeez, what's up with that? [13:55:01] icinga issue, or actual minfraud problem? [13:56:37] PROBLEM - check_minfraud_primary on payments2002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:57:07] PROBLEM - check_minfraud_secondary on payments1003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:58:27] PROBLEM - check_minfraud_primary on payments2003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:58:47] PROBLEM - check_minfraud_primary on payments2001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:59:11] PROBLEM - check_minfraud_primary on payments1001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:59:17] PROBLEM - check_minfraud_secondary on payments1001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:59:17] PROBLEM - check_minfraud_primary on payments1002 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:59:18] PROBLEM - check_minfraud_secondary on payments1002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [13:59:18] PROBLEM - check_minfraud_primary on payments1004 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [13:59:19] PROBLEM - check_minfraud_secondary on payments1004 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:01:11] PROBLEM - check_minfraud_primary on payments2002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:01:11] PROBLEM - check_minfraud_secondary on payments2002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:02:57] PROBLEM - check_minfraud_primary on payments1003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 409 Conflict [14:02:59] PROBLEM - check_minfraud_secondary on payments1003 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [14:03:17] PROBLEM - check_minfraud_primary on payments1001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:03:17] PROBLEM - check_minfraud_secondary on payments1001 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:03:18] PROBLEM - check_minfraud_primary on payments1004 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:03:19] PROBLEM - check_minfraud_secondary on payments1004 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:04:13] PROBLEM - check_minfraud_primary on payments2003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:04:15] PROBLEM - check_minfraud_secondary on payments2003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:04:48] PROBLEM - check_minfraud_secondary on payments2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [14:05:17] PROBLEM - check_minfraud_primary on payments1002 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [14:05:17] PROBLEM - check_minfraud_secondary on payments1002 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [14:06:13] PROBLEM - check_minfraud_primary on payments2002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:06:13] PROBLEM - check_minfraud_secondary on payments2002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:07:17] PROBLEM - check_minfraud_primary on payments1003 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [14:07:17] PROBLEM - check_minfraud_secondary on payments1003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:08:17] PROBLEM - check_minfraud_primary on payments2003 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:08:17] RECOVERY - check_minfraud_secondary on payments2003 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 2.733 second response time [14:08:27] PROBLEM - check_minfraud_primary on payments1002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:08:27] PROBLEM - check_minfraud_secondary on payments1002 is CRITICAL: HTTP CRITICAL - Invalid HTTP response received from host on port 443: HTTP/1.1 502 Bad Gateway [14:08:53] RECOVERY - check_minfraud_secondary on payments1004 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 0.056 second response time [14:09:03] RECOVERY - check_minfraud_primary on payments2001 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 5.681 second response time [14:09:13] PROBLEM - check_minfraud_primary on payments1001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [14:09:15] RECOVERY - check_minfraud_secondary on payments1001 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 0.052 second response time [14:10:59] (PS3) Cstone: Add India specfic fields for dlocal, street_address, city, PAN for fiscal_number, and x_version. Update unit tests to handle street_address and city. Create new donor test data for India. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/519510 (https://phabricator.wikimedia.org/T224514) [14:11:13] RECOVERY - check_minfraud_primary on payments2002 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 0.167 second response time [14:11:13] RECOVERY - check_minfraud_secondary on payments2002 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 0.169 second response time [14:11:17] RECOVERY - check_minfraud_primary on payments1003 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 0.051 second response time [14:11:17] RECOVERY - check_minfraud_secondary on payments1003 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 0.030 second response time [14:13:13] RECOVERY - check_minfraud_primary on payments1001 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 0.041 second response time [14:13:15] RECOVERY - check_minfraud_primary on payments2003 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 0.160 second response time [14:13:15] RECOVERY - check_minfraud_primary on payments1002 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 0.031 second response time [14:13:17] RECOVERY - check_minfraud_secondary on payments1002 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 0.049 second response time [14:13:17] RECOVERY - check_minfraud_secondary on payments2001 is OK: HTTP OK: Status line output matched 200,301,302 - 662 bytes in 0.159 second response time [14:13:17] RECOVERY - check_minfraud_primary on payments1004 is OK: HTTP OK: Status line output matched 200,301,302 - 787 bytes in 0.035 second response time [14:17:49] (CR) jerkins-bot: [V: -1] Add India specfic fields for dlocal, street_address, city, PAN for fiscal_number, and x_version. Update unit tests to handle street_address and city. Create new donor test data for India. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/519510 (https://phabricator.wikimedia.org/T224514) (owner: Cstone) [14:20:59] Fundraising-Backlog: Communication: Employer Name field is returning blank values - https://phabricator.wikimedia.org/T227091 (NNichols) [15:36:41] cstone: let's add a different test for India with the city and street [15:37:02] yeah I was going to ask about that [15:37:53] I created one and a new IN donor data profile, should I just remove the city and street from the BR one then? [15:47:40] Fundraising Sprint Men In Slack, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice: Review incoming patches 2019-06 and 2019-07 - https://phabricator.wikimedia.org/T226655 (DStrine) [15:47:46] Fundraising-Backlog: Communication: Employer Name field is returning blank values - https://phabricator.wikimedia.org/T227091 (DStrine) a:DStrine→None [17:10:29] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Security-Team-Review-Active: CentralNotice: Security review of banner preview feature - https://phabricator.wikimedia.org/T226963 (sbassett) a:Reedy [17:36:49] fr-tech: on these utm_* tracking fields, does anyone know if they always come together, or is it possible we'd have one without the others? [17:54:18] and leave the /nick ejegg [17:54:23] derp [17:54:43] XenoRyet: Let's allow for the possibility of having some and not others [17:55:13] cstone: sure, let's remove the city and street from the BR one [17:55:33] Yea, seems safer that way if we don't know for a fact that they always all come together. [17:56:20] cstone: so just unset($init['city']) and unset($init['street_address']) [18:44:47] (CR) Jforrester: [C: +2] Add missing centralnotice-multiple-{countries,languages} keys [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/519750 (https://phabricator.wikimedia.org/T226879) (owner: MarcoAurelio) [19:07:14] (Merged) jenkins-bot: Add missing centralnotice-multiple-{countries,languages} keys [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/519750 (https://phabricator.wikimedia.org/T226879) (owner: MarcoAurelio) [19:15:13] ejegg hmm with city and address in the AstroPaySignature is there a switch somewhere I'm not seeing to be able to change the parameters depending on what we need? All the unit tests for BR are looking for city/address now [19:16:35] (CR) jenkins-bot: Add missing centralnotice-multiple-{countries,languages} keys [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/519750 (https://phabricator.wikimedia.org/T226879) (owner: MarcoAurelio) [19:17:26] cstone oh, so if you unset those two params in init, the AstroPaySignature throws an undefined parameter error? [19:18:21] unset them from $init at the start of the test, that is? [19:18:47] In that case, the signature should check if they're defined and use '' when they're not [19:19:42] If we're totally off php5.6 we can use the coalesce operator for that [19:20:49] whoa, php7 has a 'Spaceship operator' too! [19:20:53] yeah its still throwing the error [19:20:55] https://php.net/manual/en/migration70.new-features.php [19:21:05] hah yeah i was just reading about that a couple weeks ago, the spaceship [19:21:09] cstone what error? [19:21:35] er sorry undefined index city after unsetting them at the top [19:22:28] in the signature class? [19:22:52] yeah in the signature [19:23:24] and you're doing something like $city = isset( $stagedData['city'] ) ? $stagedData['city'] : '' [19:23:34] then using $city in the concatenated bit? [19:24:28] hah sorry caused confusion, have not done checking if they are set yet [19:24:33] but that sounds like a good solution [19:26:59] ok, cool! [20:32:55] eclipse is totally covered by clouds :( [20:33:13] (PS1) XenoRyet: Add traking fields to opt-in consumer [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/520315 [20:39:17] (CR) jerkins-bot: [V: -1] Add traking fields to opt-in consumer [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/520315 (owner: XenoRyet) [22:11:09] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: fredge query yielding '502 bad gateway' error - https://phabricator.wikimedia.org/T224742 (MBeat33) So of course the bugs hide when @Eileenmcnaughton is watching ;) Some takeaways from our hangout: * adjustin... [22:18:09] (PS1) Eileen: Change default displayed columns [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/520333 (https://phabricator.wikimedia.org/T224742) [22:21:40] (PS1) Eileen: Order fredge report by payment attempt date desc by default [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/520334 (https://phabricator.wikimedia.org/T224742) [22:22:33] (CR) Ejegg: [C: +2] Change default displayed columns [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/520333 (https://phabricator.wikimedia.org/T224742) (owner: Eileen) [22:22:50] (CR) Ejegg: [C: +2] Order fredge report by payment attempt date desc by default [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/520334 (https://phabricator.wikimedia.org/T224742) (owner: Eileen) [22:28:28] (PS1) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/520335 [22:29:58] (CR) Eileen: [C: +2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/520335 (owner: Eileen) [22:34:17] (Merged) jenkins-bot: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/520335 (owner: Eileen) [22:35:05] !log civicrm revision changed from 96985fcc4b to 8a4451f390, config revision is af9e657134 [22:35:10] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [22:36:00] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Civi: fredge query yielding '502 bad gateway' error - https://phabricator.wikimedia.org/T224742 (Eileenmcnaughton) @MBeat33 we looked at those changes in tech talk & they are already deployed! H... [22:37:01] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Civi: fredge query yielding '502 bad gateway' error - https://phabricator.wikimedia.org/T224742 (Eileenmcnaughton) a:Eileenmcnaughton [22:37:53] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Civi: fredge query yielding '502 bad gateway' error - https://phabricator.wikimedia.org/T224742 (MBeat33) Careful, I could get used to that! Thank you. [22:38:54] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Civi: fredge query yielding '502 bad gateway' error - https://phabricator.wikimedia.org/T224742 (Eileenmcnaughton) lol - I was thinking 'I go from not knowing I want a wine to having procured a... [22:45:15] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Turn on Redis, Functional locks - https://phabricator.wikimedia.org/T222002 (Eileenmcnaughton) I've made the following change on frpm - ready to deploy..... ` +++ b/civicrm/sites/default/civicrm.settings.php +// m... [22:47:29] Fundraising Sprint Men In Slack, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Turn on Redis, Functional locks - https://phabricator.wikimedia.org/T222002 (Eileenmcnaughton) @ejegg wanna check the change on frpm before I deploy - am doing the locks only first - that seems very safe - we can ta... [23:09:00] ejegg: I put a patch in civicrm.settings to go out for - https://phabricator.wikimedia.org/T222002 - I figured to make the changes separately [23:14:11] if you can check it I will push out [23:22:06] eileen: looking... [23:24:33] checking our version of mariadb [23:26:18] eileen: looks like we have mariadb 10.1 [23:26:31] which has feature parity with mysql 5.6 [23:26:38] which should be more than 10.0.2... [23:27:04] ah, the locks were added to mariadb in 10.0.2? [23:27:20] https://mariadb.com/kb/en/library/get_lock/ [23:28:12] ok, cool [23:29:24] the settings patch looks good, then! [23:30:22] so this doesn't do anything on its own, but lets us add locks to the QCs to help prevent e.g. double charging recurring donations? [23:31:54] ejegg: yep - well civi core DOES use the locks a little [23:32:09] so it should make them work better but I doubt we will notice... [23:32:35] in theory we could get less deadlocks.... [23:38:32] ejegg: ok pushing it out now - we should plan a time to do the redis one though - no outage needed but perhaps we'd stop & restart queues [23:39:04] yep, I concur with the queue stoppage [23:40:42] do you have a thought as to when is best to make the change? Early in the day maybe [23:41:25] eileen: looks like there's very little traffic from anywhere just now. [23:41:35] oh hey, actually, dash would tell us the lull [23:41:36] should we do it now? [23:41:50] sure! [23:42:52] !log civicrm revision is 8a4451f390, config revision is c02a038331 (mysql locks enabled) [23:42:57] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [23:44:51] ejegg: so that is all the change I think we need to make ^^ [23:44:59] actually not ^^ but on frpm [23:46:24] hehe, ok, looking [23:46:59] oh right, we had it, just commented out [23:47:32] yeah - I assume we had the right password... [23:48:47] yep, just checked with redis-cli [23:49:14] want to do the honors on the queue jobs, or should I? [23:49:40] I should be able to just run process-control/disable shouldn't I [23:49:55] but getting grumpiness [23:49:55] sed: couldn't edit /bin: not a regular file [23:51:18] ah got it [23:51:58] ejegg: ok I pushed but the order is wrong isn't it? [23:52:14] I mean I should have disabled, then pushed, then enabled redis [23:52:58] ok - I pushed a revert [23:53:18] oh, you pushed the redis setting first? [23:54:07] heh, I think the git patch order in settings doesn't matter as long as you do the rsync for process-control before the rsync for civi [23:54:43] ejegg: yeeh but we need to stop jobs some minutes before the change? [23:54:46] AndyRussG: the timestamp format changed! [23:54:57] there's a 'Z' at the end now, and the regex doesn't pick it up [23:55:35] As an aside is this the page that is apparently our docs home page - https://www.mediawiki.org/wiki/Fundraising_tech [23:56:15] yep, mepps recently reorganized it a bit [23:56:25] I think she moved some stuff to subpages [23:56:38] I will bookmark it! [23:57:03] Ok - I've pushed to stop jobs - how long do we wait having done that? [23:58:02] the jobs graph on the internal grafana dash should show us somethign [23:58:07] ejegg nice find, thanks!! [23:59:15] run-job -r doesn't show anything although I lack some trust [23:59:59] ejegg I can make a ticket in a bit