Agenda:
Introduction and context (Steve Van Tuyl tamsin woo 10 minutes)
We’d like to come out of Connect with an emerging plan for Valkyrie/Hyrax
There is a bunch of work and thinking that has been done thus far, but we need to ensure that we’re taking the right approach
https://wiki.duraspace.org/display/samvera/Valkyrie+Discussion+-+2018-10-04
What has been done? (30 minutes)
Valkyrie (Trey Pendragon )
- Storage differences btwn valkyrie's fedora 4 adapter vs. hyrax's use of fedora:
- valkyrie does has members differently than hyrax.
- valkyrie doesn't use indirect containers; it puts the triples straight on the graph
- object > binary > metadata about binary (hyrax) vs object > metadata profile > binary (valkyrie); it's real hard to flip this around in valkyrie
- One idea would be to have read-only adapters meant for migration purposes. this would be a much easier way forward here.
- do institutions want to stay on fedora and use a hyrax-y fedora adapter going forward
- Tom: a couple possible approaches to moving folks over
- Ship with an immediate / abrupt code cut-over and expect everyone to update their applications
- use a read-only fedora-hyrax adapter; ship it and expect everyone to upgrade right away; whenever something gets read out of fedora in the old model, replace it with a version running through the new metadata adapter. this could be a data migration over time, with an immediate code migration
- existing writes through active fedora are immediately breaking (lead to data loss)
- Allow the fedora-hyrax adapter to be read/write, leave active fedora in place; allow adapters to decide when they want to make the code cut-over. Allow code migration to be step-wise
- Ship with an immediate / abrupt code cut-over and expect everyone to update their applications
- Why can't I just power valkyrie up with active fedora? V has features not available in active fedora like arbitrarily deep nested objects and ordered properties
- Let's not call it valkyrie-hyrax!! because it is really more like a valkyrie-AF or valkyrie-pcdm
- Storage differences btwn valkyrie's fedora 4 adapter vs. hyrax's use of fedora:
Valkyrie on Hyrax v.1 (justin )
- A 4-week effort which got valkyrie in by find/replacing all uses of active fedora. This code is out of date since collections work was merged
- One difficult piece was versioning; only fedora has a "version this" button. They implemented in hyrax by saving the new resource directly, maintaining pointers, etc.
The Hamfisted Version (Slide deck: http://bit.ly/hyrax-valkyrie) (Josh Gum )
Where do we go? (15 minutes)
CHECK IN; should we:
Continue discussion;
a wide expectation that Valkyrie is coming to Hyrax may exist in the community
- is there an easy way of learning? poll/survey
- give respondents options weighted across a variety of real-world paths/scenarios (around time/money/quality/, code vs. data migration, etc.)
- some members will not migrate (due to their resources) until there is something like Valkyrie
- is there an easy way of learning? poll/survey
Break-out technical subgroups?
Whiteboarding
Hacking
Report back (last 20 minutes)
What were the concrete outputs from today?
What are the next steps?
What, if any, additional get togethers should there be at Connect?
What commitments do we need to accomplish this?
What should our ask be for the rest of the conference?
...
- side-by-side approach with both current activefedora gem supported at the same time that an activefedora-adapter is implementedparallel code is written supporting valkyrie read-write.
- controllers and models will be created that use the read-only activefedora-adapter.
- continue to support activefedora gem codeonce activefedora-adapter approach is completely functional
- if required, extend activefedora-adaptor to be read-write
- once valkyrie approach is complete, remove code using the activefedora gem approach. Complete is defined as...
- EITHER read-write activefedora-adapter approach is completely functional
- OR if it is decided that read-write is not required, once read-only activefedora-adapter AND parallel code for using other write adapters is complete
- can use feature-flipper approach
- Tom - when an app is deployed, it can choose which approach it wants
- Trey - use generators to generate one or the other; change is at controller level
- pro - migration is not a line in the sand and development can respond to deprecation notices over time
- pro - other work can continue while this large effort is being developed
- con - can make hyrax even more complex as both approaches are supported at the same time
- con - greatly increases the number of tests to run since you have to test both approaches
...
- The various bars address data migration, but all bar options require code migration for any customizations by apps.
SURVEY VOLUNTEERS: The survey should include questions proposed by tamsin woo and Steve Van Tuyl. Let's document the survey process, and make it available on the samvera wiki, so we don't keep doing them ad-hoc.