/
Samvera Tech Call 2026-02-18

Samvera Tech Call 2026-02-18

Meeting Logistics:

Agenda (meeting notes below)

  • <add your agenda item here (your name)>

  • UNC Hyrax 5 migration questions, see list in Notes section (Rebekah Kati, Ben Pennell, Dave Campbell)



Moderator: @Daniel Pierce

Notetaker: @Sarah Proctor

Attendees:

  • @Bradley Watson

  • @Rebekah Kati

  • @Randall Floyd

  • @Tracy McCormick

  • @Ben Pennell

  • @Nicholas Mark Homenda

  • @Randall Floyd

  • @Mark Bussey

  • Kirk Wang

  • Dave Campbell



Meeting Process

  1. Standing pre-agenda items (moderator)

    1. Welcome

      • "Welcome everyone, please add your name to the Attendees list.  If you are unable to do so, please let us know, and someone will add you. To any newcomers, Welcome, and please feel free to ask questions. Likewise for all attendees. We strive for an open and accessible conversation around Samvera technology."

    2. Call for new agenda items

  2. Follow Agenda from above (facilitated by moderator) and record notes in Notes section below (note taker)

  3. Standing post-agenda items (moderator)

    1. call for next moderator and note taker (moderator)

      1. Moderator:

      2. Notetaker:

    2. Samvera help follow-up (moderator)

    3. Pull request review (moderator)

      1. Recent Samvera PR list

  4. Post-meeting action (note taker)

    1. After call, this week's notetaker should create the agenda for the next call:

      1. Open template agenda titled "Samvera Tech Call XXXX-XX-XX"

      2. Click on ... in the top right corner, and select “Duplicate”.

      3. Popup will open for location. It should contain:

        1. Space: Samvera

        2. Parent page: (Verify value is current year)

      4. Select “Duplicate”. New page should be created.

      5. Modify the title to remove "Duplicate of", update it with the next date, add moderator, notetaker, and any carry-over agenda info. Click Publish. 



Notes

  1. UNC Hyrax 5 migration questions (Rebekah Kati, Ben Pennell, Dave Campbell)

    1. Is the preferred approach to upgrade the application with data left in place in Fedora 4, and then migrate gradually?

      1. When doing this, would we be migrating to using Valkyrie for the fedora 4 connection, or would that stay on ActiveFedora while we would be using Valkyrie code for talking to fedora 6?

    2. Would it be safe to leave the data exclusively in Fedora 4 for some time? We are likely going to have to do a major OS migration at the same time due to ruby versions, so if we can cut down on the number of simultaneous migrations that would be helpful.

    3. Are there cases of migrating from fedora 4 to 6 at the same time as upgrading hyrax 4 to 5, using frigg?

      1. Or is the emory approach the main way to do both at once?

    4. What is a good starting point for this migration? We have a lot of overrides that will likely need to be updated, can that be done separately from the data migrations?

      1. Are there any parts of the code base that would help us get a sense of how to set up the migrations?

    5. Do you know of institutions that have migrated from fcrepo 4 to postgres?

Meeting Discussion Notes

  • Hyrax 5 migration questions

    • List of question above to address how to get started and what direction to go

    • Migrations: Upgrade application to Hyrax 5 and leave the data where it is in Fedora 4 then make use of the migration adapters which will migrate gradually moving the most frequently used objects first

      • Hyrax 5 has tooling that will run the migration in the background

      • Another path is to re-create the application in Hyrax 5 then do a custom migration to the new system

      • Mark’s system is using Fedora 4 which uses ActiveFedora which is wrapped in Wings

      • The migration tooling for gradual migrations will require new implementations of the models that will be based on Valkyrie resources

      • The lazy migration approach runs on save (edit) which copies objects from Fedora over to Postgres (or the new storage adapter)

        • The other option is to run an active migration in a background job

        • There has been issues with deleted if the object is deleted in the new location it can still exist in the old location (this is known bug that may have been resolved at this point)

      • If the binaries were stored in Fedora 4 (not in a S3) they will have to get moved somewhere (another Fedora, etc) during migration in one way or another

        • Could do the metadata migration first then the data, or could do both at one

        • During migration binaries will likely be stored twice

      • Sunsetting Fedora 4 by removing ActiveFedora models and fedora.yml config, wings disabled, make sure there are no classes using Fedora models, once the migration is done all the Solr records are reindexed

        • Koppie runs without fcrepo

        • GBH shut down Fedora but after a metadata-only migration (not binaries)

    • Leaving data in Fedora 4: Mark’s application did a Hyrax migration but left data in Fedora 4 for now and it is working okay

      • In the future there will be a major Hyrax release that removed support for Fedora 4 and ActiveFedora

    • Is anyone using a Frigg adapter to migrate at the same time as going from Fedora 4 → 6: not currently

      • Some development and further discussions are underway

    • Good starting point: Checking overrides and ensure you have as much test coverage as possible

      • Documenting what needs to be tested manually

    • Any examples: the Hyku repo should have examples of going to Postgres

      • Dassie is a working Hyrax 5 and Fedora 4 application that can be used as a comparison with gem versions, wings config

  • Consistent flaky/failing tests (two in Koppie and two in Sirenia) in Hyrax when adding generators in attempt to add Ramp that cannot be replicated locally

  • Bulkrax demo that is open to everyone is happening today at 10:30 PT / 1:30 ET