[00:04:36] dstrine: for standup [00:29:39] (PS1) Ejegg: Insert paypal recur records on first payments [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/631558 (https://phabricator.wikimedia.org/T248420) [11:39:40] tzag fr-tech! [12:07:35] PROBLEM - check_redis on frqueue1001 is CRITICAL: CRITICAL: recurring is 4084 4000 - REDIS 5.0.3 on 127.0.0.1:6379 has 1 databases (db0) with 11 keys, up 38 days 21 hours - memory use is 4.63M (peak 47.67M, 0.13% of max, fragmentation 2.18%), connected_slaves is 2, donations is 97, jobs is 0, jobs-adyen is 86, jobs-paypal is 2, payments-antifraud is 91, payments-init is 20, pending is 0, refund is 1, unsubscribe is 3 [12:12:35] PROBLEM - check_redis on frqueue1001 is CRITICAL: CRITICAL: recurring is 4381 4000 - REDIS 5.0.3 on 127.0.0.1:6379 has 1 databases (db0) with 10 keys, up 38 days 21 hours - memory use is 4.78M (peak 47.67M, 0.13% of max, fragmentation 2.19%), connected_slaves is 2, donations is 196, jobs is 0, jobs-adyen is 33, jobs-paypal is 1, payments-antifraud is 85, payments-init is 31, pending is 2, refund is 0, unsubscribe is 6 [12:16:09] ACKNOWLEDGEMENT - check_redis on frqueue1001 is CRITICAL: CRITICAL: recurring is 4381 4000 - REDIS 5.0.3 on 127.0.0.1:6379 has 1 databases (db0) with 10 keys, up 38 days 21 hours - memory use is 4.78M (peak 47.67M, 0.13% of max, fragmentation 2.19%), connected_slaves is 2, donations is 196, jobs is 0, jobs-adyen is 33, jobs-paypal is 1, payments-antifraud is 85, payments-init is 31, pending is 2, refund is 0, unsubscribe is 6 Dw [12:16:09] onations are successful. Should raise the limit. [13:03:05] I guess that's a lot of recurring messages [13:53:00] Wikimedia-Fundraising-Banners, Accessibility: Fundraising banners should respect prefers-reduced-motion setting - https://phabricator.wikimedia.org/T264442 (Pcoombe) [13:53:13] Wikimedia-Fundraising-Banners, Accessibility: Fundraising banners should respect prefers-reduced-motion setting - https://phabricator.wikimedia.org/T264442 (Pcoombe) p:Triage→Low [14:22:46] jgleeson|biab fr-tech hey :) [14:28:12] so last night was a terrible time to decide to just take one last peek at Twitter [14:29:37] ejegg: I tell ya, it's as if the the news cycle were onto my weird working hours [14:36:06] ejegg: pcoombe: just glanced at the banner bug thing from yesterday, seems like it's solved, at least for now [14:37:00] Also, the kvStore component of CentralNotice does have facilities for using localstorage with fallback, key expiry and organizing keys nicely [14:37:34] All the API needed should be accessible... maybe we should talk about what the goal of the banner code was and how to make it use kvStore? [14:42:32] RECOVERY - check_redis on frqueue1001 is OK: OK: REDIS 5.0.3 on 127.0.0.1:6379 has 1 databases (db0) with 10 keys, up 39 days 21 minutes - memory use is 3.58M (peak 47.67M, 0.11% of max, fragmentation 2.52%), connected_slaves is 2, donations is 180, jobs is 0, jobs-adyen is 27, jobs-paypal is 0, payments-antifraud is 141, payments-init is 40, pending is 1, recurring is 2145, refund is 0, unsubscribe is 20 [15:14:17] hey AndyRussG fr-tech :) [15:14:33] re:twitter, it was a bad time to turn the news on at 6am here also [15:14:52] jgleeson: :) heh I can imagine [15:15:58] hi jgleeson [15:16:40] msnbc was showing multiple images of trump with no mask during the reports and then fox news was showing a single image constantly of him wearing a mask [15:17:11] Wikimedia-Fundraising-Banners, Wikimedia-production-error: TypeError: this.banner is undefined on German Wikipedia banner - https://phabricator.wikimedia.org/T264452 (Jdlrobson) [15:17:19] hey ejegg [15:18:46] jgleeson: it's two separate worlds [15:19:32] yeah you'd think they were covering different people it's so polarised [15:26:39] I've seen that at different times here in Mexico too [15:27:22] I think usually not a very happy sign [15:34:37] so Jeff_Green we can add a diagnostic php file to payments-wiki-staging that just dumps the headers and some values that PHP sees [15:34:52] and I can just hit that via my manipulated hosts file [15:35:01] without ever exposing it to the public [15:35:18] ejegg: sounds good to me [15:38:31] fr-tech I added in a couple of metrics we could access and renamed a few things on the import stats graph, does this look ok? https://frmon.frdev.wikimedia.org/d/Pq1YNMviz/fundraising-overview?viewPanel=33&org=&orgId=1&refresh=1m&from=now-6h&to=now [15:42:54] it looks like recurring donations can take up to double the time on a non-recurring donation [15:43:13] not always but during presumably busier periods [15:43:23] I don't think they do double the work? [15:43:56] maybe as it's less frequent it's due to them not benefitting from caches [15:46:14] well, there are definitely more tables in play on the recurring ones [15:58:10] (PS1) Ejegg: NOT FOR PRODUCTION: Debug headers [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631803 [15:58:58] (CR) Ejegg: [V: +2 C: +2] NOT FOR PRODUCTION: Debug headers [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631803 (owner: Ejegg) [16:02:33] Wikimedia-Fundraising-Banners: France banner with link to WYDG - https://phabricator.wikimedia.org/T264324 (jbolorinos-ctr) Open→Resolved All issues found have been reported and addressed. These banners are now READY TO TEST! @HNordeen [16:02:50] well dang Jeff_Green: [X-Forwarded-For] => 186.81.100.86 [16:02:58] but $_SERVER["REMOTE_ADDR"]: 127.0.0.1 [16:03:05] and WebRequest->getIP(): 127.0.0.1 [16:03:16] huh [16:03:44] I wonder what XFF is on a stretch host? [16:04:16] heh, i definitely don't want to deploy the same debug patch on a server that's seeing traffic [16:04:26] it's just dumping all the headers at the top of the web page [16:04:42] right [16:06:15] we'd have to test in vagrant/vb [16:06:32] Jeff_Green: oh, or payments1004, right? [16:07:05] oh, true [16:07:21] if you can just copy/paste a few lines in the index.php we could check there [16:07:40] up for a little root-access live hacking? [16:07:45] ha [16:08:01] thinking [16:08:06] would be basically the same as the change for 1.35: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631803/1/index.php [16:08:28] since it's not exposed via lvs we can only tunnel to it, so then we're getting its ip [16:09:18] hmm, but we can still hit nginx across the tunnel, right? [16:10:31] thinking [16:11:01] testing [16:17:03] yeah, nginx sees the end of the tunnel as the source IP in that case, so payments1004's ip [16:17:18] Fundraising-Backlog, fundraising sprint Theme songs for programming languages: Donations queue consumer failed - Invalid character input in postal code - https://phabricator.wikimedia.org/T262232 (jgleeson) a:jgleeson [16:19:00] oh drat Jeff_Green so that doesn't help [16:19:32] Jeff_Green: if it's not 127.0.0.1 it may still let you know if it's doing something. [16:19:34] we can end the tunnel at frbast-eqiad.wikimedia.org and at least get a different private IP [16:19:42] dwisehaupt: true [16:20:12] worth a shot at least. [16:20:22] ok ejegg, what's the live hack? [16:20:46] Jeff_Green: in index.php, add these lines https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631803/1/index.php [16:21:01] should work in the same place for mw 1.31 as it does for mw 1.35 [16:21:44] ok done [16:22:26] XFF looks the same to me, I'm getting the IP for the bastion which is where I ended my tunnel [16:23:58] Fundraising-Backlog, fundraising sprint Theme songs for programming languages, fr-donorservices: Add translations for failed recurring email for 7 additional languages - https://phabricator.wikimedia.org/T260703 (Cstone) a:Cstone [16:24:46] Jeff_Green: at the bottom what do you see for WebRequest->getIP() ? [16:25:05] sec, i already closed it [16:25:47] maybe main-cluster-ops has some insight into what else we would need to update? [16:26:37] it looks like there's some consideration of 'trusted proxies' in that getIP function [16:26:38] same IP for getIP [16:26:58] right was wondering about that [16:27:22] ejegg: is this hack still in place on payments2xxx? [16:27:29] yes Jeff_Green [16:27:35] ok lemme see what I get there [16:28:14] Wikimedia-Fundraising-Banners: QA: frFR dsk lg - move smallprint back below message only - https://phabricator.wikimedia.org/T264331 (jbolorinos-ctr) Screenshote Test Results - Desktop: - Control: https://app.crossbrowsertesting.com/public/i15b74a2dc92badb/screenshots/z09bbe80e7bb402b4d93 - Test: https://app... [16:28:23] there i get 127.0.0.1 for WebRequest->getIP() [16:28:49] yep, that's what I see too [16:28:56] so it IS a core change [16:29:05] it seems like it must be, or a php change [16:29:08] who on main cluster ops might know about it? [16:30:26] that's a good question, I'm not even sure it would be an SRE thing but rather a code deploy thing [16:30:39] have you spelunked phab yet? [16:32:35] Wikimedia-Fundraising-Banners: QA: frFR dsk sm - banner above heading - https://phabricator.wikimedia.org/T264330 (jbolorinos-ctr) Screenshot Test Results - Desktop: - Control: https://app.crossbrowsertesting.com/public/i15b74a2dc92badb/screenshots/z768cd64615818bf9d03 - Test: https://app.crossbrowsertesting... [16:34:04] ejegg: you around? [16:35:27] oops, be right there [16:38:51] Fundraising-Backlog, fundraising sprint Theme songs for programming languages, FR-Q2-FY2020-21-cleanup-list, Patch-For-Review: 3 Paypal recurring payments missing predecessor - https://phabricator.wikimedia.org/T248420 (DStrine) [16:40:28] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-Q2-FY2020-21-cleanup-list: Automatic TY for Stock Gifts - https://phabricator.wikimedia.org/T259173 (LeanneS) @DStrine Jessica and I spoke about the stock TY email. To give you an idea on timing, stock donations start to ramp up in November so I... [16:41:14] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-Q2-FY2020-21-cleanup-list: Automatic TY for Stock Gifts - https://phabricator.wikimedia.org/T259173 (DStrine) ok. We'll try to look at this next print [16:43:16] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-Q2-FY2020-21-cleanup-list: Automatic TY for Stock Gifts - https://phabricator.wikimedia.org/T259173 (LeanneS) Great! Thanks so much. [17:11:14] ok, back on this getIP investigation [17:18:31] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) [17:18:52] (PS1) Ejegg: Revert "NOT FOR PRODUCTION: Debug headers" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631830 [17:19:07] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) a:Dwisehaupt [17:19:53] Fundraising-Backlog, fundraising-tech-ops: Civi Credential for Melanie - https://phabricator.wikimedia.org/T264335 (Dwisehaupt) [17:20:14] Fundraising-Backlog, fundraising-tech-ops: Civi Credential for Melanie - https://phabricator.wikimedia.org/T264335 (Dwisehaupt) a:Dwisehaupt [17:21:00] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) [17:21:24] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) a:Dwisehaupt [17:23:20] (CR) jerkins-bot: [V: -1] Revert "NOT FOR PRODUCTION: Debug headers" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631830 (owner: Ejegg) [17:28:22] (CR) Ejegg: [V: +2 C: +2] Revert "NOT FOR PRODUCTION: Debug headers" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631830 (owner: Ejegg) [17:29:54] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) Approval received. ` From: Lisa Gruwell To: Leanne Schreibstein Cc: Leticia Navarro, Eileen McNaughton, Dallas Wisehaupt Subject: Re: Approval for t... [17:30:21] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) [17:36:19] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (EMartin) Dallas, approval is in the task. I will forward you the email from Lisa as well. [17:36:59] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) SSL client cert created and sent via email. Password sent via SMS. Civi account created (ryleighs) and welcome email sent. [17:37:27] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) [17:40:24] Fundraising-Backlog, fundraising-tech-ops: Civi Credential for Melanie - https://phabricator.wikimedia.org/T264335 (Dwisehaupt) Approval received. We can move forward with the rest of the steps on Monday when the contact info is completed and Melanie starts. ` From: Lisa Gruwell To: Leanne Schreibstein... [17:40:50] Fundraising-Backlog, fundraising-tech-ops: Civi Credential for Melanie - https://phabricator.wikimedia.org/T264335 (Dwisehaupt) [17:44:32] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) @EMartin Could you please add Leticia's contact information to the [[ https://collab.wikimedia.org/wiki/Fundraising#Contact_List | Fundraising Contact list ]]? Thanks. [17:44:49] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) [17:46:02] fr-tech when I try to vagrant provision I get the enable_drupal_modules setup command timing out [17:47:45] maybe that's why mepps has been unable to see the civi DBs? [17:56:40] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (EMartin) Leticia has been added, Dallas [17:57:57] asking about getIP over in #wikimedia-cpt (Core platform team) [17:58:04] but so far no response [17:58:23] code seems pretty simple [17:58:42] and hard to see how it wouldn't return the XFF header [17:59:00] fr-tech anyone want to look over the code in a video chat? [18:00:12] hmm, is getHeader changed? [18:01:11] Wikimedia-Fundraising-Banners: QA: frFR dsk lg - move smallprint back below message only - https://phabricator.wikimedia.org/T264331 (jbolorinos-ctr) Since there's apparently an issue with the screenshots service right now, I'll just manually upload a few verification screenshots. - Control: {F32371430} -... [18:02:00] oho, looks like headers are actually gotten differently [18:02:32] Could this have anything to do with it? [18:02:33] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/580870 [18:11:48] Wikimedia-Fundraising-Banners: Main banner and nag appearing at the same time - https://phabricator.wikimedia.org/T264461 (jbolorinos-ctr) [18:11:54] Wikimedia-Fundraising-Banners: Main banner and nag appearing at the same time - https://phabricator.wikimedia.org/T264461 (jbolorinos-ctr) a:jbolorinos-ctr→None [18:17:45] (PS1) Ejegg: NOT FOR PROD: More IP /header debug [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631839 [18:17:49] hmm, unlikely, the getHeader code uppercases its arg too [18:19:52] (CR) Ejegg: [V: +2 C: +2] NOT FOR PROD: More IP /header debug [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631839 (owner: Ejegg) [18:35:35] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) [18:39:01] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) SSL client certificate has been created and password has been sent via SMS. Civicrm account has been created (lnavarro) and initial welcome email sent. [18:56:25] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) [18:56:47] Fundraising-Backlog, fundraising-tech-ops: Leticia Navarro needs Civi access - https://phabricator.wikimedia.org/T264325 (Dwisehaupt) Open→Resolved Worked with Leticia and the certificate is installed and working. A password change loop was done on civicrm and access was verified. [19:21:38] Wikimedia-Fundraising-Banners: QA: frFR dsk sm - banner above heading - https://phabricator.wikimedia.org/T264330 (jbolorinos-ctr) Open→Resolved All bugs found have been reported and addressed. Closing as Resolved, these banners are now READY TO TEST! [19:24:37] Wikimedia-Fundraising-Banners: QA: frFR dsk lg - move smallprint back below message only - https://phabricator.wikimedia.org/T264331 (jbolorinos-ctr) Open→Resolved All bugs found have been reported and addressed. Closing task now as Resolved, these banners are READY TO TEST! [19:41:05] Fundraising Sprint Raw data never hurt anyone, Fundraising Sprint 🐍 is not a valid zipcode, Fundraising-Backlog, fundraising sprint Theme songs for programming languages: As a email manager, I'd like to see which contacts are suppressed - https://phabricator.wikimedia.org/T261705 (KHaggard) Hey a... [20:04:14] Fundraising-Backlog, Wikimedia-Fundraising-Banners, MediaWiki-extensions-CentralNotice, JavaScript, Wikimedia-production-error: Fundraising banners are throwing JS errors in CentralNotice live preview - https://phabricator.wikimedia.org/T262693 (Pcoombe) [20:37:43] (PS1) Ejegg: NOT FOR PROD More IP debugging [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631868 [20:38:25] (CR) Ejegg: [V: +2 C: +2] NOT FOR PROD More IP debugging [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631868 (owner: Ejegg) [20:44:43] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) [20:44:44] hmm, taking a long time to load pages with that new debugging [20:45:12] Fundraising-Backlog, fundraising-tech-ops: Civi credential for Engage staff member, Ryleigh S. - https://phabricator.wikimedia.org/T264337 (Dwisehaupt) Open→Resolved Verified Ryleigh logged into civi with correct certificate installed. [20:45:38] ohhhhh, unshift does something different than I though [20:54:38] oh dang, adyen audit parser failing [20:55:03] i'm betting it's those missing submethod mappings [20:55:13] maestro? [20:57:37] dwisehaupt: I think I found a way to get that XFF header pulled in correctly [20:58:04] though it will mean we have to specify 127.0.0.1 as a CDN server [21:01:58] Wikimedia-Fundraising-CiviCRM: Access to CIVI and Terminal for Noah Israel - https://phabricator.wikimedia.org/T264473 (Dereckson) [21:11:20] interesting [21:12:22] is that something that would just be modified in config? [21:13:51] yep, I'll try a couple of different places to put it after I run a quick errand [21:14:47] cool. [21:51:35] ahhhhh [21:51:46] the constant was renamed [21:52:01] just found the old name in the settings [21:52:02] wgSquidServers = array('127.0.0.1'); [21:54:40] yay. that's good. [21:55:44] ok, that's giving a good IP address now [21:55:56] so I'll revert the debugging code and redeploy staging [22:04:32] jeez, this slow connection to gerrit is a pain [22:05:57] (PS1) Ejegg: Revert "NOT FOR PROD More IP debugging" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631878 [22:05:59] (PS1) Ejegg: Revert "NOT FOR PROD: More IP /header debug" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631879 [22:06:02] (CR) Ejegg: [V: +2 C: +2] Revert "NOT FOR PROD More IP debugging" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631878 (owner: Ejegg) [22:06:05] (CR) Ejegg: [V: +2 C: +2] Revert "NOT FOR PROD: More IP /header debug" [core] (fundraising/REL1_35) - https://gerrit.wikimedia.org/r/631879 (owner: Ejegg) [22:13:52] cool cool, IP addy showing up right [22:14:02] so Monday we should be able to send more traffic through [22:14:11] oh, I'll turn minfraud back on for staging too [22:14:57] ejegg: fr-tech: do we ever run CI tests, linting, etc. for Payments locally? It's done with npm like other mw stuff? [22:15:34] I just use the phpunit maintenance script to run unit tests [22:15:37] for donationinterface [22:15:46] i admit I don't often run the linter [22:16:05] mostly just trust my IDE's linting [22:16:06] yeah. monday should be good. either later in the day. or maybe even before the email send goes out. [22:17:09] i would almost opt for before the send if we could pull it off. then we can make a plan to fully swap sooner. [22:17:29] yeah, early sounds good [22:18:52] ejegg: right cool thx...! Mmmm though there must be a way to do it, right? [22:19:37] AndyRussG: you can run composer test to do the linting etc [22:20:57] ejegg: ahhh ok right [22:21:22] looks like the sends are at 1400utc so it'd be pretty early. i may even dip into coffee for that one. :) [22:45:51] ejegg: hey just another smol question, sorry for the bother... I don't think I've ever heard of anything relevant actually being stored in the payments wiki database per se, is that correct? [22:47:07] As in, whatever base data structures that mw install.php and update.php create in the mediawiki database, with all the extensions installed, is sufficient for all possible dev work? or is there any sort of testing data setup we might want to throw in the mw database? [22:47:23] thx in advance! [22:48:50] AndyRussG: we like to put in at least a bit of HTML for the appeal template [22:48:58] that gets rendered to the side of the forms [22:49:09] just so they look about the same width as they do on prod [22:49:23] in vagrant we import that + a main page template with a bunch of testing links [22:50:27] ejegg: ahhh right ok the appeal template [22:50:33] K I should be able to find that in vagrant [22:50:41] the main page with the links I'm planning to do differently [22:51:03] ok [22:51:06] the idea for that is rather a markdown file inside the fundraising-dev repo [22:51:17] so that it'll be easy for everyone to update and share their updates across the team [22:51:46] and then we can have a very simple service that renders it into html for easy viewing and clicking in a browser locally [22:52:02] does that sound decent? [22:52:17] ahh, so the one advantage of the main page is that you can make the links relative to whatever local port number ppl are using [22:52:31] is it really harder to edit a wiki template to share changes? [22:52:36] I guess we could also have s separate file, not tracked in the git repo, for private keys for payment providers as needed [22:52:51] ejegg: hmmm maybe not, I guess I should look into that [22:53:03] right AndyRussG, we keep any private stuff on frpm [22:53:05] ejegg: wrt local port, yes that is planned as fully configurable across the whole app [22:53:29] right, but if we've got the links for testing in a markdown file, won't those need a port hardcoded? [22:53:49] right, I think there should be a way to substitute on the fly when viewing [22:54:28] we could make it inside the same wiki and import, I guess the other consideration is I kinda feel like the payments docker setup should be as close to production as possible [22:54:51] so we should have a separate donatewiki? [22:55:03] and mainpage should redirect there? [22:55:03] as in, if we add any extra stuff/extensions/wiki jobs, it's complexity not on production that could potentially cause diferent behaviour [22:55:39] ejegg: hmmmm donatewiki... do we have something like that on vagrant? what to we potentially want for dev setup there? I'd thought of the t-y pages, but I guess there's more [22:55:41] i'd be pretty surprised if main page content caused that [22:55:52] AndyRussG: no, we don't have that on vagrant [22:56:27] main page content, no, but some script to import regularly a wiki template, or some mw extension to render markdown, maaaaybeeeee [22:57:09] ahh, scheduled jobs sound like overkill [22:57:52] we can just re-run the setup script to get the changes, right? [22:58:24] yes we could, but that also does other stuff, or at least checks/asks if it should do it [22:58:43] that's why I was thinking just a super-simple markdown renderer in a separate Docker container [22:58:49] ahh [22:59:12] we don't change that content very often [22:59:28] I think we're ok to leave it as a re-run setup at least for starter [22:59:31] s [22:59:35] perhaps less often than we should? [22:59:45] maybe [22:59:53] Like, it could be expanded to have more than just payment processor links [23:00:24] I mean, I think it does, but also a more complete dev setup start page that we all keep up-to-date feels like it may have potential [23:00:37] wrt donate wiki I added a point on line 40 on the etherpad.... https://etherpad.wikimedia.org/p/fr-tech-docker [23:01:03] if you'd like to mention here, or add to the etherpad, any thoughts on stuff we'd want to reproduce from donatewiki, that'd be fantasmic! [23:02:31] errrr [23:02:46] so donatewiki is probably not something to replicate via docker [23:02:59] it's more an evolving set of wiki content than a bunch of software [23:03:04] hmm, I guess maybe [23:03:26] but it would be on the extreme side of 'sync lots of wiki content' [23:04:23] ejegg: right that's why I was thinking of just some static t-y page stand-in or something [23:05:18] hehe K I added a question mark after the donate wiki line in the etherpid [23:06:02] anyway just a placeholder in case anything comes to mind at least [23:06:16] AndyRussG: oh, i think we don't even need the mediawiki jobrunner for payments [23:06:25] since we basically do no editing [23:06:42] ejegg: yep... current setup is configuring without :) [23:06:49] cool cool [23:07:32] (just noted on line 201, as a possible issue, in case I was missing something and we did need it) [23:08:19] The thing that does seem complicated but that we have in vagrant is having payments/civi/cn sites have their own local hostnames [23:08:41] ah yeah [23:08:44] See line 200 there for a link to a possible solution, but it seems a bit much, I think we can just distinguish stuff based on port [23:08:46] there's no way to do that in docker? [23:09:05] looking [23:09:09] there is, but it's not an included-in-the-box solution [23:09:12] i'd be curious to learn a little more about how we use donatewiki in the dev/vagrant/docker environment. i don't think post 4pm on a friday is the right time for my brain to absorb it. [23:09:14] admittedly I didn't dig super far [23:09:52] dwisehaupt: pls throw anything you like in the etherpad! post-Friday-4pm thoughts, or anytime-thoughts, most welcome :) [23:11:09] dwisehaupt: there's a catch-all questions section line 204, and also pls feel free do add stuff anywhere :) [23:11:14] i think maybe i should take some time to look at the setup as compared to how we run our dev/testing environment which is pretty stateful and has a chunk of long living vms. [23:11:30] where look at may mean trying to build it for fun. :) [23:11:53] dwisehaupt: ahh right, yeah cool!! so far I've liked Docker quite a lot [23:12:03] despite running into a few hurdles here and there [23:20:34] fr-tech cartebancaire broke the audit parser, is that a separate payment method entirely I guess i thought it was some cc thing? [23:20:56] cstone oho, I just added that to the decoder [23:21:13] but we need to pull the library update into crm [23:21:16] lemme just do that now [23:32:25] grrr [23:32:32] things taking long time [23:38:05] (PS1) Ejegg: Update SmashPig library [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/631883 [23:38:14] (CR) Ejegg: [C: +2] Update SmashPig library [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/631883 (owner: Ejegg) [23:39:17] (PS1) Ejegg: Update wikimedia/smash-pig library [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/631884 [23:39:46] (CR) Ejegg: [C: +2] Update wikimedia/smash-pig library [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/631884 (owner: Ejegg) [23:45:32] (CR) Ejegg: [V: +2 C: +2] Update wikimedia/smash-pig library [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/631884 (owner: Ejegg) [23:45:47] (Merged) jenkins-bot: Update SmashPig library [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/631883 (owner: Ejegg) [23:46:13] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/631886 [23:46:42] (CR) jerkins-bot: [V: -1] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/631886 (owner: Ejegg) [23:46:57] (PS2) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/631886