Time/Place
Join fedora-project.slack.com on the "tech" channel
- Self-register at: http://slack.fcrepo.org/
Attendees
- Danny Bernstein
(note taker) - Peter Winckles
- Michael Ritter
- Demian Katz
- Geoff Scholl
- Joshua Westgard
- Mark Jordan
- Arran Griffith
Agenda
- Desired Features
- Review Existing Solutions
- UMD
- Features
- Scalability
- Limitations
- RipRap
- Features
- Scalability
- Limitations
- Camel Toolbox
- Features
- Scalability
- Limitations
- UMD
- To extend or to roll anew
- Availability over this quarter
Notes
Riprap Mode:
- started in 2018. Islandora 2 was just getting going. Responding to limitations of Islandora’s fixity checking capabilities (repo bloat)
- cron basis, get a list of resources, check with last recorded in database.
- designed with wider user case in mind ( not Islandora only)
- has various plugins for messaging, pulling resources, etc.
- README contains
- Symphony framework (PHP) not great -
- Compliant with PREMIS event and vocabularies
- Scalability: run multiple instances of Riprap
- Thin Mode (last success / or failure) - keeps database size down to a minimum.
- Commandline interface and REST for reporting: returns JSON and CSV
- start and end
- outcome
- offset
- sort
Demian - suggested using version hardening techniques (using platform in compose json and avoid * dependencies) for dealing with symphony/php version migration issues.
UMD - https://github.com/umd-lib/umd-fcrepo-docker/tree/develop/fixity
- starts with cron job to kick off the checking.
- nightly fixity checking window - avoids putting undue load on Fedora during peak usage times
- uses activemq - originally used camel but moved away and just uses activemq directly
- separate audit triplestore - tracks premis events
- generating the list of candidates was tricky with the bottleneck (solved with list caching) - not currently using a relational database
- continuous checking model - everything checked every 6 months or so
- checker is python based
- goes through Fedora API’s fixity checker
- fixity checker sends an event to success or failure queues where they are split into different queues - write to triple store, send email
Actions: Mark Jordan and Joshua Westgard will update the matrix on the desired feature page to clarify what currently exists and what could easily be added to complete the feature set.
