Spike - Revisit platform descriptors

Spike Overview

JIRA ID: EUREKA-285 Revisit platform descriptors

Objective: In Eureka, applications are composed of modules, defined by application descriptors. These applications, in turn, compose platforms represented by platform descriptors. While the concept of platform descriptors is not new, we have yet to design or implement a concrete solution.

For the legacy platform, we use an install.json file, which essentially lists modules and their versions. In Eureka, we aim to work with applications, so we've been providing DevOps with informal lists of applications, their versions, and other components (mgr-*, Keycloak, Kong, etc.). Our goal is to formalize this into a versioned platform descriptor that includes all relevant component and infrastructure versions.

Several additional concepts are also relevant here:

• Virtual applications: These are applications not composed of modules but rather infrastructure components. While some aspects may have been included in platform schema examples, we've never formalized this concept.

• Platform inheritance: This introduces the idea of "base" and "extended" platforms. Extended platforms can inherit from a base platform, allowing us to create a foundational platform with the essential components for a minimal, functional system. Multiple extended platforms (LSP, ERM, Locate, etc.) can then build upon this shared base.

Business Drivers:

To formalize the release process for the Eureka platform by clearly defining which applications and environment components will be deployed to the cluster, we need to establish the structure of the platform descriptor, detailing its format and the necessary components for the DevOps team.

Workshop with DevOps to determine what information is required, including:

• A list of applications and their versions

• For infrastructure components, we need to provide a range of versions that can be used. The implementation should include a list of supported versions. For example, in the Sunflower release, we can support multiple versions of PostgreSQL

• Key/value properties allow us to extend the platform descriptor with additional information in the future without requiring code changes.

• Platform name

• Version number

• Description (if needed)

• Manager service versions

• The sidecar version does not need to be managed at the platform level, as it will be included in the application descriptor. However, as discussed, the sidecar should be part of the platform descriptor within the base platform.

• Infrastructure versions

• The Keycloak version should be managed as the folio-keycloak application, as we use a custom build and do not use the standard version.

• The Kong version should be managed as the folio-kong application, as we use a custom build

• Kafka version

What else should be considered?

Platform descriptor example: