Verify that Module Descriptor changes are backwards compatible
Description
Environment
None
CSP Request Details
None
CSP Rejection Details
None
Estimation Notes and Assumptions
None
RCA Group Details
None
Potential Workaround
None
defines
Checklist
hideActivity
Show:

Viktor Gema April 11, 2024 at 8:23 AM
The link on the document:

Craig McNally April 9, 2024 at 4:04 PM
Looks like the ModuleDescriptor schema does not allow additional properties:
I think this means OKAPI may reject module descriptors which have fields introduced by Eureka, and we will need to update the schema in OKAPI if we want to be able to merge the module descriptor changes into the mainline for the various modules, e.g mod-search, mod-pubsub, etc.
Done
Details
Details
Assignee

Reporter

Development Team
Eureka
RCA Group
TBD
Story Points
0
Sprint
None
Priority
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created April 3, 2024 at 1:39 PM
Updated May 28, 2024 at 3:14 PM
Resolved April 16, 2024 at 6:03 PM
TestRail: Cases
TestRail: Runs
We need to verify that the customizations we’ve made to module descriptors in scope of Eureka will not break OKAPI. This will allow us to plan incorporation of these changes into the mainline branch of the affected module repositories. This primarily concerns changes related to system/tenant user declaration, but if there are other changes Eureka has made to module descriptors which we’re unsure of, those are in scope here as well.
Depending on how this goes, a formal spike write up may not be required for this. If the changes are found to not be backwards compatible, one or more follow-on stories should be created to address the problem.
NOTE: This is a blocker for the effort to create a snapshot-like environment for Eureka which is (re)created each day from HEAD/master