- UI looks good (all set)
- Queue consumers work well
- any other process-control jobs that we can easily run also work well
|Open||Jgreen||T243019 OKR 2019-2020 Q3: Support fundraising through maintaining infrastructure for payments and donor data|
|Stalled||Jgreen||T242257 2019-2020 Q3 fundraising hardware refresh and capex|
|Open||None||T242270 rack/setup/install civi2001.frack.codfw.wmnet|
|Resolved||None||T254940 Test CiviCRM on new box|
|Resolved||Jgreen||T256317 refactor civi1001 archive_sync jobs to also keep civi1001 and civi2001 audit data in sync|
|Resolved||Jgreen||T256318 modify pc_log_archiver to add hostname to the target filename on log rotation|
Testing process-control jobs.
Dedupe job ran fine
Can't run any queue stuff - can't connect to frqueue1001
Can't connect to Silverpop - probably just need to put new IP in allow list on Silverpop side.
@Jgreen and @Dwisehaupt we can't test audit processing - the /var/spool/audit folder and its subfolders (adyen amazon astropay globalcollect paypal) don't exist on the new box, and once they do we want to somehow synchronize the contents with those on the old box.
Each of those processor-named folders has 'completed' and 'incoming' subfolders. When we download new files, we grab anything that the processor has that we don't have in either folder. Those come in to incoming, and we process them from there. Once we've found all the donations in a file, we move it to the 'completed' folder.
So starting with empty dirs on the new box will mean we download gigs and gigs of logs on the first run and then try to process lots of things we've already processed.
I have pulled the audit directory structure of civi1001 from frlog2001 and put it into /srv/archive/civi2001/audit on civi2001. The permissions should be all correct and ready for further testing. This data footprint was a bit larger than on civi1001 currently has on disk. I'm not sure if there is any data processing or culling that would cause the difference but just wanted you to be aware of that.
IIRC audit processing (or maybe just orphan-slaying?) also uses logs that we push over from the central logger, which is done by archive_sync on frlog*, but we hadn't set this up yet for civi2001. This is fixed.
@Ejegg I reconfigured the archive sync script to pull this dir from civi1001 and push it to civi2001. This will keep civi2001 in sync but we'll need to stop and/or reverse the archive sync to promote civi2001 to the active audit processor. Please coordinate with us when you're ready to test audit processing on civi2001 so we can adjust this stuff.