[OKAPI-661] Test effect of module renaming on Okapi dep resolution Created: 27/Sep/18  Updated: 04/May/22  Resolved: 30/Jan/19

Status: Closed
Project: Okapi
Components: None
Affects versions: 2.17.4
Fix versions: 2.24.0

Type: Task Priority: P3
Reporter: Wayne Schneider Assignee: Adam Dickmeiss
Resolution: Done Votes: 0
Labels: ci, core, sprint47, sprint48
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to OKAPI-665 Report conflict when multiple modules... Closed
relates to FOLIO-1727 SPIKE: select particular implementati... Open
relates to FOLIO-1938 Create organizations github repositor... Closed
relates to FOLIO-1753 Replace mod-kb-ebsco with mod-kb-ebsc... Closed
relates to OKAPI-648 Okapi dependency resolution omitting ... Closed
relates to MODINVSTOR-900 Tell okapi that this module replaces ... Closed
Sprint:
Development Team: Core: Platform

 Description   

mod-finance has been renamed to mod-finance-storage. How will Okapi resolve dependencies with multiple modules that support the same interfaces, and what effect will that have on the snapshot CI build?



 Comments   
Comment by Wayne Schneider [ 27/Sep/18 ]

On a clean Okapi install, posted MDs for mod-finance-1.0.1-SNAPSHOT.28 and mod-finance-storage-1.0.1-SNAPSHOT.1 with the same content except for the module ID, and an MD for folio_finance-1.0.100017 which requires those interfaces. A request to the tenant's install endpoint to enable folio_finance resulted in:

[
    {
        "id": "mod-finance-storage-1.0.1-SNAPSHOT.1",
        "action": "enable"
    },
    {
        "id": "folio_finance-1.0.100017",
        "action": "enable"
    }
]

Okapi log shows:

2018-09-27 19:39:36,303 INFO  ProxyContext         700577/proxy REQ 10.0.2.2:51294 supertenant POST /_/proxy/tenants/test/install okapi-2.17.4
2018-09-27 19:39:36,308 INFO  TenantManager        mod available: folio_finance-1.0.100017
2018-09-27 19:39:36,308 INFO  TenantManager        mod available: mod-finance-1.0.1-SNAPSHOT.28
2018-09-27 19:39:36,308 INFO  TenantManager        mod available: mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,308 INFO  TenantManager        mod available: okapi-2.17.4
2018-09-27 19:39:36,309 INFO  TenantManager        outer loop i=0 tml.size=1
2018-09-27 19:39:36,309 INFO  TenantManager        getNextTM: loop id=folio_finance-1.0.100017 action=enable
2018-09-27 19:39:36,309 INFO  TenantManager        getNextMT: return tm for action=enable
2018-09-27 19:39:36,309 INFO  ModuleManager        addModuleDependencies folio_finance-1.0.100017
2018-09-27 19:39:36,310 INFO  ModuleManager        addModuleDependencies mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,310 INFO  ModuleManager        Dependency OK already enabled id=mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,311 INFO  ModuleManager        Dependency OK already enabled id=mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,312 INFO  ModuleManager        Dependency OK already enabled id=mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,312 INFO  ModuleManager        Dependency OK already enabled id=mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,313 INFO  ModuleManager        Dependency OK already enabled id=mod-finance-storage-1.0.1-SNAPSHOT.1
2018-09-27 19:39:36,313 INFO  TenantManager        outer loop i=1 tml.size=2
2018-09-27 19:39:36,314 INFO  TenantManager        getNextTM: loop id=mod-finance-storage-1.0.1-SNAPSHOT.1 action=enable
2018-09-27 19:39:36,314 INFO  TenantManager        getNextTM: loop id=folio_finance-1.0.100017 action=enable
2018-09-27 19:39:36,314 INFO  TenantManager        getNextTM done null
2018-09-27 19:39:36,314 INFO  TenantManager        installModules.returning OK
2018-09-27 19:39:36,315 INFO  InternalModule       installUpgradeModules returns:
[ {
  "id" : "mod-finance-storage-1.0.1-SNAPSHOT.1",
  "action" : "enable"
}, {
  "id" : "folio_finance-1.0.100017",
  "action" : "enable"
} ]
2018-09-27 19:39:36,316 INFO  ProxyContext         700577/proxy RES 200 12851us okapi-2.17.4 /_/proxy/tenants/test/install..

This happens to be what we want, but I'm not sure why Okapi picked mod-finance-storage over mod-finance. Adam Dickmeiss, any ideas?

Comment by Wayne Schneider [ 04/Oct/18 ]

I moved this issue into the Okapi project and unassigned myself. I'm not sure it's a bug, or if it's just undefined behavior. Feel free to close out if it doesn't seem useful to investigate. With respect to our immediate issue, Okapi seems to be (accidentally?) doing what we want it to do (picking mod-finance-storage over mod-finance to resolve the dependencies expressed by folio_finance).

Comment by Adam Dickmeiss [ 09/Oct/18 ]

If you enable only folio_finance, you are right that it's currently undefined what it does. I think it should make an error in this – because there are multiple modules providing the interface.

However, if you along with folio_finance enable the one you really want it should work fine.. Ie pick what you choose. At least that's what I see when I make a unit test for this.

Comment by Wayne Schneider [ 09/Oct/18 ]

Yes, that does make sense. I wonder if it would be helpful to return a structured error, so that the user can know what to do when they run into this situation?

It would make the task of doing a "top-down" installation a little more challenging, since you may need to do it in multiple passes (that is, post your install list, discover which dependencies are met by multiple implementations, then re-post with the ambiguities resolved). Or would there be a better way to do this?

Maybe we should support some form of disambiguation in the requires key of the module descriptor? Because we are depending on interfaces rather than implementations, it's not quite as straightforward as what you can do with apt's Depends (e.g. A | B to satisfy the dep with A or B, trying to install first A and then B if neither is currently installed).

Comment by Adam Dickmeiss [ 10/Oct/18 ]

Here's how to deal with renaming a module.

0. Specify it in install. The install was exactly meant for you to choose what modules you want to use .. especially when there are multiple modules offering the same interface.. Not much yet.. But it's like choosing your email-agent of choice in Debian ..

1. Remove the old module from the repository entirely.. If the interface is unchanged and it really is the same implementation why keep it?

2. Change the interface provided/required.. If the major interface change or the interface is renamed, it is essentially like linking a new module .. This requires both consumer and producers of the module.. So this is actually not very optimal.

3 (NOT POSSIBLE YET). Add some module require thingy.. But that requires all consumers to depend on a particular module rather than an interface.. Thus all consumers must be updated. It violates the whole interface dependency thingy.. What if you want to rename mod-codex-mux??

4 (NOT POSSIBLE YET). Add a new field "replaces": ["mod-1", "mod-2] .. field in the module descriptor.. This is like replaces in Debian and ONLY requires the producer to make a change.. And clearly, that is less work than requiring consumers to do the same. This would work for codex or login too with multiple interfaces..

If we foresee more renames in the future solution 4 could be implemented. It is relatively easy to do.

Comment by Adam Dickmeiss [ 11/Oct/18 ]

I'll keep this open for now. . Opened OKAPI-665 Closed for at least not choosing a "random" module when multiple modules satisfy a dependency.

Comment by Adam Dickmeiss [ 30/Jan/19 ]

Implemented (SOLUTION 4 before)

{
 "id" : "new-module-1.2.0"
 "replaces": [ "old-module" ]
},
..
Generated at Thu Feb 08 23:14:05 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.