Hyrax Interest Group Call 2024-08-14

Owned by Rebekah Kati
Last updated: Aug 14, 2024 by Heather Greer Klein
2 min read

Time: 11:30am-12:00pm Eastern

Connection Info: Join our Cloud HD Video Meeting

Community Notes

Notetaker:

Attendees:

  • @Rebekah Kati (UNC-Chapel Hill)

  • @Randall Floyd

  • @Heather Greer Klein

  • @Emily Porter

  • @Dan Field

  • @Arran Griffith

  • @Rob Kaufman

  • @Juliet Hardesty

  • @Bradley Watson

  • @Nicholas Mark Homenda

  • @Sudha Anand

  • @Steven Ng

  • @Daniel Pierce

 

Agenda/Notes

  • Hyrax Maintenance Working Group update - Rebekah Kati and Daniel Pierce

    • Hyrax-Fedora 6 update

      • Github actions work

      • Visibility bugs

      • Big thanks to Brad, Emily, and other folks from Emory for all their continued work on this

    • Upcoming community sprints for Hyrax-Fedora 6 and Accessibility work

      • Hyrax-Fedora 6: September 3-13

      • Accessibility: October 28-November 8

      • We have ambitious goals and need your help to accomplish this

    • Tech Lead wanted! Please consider taking on this role. You do not need an in depth knowledge of Hyrax; being in the role will give you a better understanding of the code and connection with the community.

  • Topics and Projects

    • Hyrax and Infra Finder - Hyku entry example

      • Heather will share a draft in Slack for a Hyrax entry

    • Hyku news

    • Frigg and Freya migration adapter Q&A with Rob

      • Broadly the idea is to allow folks with Fedora 4 data (potentially 3) to live migrate to Fedora 6 or Postgres. They wrap the existing Valkyrie adapter. Freya adapter (Postgres) Frigg adapter (Fedora 6), every time you write an object it is written to Postgres/Fedora 6, while your existing Fedora 4 is still running as normal. You can live migrate by reading each object and saving it. No need to ever run two systems in a migration, or take anything out of production. Well-tested structure to wrap the adapters, read to both, and write only to the new one.

      • If you have a Fedora 4 instance and you are minting a custom noid pattern, will this be supported in the migration at the fileset level? Emory has found in a greenfield export, the need for an alternate ID configuration. Artifact of Valkyrization rather than the transition. Doesn’t modify data between systems, takes what is there. There’s Hyrax code that need to be written to create and sustain noids. Don’t need a solr reindex as long as the IDs remain the same.

      • GBH has run all of their records through, PALNI/PALCI Hyku instance is currently migrating, and may have uncovered a bug in that process.

      • Default in Fedora 6 is UU ID. Pair tree ID is option

 

Questions?

Next meeting: September 11 at 11:30am Eastern

 

Notes