[FOLIO-574] ModuleDescriptor Implementation Version Created: 25/Apr/17 Updated: 12/Nov/18 Resolved: 15/May/17 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Adam Dickmeiss | Assignee: | Adam Dickmeiss |
| Resolution: | Done | Votes: | 0 |
| Labels: | dublin, sprint13, sprint14 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 2 hours, 30 minutes | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
So far, the semantics of id of the ModuleDescriptor has been vaguely described. |
| Comments |
| Comment by Adam Dickmeiss [ 25/Apr/17 ] |
|
There no version in the ModuleDescriptor of Okapi except for interfaces. As far as Okapi proxy is concerned, should will load balance over a set of modules (deployed) with identical module IDs. If we want to upgrade a tenant to use a newer version of a module we must use another module ID. We could introduce an implementation version – say at same level as id and name, but it would complicate matters because, when we deploy we identify with module ID and that is no longer unique (for multiple versions). So I suggest we make the module ID unique by including a version in it. Using a format such as [^-]+-[0-9]+(.[0-9]+)* that is : one or more characters followed by a dash followed by numerical parts with period as separator. Perhaps we should allow more tricks than that. For example, the very annoying convention of -snapsnot in Maven makes the comparison somewhat difficult, because 1.3.0-snapshot is EARLIER than 1.3.0. Perhaps, just to make them identical we can allow suffix -SNAPSHOT to be "one less than". ONe can also use serial number as used in DNS zones.. But the bottom line is that Okapi does not, normally, know what it means, but when we select a module from many , we would like them to be sorted somehow. It is of course an extra burden to update this entry for a new release. Perhaps we could generate from the native package tool at hand, for example, by generating it from version in pom.xml. |
| Comment by Adam Dickmeiss [ 15/May/17 ] |
|
There seem to be consensus about this |
| Comment by Adam Dickmeiss [ 20/Jun/17 ] |
|
All related issues with this , eg
|
| Comment by Marc Johnson [ 20/Jun/17 ] |
|
I haven't forgotten about these, when I do a release I tend to ask John Malconian and Wayne Schneider if that release would be a good time to make this change (as I don't want it to stop these versions of the module from being deployed into our various black boxes or demo sites). As far as I'm aware we don't yet have a module which has converted to these new scheme. |
| Comment by Wayne Schneider [ 20/Jun/17 ] |
|
What is needed is a convention that all backend developers agree to follow. I would propose that the module id be the artifactId from the pom.xml with the version (also from the pom) – that way it's the same in both places, might be easier to maintain. So, for example `mod-users-12.0.1-SNAPSHOT`. In addition, the Docker image name generated by CI should match the artifactId. Finally, artifactIds should be a little more conventional – we have "mod-users" but "circulation-storage" – should the artifactId match the GitHub project name? Adam Dickmeiss, Jakub Skoczen – can this go on the agenda for the 27 June backend roundup meeting, with John Malconian and I there to discuss, so that we can get an implementation plan in place for all 10 modules included in the current full-stack system? |
| Comment by John Malconian [ 21/Jun/17 ] |
|
With regards to snapshot artifact versions I was intending to append a build number after -SNAPSHOT so that we actually know what iteration of a snapshot is deployed. For example, mod-users-12.0.1-SNAPSHOT.77. This is currently in place for UI modules but not backend modules. The build number suffix is not part of the POM obviously. So I don't know for sure how this impacts things. Module Descriptors are not treated as build artifacts, but perhaps they should be. If we do treat them as artifacts, we'd have to distribute those artifacts to some sort of other repository (and not alongside the project source. The advantage would be that the module IDs can be updated as part of an automated build process. As far as creating build artifacts like Docker images with the same name specified by artifactId, we don't do this currently, but we can, if it helps. It will involve a lot of name changes to Docker repositories on Docker Hub and re-configuring build jobs in Jenkins to use the new convention. So we will need to coordinate such a change carefully. (I've been naming Docker images after the github project name.) |