[FOLIO-1727] SPIKE: select particular implementation when interface is provided by multiple modules Created: 22/Jan/19  Updated: 03/Jun/20

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

Type: Task Priority: P3
Reporter: John Malconian Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: ci, platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
is cloned by FOLIO-1753 Replace mod-kb-ebsco with mod-kb-ebsc... Closed
Relates
relates to OKAPI-337 Multiple instances with same interface Closed
relates to OKAPI-661 Test effect of module renaming on Oka... Closed
Sprint:
Development Team: Core: Platform

 Description   

In certain cases we may have multiple modules provide the same interface and there's no standard way to address it.



 Comments   
Comment by John Malconian [ 22/Jan/19 ]

We'll start with updating the hosted folio-testing environment first and wait for the go ahead from Carole Godfrey before updating the folio-snapshot environment. Since the two modules share the same interface versions, the java-based module on master needs to be a higher version than the current version of the ruby-based module in order for Okapi's interface dependency resolution mechanism to resolve to the java-based module.

Comment by Carole Godfrey [ 22/Jan/19 ]

Of note – users of mod-kb-ebsco-java module require permission kb-ebsco.all to access needed backend functionality

Comment by John Malconian [ 22/Jan/19 ]

mod-kb-ebsco is at version of 1.0.2-SNAPSHOT.157 on master according folio-registry. The latest release version is v1.1.0. mod-kb-ebsco-java is currently at 0.1.0-SNAPSHOT. There is currently no MD for mod-kb-ebsco-java posted at folio-registry. In order enable mod-kb-ebsco-java on folio-testing, I'll need to manually post a MD for v0.1.0-SNAPSHOT to folio-registry. When we are ready to enable mod-kb-ebsco-java on folio-snapshot, we need to merge a mod-kb-ebsco-java PR that enables posting the MD to the registry as well as increment the version to v2.0.0-SNAPSHOT. Wayne Schneider does this sound right to you? I guess I'll test the Okapi install endpoint to see which modules are resolved before implementing any changes.

Comment by Wayne Schneider [ 22/Jan/19 ]

John Malconian this sounds right, but why do we need to jump to v2.0.0? Did you mean v0.2.0?

Comment by John Malconian [ 22/Jan/19 ]

Carole Godfrey created https://github.com/folio-org/mod-kb-ebsco-java/pull/91

Comment by John Malconian [ 22/Jan/19 ]

Wayne Schneider I did mean 2.0.0. I wanted to ensure Okapi's install endpoint grabbed the latest version of the module (both modules have the same interface and interface version). Now that I think about it, however, I don't think this will guarantee anything since they different modules. So, I guess I'm not sure what Okapi will do with different modules with the same interface/version and if it will be consistent.

Comment by Wayne Schneider [ 22/Jan/19 ]

John Malconian judging from this comment on FOLIO-1632 Closed , Okapi will return an error.

Comment by John Malconian [ 23/Jan/19 ]

Hmm. Bummer. In the case of FOLIO-1632 Closed we could just remove the conflicting MDs. In this case, however, we need to support older builds (Q3 & Q4 2018) so I cannot simply remove the old descriptors. But can I? The quarterly builds are based on static install.json files. There is no 'okapi pull' from folio-registry. Instead, the module descriptors for each module in the quarterly builds are posted directly to the Q3/Q4 okapi instance and not from the registry. So I probably could delete the old module's MDs from the registry. However, I'm not sure who might be impacted by this outside of the our own CI environment.

Comment by Wayne Schneider [ 23/Jan/19 ]

Doesn't the build task get the module descriptor from the registry with a GET request even if it doesn't do a pull? (I'm pretty sure it does).

Could we add mod-kb-ebsco-java as an "extra" module (as with mod-codex-*), so that it's posted to Okapi as part of the initial dependency resolution request?

Comment by John Malconian [ 23/Jan/19 ]

yeah, you're right. I guess we could add as an extra module although that seems a bit hacky. Probably the likeliest solution at this point.

Comment by Adam Dickmeiss [ 29/Jan/19 ]

I suppose even if Okapi had a "replaces" feature, like Debian (see OKAPI-661 Closed ) then.. if the interface and version are the same, the new module would still be pulled for a Q4 (or?) If so,
I think we should have a separate repo, just like Debian — which has a repo per distribution.

Comment by Hongwei Ji [ 29/Jan/19 ]

How about codex? We have different modules implementing the same codex interface and version.

Comment by John Malconian [ 29/Jan/19 ]

Hongwei Ji I don't think that any modules specify codex interfaces as a dependency, do they? We typically declare the codex modules explicitly when installing.

Comment by Hongwei Ji [ 29/Jan/19 ]

Does UI module count? https://github.com/folio-org/ui-search/blob/master/package.json#L29

Comment by Jakub Skoczen [ 29/Jan/19 ]

Hongwei Ji Adam Dickmeiss John Malconian Guys, I renamed this to represent the spike about finding the general solution. I cloned the original issue an linked it here.

Question 1: do we need a general solution in order to complete FOLIO-1753 Closed ? Wouldn't bumping the interface version solve the problem (to "force" the module upgrade).

Question 2: it sounds like what we are after is the ability to control what implementation is used. Maybe we could add this to the MD?

Comment by Wayne Schneider [ 29/Jan/19 ]

Jakub Skoczen – are you suggesting that the MD contain the "replaces" functionality suggested by Adam Dickmeiss? There is still the use case proposed by Hongwei Ji, that a multi-tenant shared environment could offer multiple implementations of an interface as legitimate alternatives, not as a replacement (also not addressed by Adam Dickmeiss's proposal to have separate module descriptor registries).

Comment by Jakub Skoczen [ 29/Jan/19 ]

John Malconian Wayne Schneider Adam Dickmeiss Hongwei Ji Copy-paste what I wrote on slack:

I think there are two use cases here:
• the module knows that it wants a particular implementation, perhaps because it’s newer or performs better. This is the case for mod-kb-ebsco-java
• service-provider wants to enforce a particular implementation for their hosting (this is more like the CODEX providers scenario)
It seems to me we would need two different features here:
• in the ModuleDescriptor for the module to “ask” for a particular implementation (I think this may be better than the "replaces" Adam proposes because replacing is only one use-case)
• in the /install to “force” a particular implementation for the tenant

Comment by Hongwei Ji [ 29/Jan/19 ]

I see the second feature is very much needed, and it also exists already as folks pointed out. For the first feature, I feel it blurs the line a bit between module and interface. From a practical perspective, feature 2 can do what feature 1 needs.

Comment by Adam Dickmeiss [ 30/Jan/19 ]

Replaces feature added to okapi - OKAPI-661 Closed . This should make it easier to rename modules in the future

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