[FOLIO-2634] Upgrade folio-registry to Okapi 3.x Created: 03/Jun/20  Updated: 23/Mar/21  Resolved: 23/Mar/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: TBD
Reporter: Wayne Schneider Assignee: John Malconian
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to OKAPI-840 verify "securing by default" impact o... Closed
Sprint:
Development Team: FOLIO DevOps

 Description   

The Okapi instance that serves as the FOLIO project module descriptor registry at http://folio-registry.aws.indexdata.com needs to be upgraded to Okapi 3.x, and it needs to contain only Okapi 3.x-compatible module descriptors.

There are a couple of possible approaches:

  • Maintain the existing Okapi 2.x registry at a different URL to support 2.x installations. Question: should we stop updating it? Create a new Okapi 3.x registry at the http://folio-registry.aws.indexdata.com URL with only 3.x-compatible module descriptors
  • Upgrade all the module descriptors in the existing registry to contain the permissionsRequired property on all interface endpoints, then upgrade the Okapi instance to v3.x

Obviously, there are pros and cons to each approach. Jakub Skoczen, John Malconian, David Crossley – please add details and comments.



 Comments   
Comment by John Malconian [ 03/Jun/20 ]
  • I prefer the first option. However, it's going to be difficult to update both registries simultaneously. Is it possible to wait until all modules are compatible with the 3.0 format before making the switch?
  • I don't like the idea of modifying existing MDs. That just seems wrong somehow. MDs should be immutable, IMO.
Comment by Jakub Skoczen [ 05/Jun/20 ]

Adam Dickmeiss John Malconian Wayne Schneider

Adam, is the "pull" operation going to fail also in the case when the some of MDs stored in the registry miss the permissionsRequired field EVENTHOUGH these MDs would not be used for install?

Comment by David Crossley [ 05/Jun/20 ]

Apart from the question to Adam above, my task was to see how using an instance with okapi-3.0 would fare with pulling latest ModuleDescriptors (which includes some that do not yet have permissionsRequired) from the current folio-registry (which has okapi-2.38.0).

Yes that pull is successful.

Comment by Wayne Schneider [ 05/Jun/20 ]

OK, in that case, maybe this shouldn't happen until after we stop officially supporting Fameflower (because hotfixes may still be released with incompatible module descriptors, so we'll want to maintain the registry as Okapi 2.x)? Then, at that point, we can purge all the pre-Goldenrod descriptors and upgrade to Okapi 3.x.

That would certainly make things simpler!

Comment by Adam Dickmeiss [ 06/Jun/20 ]

That is all covered in OKAPI-840 Closed

Comment by Adam Dickmeiss [ 06/Jun/20 ]

Do NOT modify existing module descriptors (they are supposed to be immutable) Better just remove them .. Or as I've been said , make a "branch" registry for each MAJOR release Q1, Q2,.. with set of modules for that version.

Comment by Jakub Skoczen [ 09/Jun/20 ]

John Malconian has the registry been updated to Okapi 3.0?

Comment by Jakub Skoczen [ 10/Jun/20 ]

David Crossley confirms that there's not compatiblity issue when pulling MDs with Okapi 3.0 from Okapi 2.x CR.

Comment by John Malconian [ 23/Mar/21 ]

Not relevant at this point. Superceded by upgrade of folio-registry to 4.7.2.

Generated at Thu Feb 08 23:22:07 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.