Thu, Nov 19
We talked about about a standalone lint script that can be used from git, fundraising_code_update, and process-control. The script would extract the 'schedule' value from a process-control yaml config file and sanity check it. It looks like python3-crontab will be a good start.
Wed, Nov 18
Because we love regexes . . .
Tue, Nov 17
frmx1001 & frmx2001 are in service and we're in the process of phasing mail over to them
frmon1001 was upgraded during yesterday's maintenance window
frdb1004 is in service, we'll task the frdb1001 decom separately in Jan 2021
Mon, Nov 16
Tue, Nov 10
Mon, Nov 9
Wed, Nov 4
Mon, Nov 2
frpig1001 is done
Fri, Oct 30
Thu, Oct 29
Doesn't seem to be much interest in this, closing.
The SRE portion is essentially done: https://collab.wikimedia.org/wiki/Fundraising/Engineering/Emergency_Datacenter_Cutover_Procedure.
At this point I don't see a clear indication of a slowdown since the php 7.3 upgrade. As Dallas noted noted above we may be leaving 7.3 performance gains on the table by not enabling OPcache, but we don't think we can do that without sandbox testing.
Task T140311 is already tracking performance tuning issues/ideas.
Removing fundraising-tech-ops tag as this is a software development task. Dallas volunteered a patch, but it has been sitting unreviewed since June.
Wed, Oct 28
Reopening to fix payments100[1-3] since we did a dist-upgrade to Buster instead of a full reimage.
Tue, Oct 27
Tossed back into Fundraising-Backlot triage column b/c the next steps are to get FR Tech input to the areas mentioned above.
Setting priority to "High" because debug logging like this can become a performance issue during peak FR season.
This is mostly done https://docs.google.com/document/d/1oIbiBFDkzIgliF_EaNmEzaUv_y2BW0QN9Fr5uyDKPoY/edit?usp=sharing but needs FR Tech help around the issues of validating redis incrementer (section 7) and migrating and validating queue consumer jobs (section 18).
Oct 21 2020
payments-wiki localsettings tree is updated to match payments-wiki-staging. In the process I noticed payments-wiki-staging/employers.csv is just the stub file, so I did not port that back to payments-wiki.
I updated the frdeploy payments-wiki branch to match payments-wiki-staging (which is what we're currently running on). We still have to clean up the payments-wiki localsettings tree before we can switch over to the payments-wiki frdeploy project.
I don't think we should broaden access to civicrm staging if it is avoidable.
Boxes are up and running and so far appear to deliver mail properly. The ops/sre part of the project is complete. There's a separate task to switch civicrm to use them.
This is all interaction of the stock Debian packages (dovecot-core vs systemd-?) packages. It looks like a debug/warning with no actual functionality impact, so I don't see any point in spending the time to fix it.
Oct 20 2020
@Eileenmcnaughton I did some testing and the phpmailer functionality seems reasonable. I have a couple observations.
Oct 19 2020
I'm finding it hard to spot a clear trend with so much variation in the graph, also I'm not entirely clear on what the underlying metric is. These queries poked into grafana's explore tool could be useful: