[00:50:41] Fundraising Sprint Bermuda Rhombus (where things dissappear then reappear), Fundraising-Backlog, MediaWiki-extensions-CentralNotice: pull data for unique campaigns last year - https://phabricator.wikimedia.org/T185175#3908350 (DStrine) [03:51:09] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Port back delete patch from search change - https://phabricator.wikimedia.org/T185183#3908532 (Eileenmcnaughton) [12:52:29] !log turned on donations queue consumer process-control job (actual time of change 17/01/18 ~16:20) [12:52:40] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [15:17:10] hi jgleeson! [15:17:21] hey ejegg! how was your flight? [15:23:00] hi mepps! [15:23:59] flight was fine, immigration amd customs was the quickest ever [15:24:00] ejegg i have a few reviews out right now [15:24:04] nice! [15:24:49] ok, i know about the processDonorReturn one [15:25:55] something feels off about it, but i'll give more detailed feedback via gerrit [15:26:28] what would be your next priority for review? [15:28:38] hey mepps & ejegg :) [15:29:06] ejegg i'm not sure if this is too simple a solution, or if we always want the same order for credit cards: https://gerrit.wikimedia.org/r/#/c/404802/ [15:29:26] also i couldn't get my local form to respond to DonationInterfaceFormSettings.php [15:29:35] i'm not sure if it's using that file? [15:29:40] (PS1) Ejegg: Add missing @return tags [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405003 [15:29:43] (PS1) Ejegg: Fix parameters in phpDoc blocks [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405004 [15:30:11] (PS1) Ejegg: Fix extra params on method calls [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405005 [15:30:18] (PS1) Ejegg: Fix typos in comments [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405006 [15:30:49] buncha no-op patches, for review when anyone's bored enough ^^^ [15:30:57] hi jgleeson [15:32:26] coffee time [15:32:58] i'll take a look jgleeson [15:33:01] i mean ejegg :) [15:33:43] (PS2) Mepps: Add missing @return tags [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405003 (owner: Ejegg) [15:33:46] (CR) Mepps: [C: 2] Add missing @return tags [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405003 (owner: Ejegg) [15:35:48] ejegg i'm looking at the phpDoc one but notice a lot of places there aren't return parameters, should we be adding those too? [15:37:39] (Merged) jenkins-bot: Add missing @return tags [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405003 (owner: Ejegg) [15:42:08] mepps there's one patch adding @return: https://gerrit.wikimedia.org/r/405003 [15:42:19] yeah i saw that ejegg but it only adds it to a few places [15:42:58] heh, I was just adding the ones where my IDE complained [15:43:03] gotcha [15:43:20] let me see, it's a little confusing just because i have to side by side compare the patches [15:43:21] but yeah, would be nice to have 100% documentation [15:44:11] (PS2) Mepps: Fix parameters in phpDoc blocks [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405004 (owner: Ejegg) [15:46:55] (CR) Ejegg: [C: 2] "Yep, this is basically the only mechanism we have for order, and it'll affect all the forms. Let's come up with a good way to offer differ" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/404802 (https://phabricator.wikimedia.org/T185035) (owner: Mepps) [15:48:31] (Merged) jenkins-bot: Seems inelegant but reorders credit cards [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/404802 (https://phabricator.wikimedia.org/T185035) (owner: Mepps) [15:48:32] hey mepps or ejegg, can one of you run drush --version for me and tell me what version you're using locally? [15:48:33] yeah there's still a few missing returns--should i still +2 this ejegg and have that be a separate patch? [15:48:47] 5.10.0 [15:49:07] that's the same as what's on the server [15:49:48] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: Allow different order of credit cards on different country forms - https://phabricator.wikimedia.org/T185224#3909931 (Ejegg) [15:49:51] mepps yeah, if you don't mind [15:49:55] the latest version is version 9. Are we using the earlier version due to our reliance on an earlier version of drupal do you know? [15:50:26] (PS3) Mepps: Fix parameters in phpDoc blocks [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405004 (owner: Ejegg) [15:50:29] (CR) Mepps: [C: 2] Fix parameters in phpDoc blocks (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405004 (owner: Ejegg) [15:50:40] jgleeson: I think we just haven't tested newer versions [15:51:46] looks like drush 9 might be only for drupal 8 [15:52:06] ooh, drupal 8.4+ even [15:52:14] our vagrant build is failing as it looks like drush isn't available for stretch yet [15:52:15] but Drush 8 ought to work with our site [15:52:28] so I'm looking at either, building it from source in puppet [15:52:32] oh drat [15:52:38] or, using a backport apt source [15:52:42] (Merged) jenkins-bot: Fix parameters in phpDoc blocks [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405004 (owner: Ejegg) [15:52:45] fun! [15:52:54] any preference? [15:53:30] Huh, I thought we had it checked in to gerrit someplace [15:54:11] can we just clone it from /wikimedia/fundraising/crm/drush ? [15:54:18] sorry, back in a bit... [15:55:18] fundraising-tech-ops, Operations, netops: bonded/redundant network connections for fundraising hosts - https://phabricator.wikimedia.org/T171962#3909954 (Jgreen) [16:00:47] ejegg|afk, that version in gerrit is 7.0-dev [16:01:06] I'll add that for now and we can change it if you like at a later point [16:12:45] sounds good! [17:28:56] XenoRyet, just seen the screen extend part haha [17:29:02] brilliant! [17:29:07] So good [17:29:28] the angry mouse shake afterwards, which happens all the time [17:29:41] I also liked this one: [17:29:43] https://gfycat.com/QueasyGrandIriomotecat [17:31:29] the imaginary act of vandalising whatever it is on screen by shaking your cursor erratically around it, is the my standard reaction to any annoyance [17:32:03] Yep, I do it every time. [17:34:54] jgleeson: thought you might be interested/dismayed: https://phabricator.wikimedia.org/T185134 [17:36:12] ah man [17:36:45] just when I thought we'd made some progress [17:37:01] -_- [17:37:31] currently weighing the pros/cons of staying with prometheus at all [17:38:14] one minor positive is most of the work done recently was to make the solution *backend agnostic* so if we do switch, it's just a new export mapping update, hopefully... [17:38:30] for instance, it is built by a company that is built on top of docker [17:38:55] and optimized for having a million servers/containers/whatever [17:39:16] not exactly our use case [17:41:48] To retain access to your historic monitoring data we recommend you run a non-scraping Prometheus instance running at least version 1.8.1 in parallel with your Prometheus 2.0 instance, and have the new server read existing data from the old one via the remote read protocol. [17:56:06] lol [17:56:58] fr-tech, off out to pick family up as we're having some bad weather here. Be back on later [17:57:10] drive safe! [18:09:59] (CR) XenoRyet: [C: 2] Fix typos in comments [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405006 (owner: Ejegg) [18:11:11] (CR) XenoRyet: [C: 2] Fix extra params on method calls [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405005 (owner: Ejegg) [18:12:54] (Merged) jenkins-bot: Fix extra params on method calls [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405005 (owner: Ejegg) [18:17:38] (Merged) jenkins-bot: Fix typos in comments [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/405006 (owner: Ejegg) [18:34:17] hey ejegg i see some old patches from september like this one--https://gerrit.wikimedia.org/r/#/c/324789/--do you want me to review still? [18:37:44] stepping out for a bit [19:32:48] mepps sure, that one would be good to have! [19:32:52] thanks [19:46:34] hopefully wont have to drive through conditions like that again anytime soon! [19:50:00] ejegg|afk, I noticed something earlier Prometheus related. I think we need to switch over from counter to gauge for our metrics using the TYPE token/comments covered here https://prometheus.io/docs/instrumenting/exposition_formats/#text-format-details. [19:50:41] you may have already told me this, I have a vague memory of us discussing it :) [19:51:50] as our numbers go down as well as up, it doesn't fit the counter description here https://prometheus.io/docs/concepts/metric_types/#counter [19:58:27] jgleeson: glad you got home safe! [19:59:18] Are you able to log in to the grafana admin? https://grafana-admin.wikimedia.org/ [19:59:25] thanks. pretty crazy hail storm here making it impossible to see [19:59:31] yowza! [19:59:39] yup [19:59:48] yup to logging in [19:59:53] great! [20:00:21] so how do the new metrics look when you try to add them to a graph? [20:00:44] feel free to make a new dashboard to play around with if you don't want to tweak the existing one [20:00:48] just yet [20:01:16] I tested them the day after we released them and they looked good although I then discovered the bug with the metric that is always present even when it shouldn't be [20:01:33] since then I've been trying to get a working dev environment so I can reproduce locally heh [20:02:00] but near there now, and then will patch that issue and switch over to new metrics [20:02:31] we could switch over now, as the affected metric isn't currently used (it's the message enqueued age) but figured I'd fix the bug first [20:03:02] cool, cool. So does prometheus consider scalars a counter by default, unless you add the gauge type comment? [20:03:32] that bit I'm not sure on [20:03:51] I would guess yes [20:04:24] I'm not sure if I've actually accessed the Prometheus frontend for our live environment [20:05:52] nope, nothing in my history. Looks like I've only been checking with Grafana for the last few months [20:06:14] oh yeah, I guess I've only been seeing the stats via grafana too [20:06:15] the reason I ask is I think Prometheus tells you the metric type, in the metric output data [20:10:06] aha, just found the instructions on wikitech for getting into the actual prometheus web interface [20:10:30] https://wikitech.wikimedia.org/wiki/Prometheus#Access_Prometheus_web_interface [20:11:16] awesome [20:11:23] hmm, .wmnet [20:11:34] I guess that's through the main prod bastion? [20:11:50] tin [20:12:05] no [20:12:06] bast1001.wikimedia.org [20:14:08] drat, which credentials though? [20:17:14] going to ask over in #wikimedia-operations [20:24:57] sup guys [20:25:15] you will need extra access if you want to access prod prometheus [20:28:27] it may be easier to access the frack instances [20:29:06] oh hey, you guys set up the private prometheus instance for frack already? [20:31:26] hey eileen_! [20:31:58] ejegg: yep we've always had our own, and it feeds the prod one [20:32:12] we actually have 4 instances :o [20:32:41] well that was a good rabbit hole. Our civi install and drupal install were failing due to the install script templates not being written. took a while to work out that it was due to a failing "unless" mysql query relying on the root account and password. However with maria db the root account is accessed with a password, instead it's accessed as sudo as it takes the permissions from the user calling mysql! [20:32:53] I think you mentioning something about that bd808 [20:32:59] mentioned* [20:33:25] mariadb, root account accessed WITHOUT* a password [20:33:29] but look at all the different things grafana can do... http://docs.grafana.org/features/datasources/ [20:38:57] jgleeson: yeah. that's the default auth for the new mariadb builds on Debian apparently [20:39:06] at least for the root account [20:39:59] it actually highlights that we would benefit to add a specific mysql user with perms to access the tables being queried and not relying on root [20:40:04] from adding* [20:42:24] eileen_ i have a question about https://issues.civicrm.org/jira/browse/CRM-18106 [20:43:19] mepps: I just saw a question from you fly by [20:45:17] jgleeson|food: the civi install scripts we use in CI only use root to create the empty DBs and a user to own them, [20:45:27] then with that user they create the rest of the tables [20:45:36] hi eileen, i was curious how to find the json stored of the contact ids--i can't find it so far [20:45:49] checking to see how it is in the vagrant build [20:45:52] which was the phab [20:49:39] it's this jira issue: https://issues.civicrm.org/jira/browse/CRM-18106 [20:51:17] mepps: I don't think it happened [20:51:35] it was the outcome of discussion but I can't see much evidence of it :-( [20:51:51] eileen, ah, thanks--yeah same here, but was worried i was missing something :) [20:52:17] yeah - & now we have gone done assignee - but I have not got upstream buy in yet - so that is something to work through! [20:53:47] eileen i have mixed feelings aobut assignee myself [20:54:08] which is part of why i haven't pushed upstream hard [20:54:13] yeah - i haven't quite resolved myself either [20:54:48] obviously last discussion I came to a different conclusion but that was in part on the idea we might be able to merge multiple at once [20:55:02] but, I'm not 100% sure about the value of that [20:55:42] i feel like maybe the activity records are okay, but there should be a link both in the db and the ui between the deleted contact and the merged contact [20:56:23] i was hoping the json was already in there [22:53:34] fundraising-tech-ops: allow fr-tech access to prometheus web interface - https://phabricator.wikimedia.org/T185268#3911427 (cwdent)