Removal of CSPs Modules and Main Class Reassignment to the Core
ADR: Remove provider modules from the CRS Conversion.
Simplify the Development and maintenance of the CRS Conversion service by removing CSP modules.
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
The CRS-Conversion service operates independently of cloud-specific technologies, conducting all calculations at runtime and storing necessary data within bundled service files. However, within the OSDU Community, four distinct artifacts are generated, each designated per CSP, tested, maintained, and patched for vulnerabilities separately.
Decision
- Delete provider modules.
- Move the main class to the CRS Conversion Core.
- Merge and move Spring Security Configurations to the CRS Conversion Core. These configurations are used for service request handling and are independent of cloud technologies. Despite minimal differences, these configurations are dispersed across CSPs, leading to inconsistency in handling and increasing the risk of service misconfiguration.
- Merge and move properties files to the CRS Conversion Core.
- Determine the necessity of incorporating CSP libraries as pluggable utilities. These libraries could serve as background utilities for tasks such as log formatting and trace capture. If utilized within the CRS Catalog, establish a method to independently integrate them. This approach could subsequently be adopted for the Community Implementation.
Rationale
The existing setup of the CRS Conversion multiplies the effort needed for maintenance and release processes without visible benefits. This service contains minimal cloud-specific code, primarily limited to occasional utilities from libraries. By excluding CSP modules, the OSDU Community can offer sustainable, thoroughly tested artifacts for the CRS Catalog, significantly reducing the necessary effort.
Consequences
- Deletion of provider modules.
- Minor CI/CD refactoring to transition to a single artifact (JAR file) from four different artifacts.
- (Optional, pending agreement) Implement a solution for abstracting utility libraries used by CSPs, which could be beneficial in the future.
Tradeoff Analysis
Beyond defining an abstraction mechanism for CSP utility libraries, the proposal aims to decrease the effort needed for support, releases, and vulnerability management. But if abstraction for libraries is needed it definitely should not introduce more complexity, as it would contradict the main goal of this ADR.
Alternatives and implications
- Introducing the Core Plus module during the Community Implementation phase. Similar to existing CSP modules, it would be a shallow module. However, introducing custom utilities might pose complexities. On the other hand, it won't be hard to create the same shallow modules elsewhere, but Community OSDU is moving towards maintaining only a single version of the platform.
- Alternatively, we could include the main class, properties, and security configs in the Core, making those components optional without disrupting existing CSP providers.