Skip to content

ADR - Formalize the System/Shared Tenant.

ADR: Formalize the System/Shared Tenant.

Status

  • Proposed
  • Trialing
  • Under review
  • Approved
  • Retired

Context

  • The OSDU Platform has global meta-data, which is vital for the platform's integrity and normal operation and is shared across all tenants. This meta-data is provisioned once the new OSDU instance is created and then remains immutable.
  • It's important to consider that the shared tenant can function not only as a repository for global metadata but also as a standard private tenant, particularly in single-tenant environments. Therefore, any proposed system API changes should not disrupt the existing regular flow, ensuring that system tenants can maintain private tenant-specific configurations without interference.

Problem Statement

In the current approach, we do not have a proper way to distinguish the system tenant from private tenants.

System tenant configured per service, via the environment, for example, https://community.opengroup.org/osdu/platform/system/schema-service/-/blob/master/provider/schema-gc/src/main/resources/application.properties?ref_type=heads#L25

The first created tenant in the OSDU platform by default is used as originating storage for multiple shared data - default system schemes, reference data, and system DAGs.

All the other tenants are forced to consume this data from the first created tenant space. This breaks the tenant data isolation concept for multi-tenant environments and forces core services implementation to "be aware" of the specific case of the first tenant and implement some workarounds etc.

Also, it does not take into account some corner cases like removing the very first tenant from the system.

Proposal

To have a more consistent system and to improve tenant data isolation we propose to formalize a special system tenant at the Partition service API, which will contain all the immutable shared meta-data, like system schemes, system DAGs, and default OPA rego rules.

Decision

  • When a new OSDU instance is created, a system tenant is created for that instance by default along with the first client tenant. Should be configurable, it will be possible to use the same first client tenant as a system tenant if there is no need to create it as a separate tenant. Untitled_Diagram.drawio_30_
  • Move the configuration of the system tenant from services environment variables to the Partition service.
  • Update Partition API accordingly.
    • Partition service should not expose the system tenant in the full partitions list, should be configurable, if the system tenant is used as a private then it should be present in the partition list.
    • Add new endpoints, that would provide only system (shared) configurations.
    • Forbid system tenant management through regular endpoints.
    • Forbid system tenant deletion.

Rationale

Formalizing the System tenant will get us closer to platform standardization.

With updates, it will be possible to reduce resources provided for the system tenant, for example, Elasticsearch, Database instances, etc.

Also, it will give us the ability to align feature flag configurations, which are currently scattered.

It will be possible to move global platform configurations from environment variables to the system tenant.

Consequences

Required code changes:

  • Updates in Core-Common library to use new API (Partition client), in a nonbreaking manner, but highlighting existing flow as deprecated.
  • Updates in consumer services to utilize new capabilities. Schema, Workflow, Feature Flag Service implementation in the Core Common. Again in a nonbreaking manner, allowing to use old approach.
  • A clear approach to update CSP tenant configurations used in the dev environment. Since developers do not have access to CSP Partition configurations it will be helpful to have an approach for such cases. Having versioned bootstrap configurations is preferable.

To enable API:

  • Update Partition configuration to enable system API.
  • Configure system tenant name in Partition configuration, default is system.
  • Configure services that are using system tenant to use API instead of env configuration to determine system tenant (Only after changes are implemented in service).

No changes are required if API is disabled. But we do hope that it won't be hard to adapt as changes can be enabled sequentially without disrupting existing environments.

Edited by Rustam Lotsmanenko (EPAM)