Time/Place
This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Audio/Video Conference Link: https://lyrasis.zoom.us/my/fedora
- Dial-in:
+1 408 638 0968
+1 646 876 9923
+1 669 900 6833
Meeting ID:
812 835 3771
- Dial-in:
Join fedora-project.slack.com on the "tech" channel
Attendees
Agenda
- Announcements
- Fedora 5.1.0 Release
- Update on Fedora 6 Pilots (NLM, Docuteam, UWM)
- migration-utils work
- Configure "fedora4Client" to new implementation of the Fedora4Client.java interface
- Writing to OCFL instead of Fedora4/5/6 API
- migration-utils work
- Sprint Planning
- 6.0 Architecture Review
- Problems requiring design
- Transaction and Lock Management
- Transactions scope: what do we need to support?
- Individual Resources
- Groups of resources
- Containment hierarchies
A Fedora transaction may span multiple HTTP Requests. Assuming that we do not want to commit anything to OCFL until the Fedora Transaction is committed, how do we maintain the state of open OCFL Sessions
across requests?
- across instance reboots?
- across multiple horizontally scaled instances?
How also do we ensure that two requests using the same transaction ID against the same OCFL object do not stomp on each other
- Globally accessible state (for horizontal scalability)
- Transactions scope: what do we need to support?
- Caching/indexing strategy
- What caches and indexes do we need(ie in what layer(s)?)
- OCFL client
- Persistence Implementation (OCFL)
- Kernel Implementation
- Physical location of the cache (assuming we want to plan for horizontal scalability support)
- Cache per instance?
- synchronizing changes across instance
- 1 Global cache/index?
- Cache per instance?
- What caches and indexes do we need(ie in what layer(s)?)
- Transaction and Lock Management
- Your topic here...
Tickets
In Review
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Notes
- Folks are largely out today : just a skeleton crew.
- Is it worth exposing an HTTP interface to the OCFL Go client?
- Advantage: decoupled service that can be used for a variety of purposes, not just Fedora
- Disadvantage: performance could suffer, especially when thinking about supporting S3 (client → http → fedora → http → ocfl → http → S3 = lots of hops)
- migration-utils (f3 → ocfl) work is moving forward: Andrew is looking for internally consistent Fedora 3 data sets for testing : will push something up once he's able to run a successful test.
- There is agreement on the team to merge Danny's fcrepo4 PR that removes modeshape.
Actions
- Danny Bernstein will reach out to Greg about DRASTIC test results
- Ben Pennell will review import/export tasks