Skip to content
This repository has been archived by the owner on Oct 10, 2023. It is now read-only.

Latest commit

 

History

History
567 lines (438 loc) · 19.8 KB

dbaas-catalog-design.md

File metadata and controls

567 lines (438 loc) · 19.8 KB
Raw

DBaaS Platform OLM Catalog

Summary

DBaaS Platform OLM Catalog would provide set of operators to extend Kubernetes to deliver DBaaS Platform based on it.

Motivation

Goals

Create and Maintain OLM DBaaS Platform Catalog to provide instrumentation (catalog of operators) to build DBaaS Platform on Kubernetes base. Enable community to develop and extend this catalog.

Non-Goals

Developing operators, creating/developing/maintaining operator bundles.

Creating/Developing DBaaS Platform.

Proposal

Proposal is to create a new catalog of operators that solves one particular problem: DBaaS Platform. The scope of that catalog would be everything related to ability to build DBaaS Platform which includes but not limits to such categories:

  • Cloud Provider
  • Database
  • Logging & Tracing
  • Monitoring

Such catalog will allow to separate different concerns, to have smaller repos/images/systems, to harden security by reducing the scope.

User Stories (Optional)

Story 1

As a SRE I would like to add one catalog and be able to deploy my variant of DBaaS Platform from it.

For example:

  • install DB Server operator
  • install monitoring operator
  • install Database operators that help to manage and operate Databases

Story 2

As a SRE I should be able to install any operator from the catalog and subscribe to updates to be able to have updated versions of operators in my kubernetes cluster.

Story 3

As a SRE I should be able to switch between catalog channels to try the newest versions of database operators to test my upgrade plans to understand the consequences of upgrading and possible downtime on the production environment.

Story 4

As a DBaaS Platform developer I would like to have single catalog to test interoperability of different operators, their custom resources. Thus to be able to release tested and validated catalog of operators to build DBaaS platform.

Story 5

As a DBaaS platform developer, I should be able to install the newest version of a database operator and run automated tests against it to improve the overall quality of the operator's interoperability

Story 6

As a DBaaS QA, I should be able to install any version of a database operator or a set of database operators in order to test the update/upgrade scenarios and the operator's interoperability.

Notes/Constraints/Caveats (Optional)

TBD

Risks and Mitigations

TBD

Design Details

OLM Catalogs is the way to distribute set of operator that can be installed onto a cluster via OLM.

This Catalog will be based on Veneers, specifically on semver veneer as an approach to simplifying interacting with FBCs (File-Based Catalogs).

Please see Semver Veneer specification.

Catalog should have number of different testing layers to test:

  • sanity of individual operator veneer/catalog
  • integration test of new catalog with updated operator
  • interoperability of the new operator version with other operators that could be affected
  • e2e test for the platform configurations

This repo provides only Catalog, OLM operator bundles and their images are provided and maintained by individual operators.

There could be number of bundle sources for this DBaaS Platform Catalog. Operator owners could:

  1. create their own bundles and images and push them to the operator's registry
  2. push operator's manifest and metadata to the Kubernetes Community operators repo
  3. use hybrid approach, when RC and testing bundles are created in operator's registry and release one both in operator's and community one

When in a first case Operator owners are responsible to create CI/CD pipelines to build and publish bundle images, in a second case Kubernetes Community does that.

C4Context
    title Operator bundle Workflow for DBaaS Platform Catalog

    Person(OperatorOwnerA, "Operator A")
    Container(ImageRegA, "Operator A image Registry")

    System_Boundary(c1, "DBaaS Platform Catalog") {
        Container(DBaaSPlatformCatalog, "DBaaS Platform Catalog Image")
    }

    Container(RegOperatorHubIO, "Operator B in OperatorHub.io Registry")
    Person(OperatorHubIO, "Operator B")

    Rel_D(OperatorOwnerA, ImageRegA, "Creates bundle", "image")
    Rel_D(ImageRegA, DBaaSPlatformCatalog, "Updates image in the catalog")

    Rel_U(RegOperatorHubIO, DBaaSPlatformCatalog, "Updates image in the catalog", "image")
    Rel_U(OperatorHubIO, RegOperatorHubIO, "Creates bundle", "image")
Loading

Add or Update operator catalog

To add new operator - create veneer.yaml:

mkdir catalog/percona-xtradb-cluster-operator ; cd catalog/percona-xtradb-cluster-operator
cat << EOF >> veneer.yaml
Schema: olm.semver
GenerateMajorChannels: true
GenerateMinorChannels: false
Stable:
  Bundles:
  - Image: quay.io/operatorhubio/percona-xtradb-cluster-operator:v1.10.0
EOF

To update operator - add new bundle to the existing veneer:

Schema: olm.semver
GenerateMajorChannels: true
GenerateMinorChannels: false
Stable:
  Bundles:
  - Image: quay.io/operatorhubio/percona-xtradb-cluster-operator:v1.10.0
  - Image: docker.io/percona/percona-xtradb-cluster-operator:v1.11.0-bundle

example-operator Use channel names Candidate, Fast, and Stable as stated in Veneer specification.

Generate operator catalog:

opm alpha render-veneer semver -o yaml < veneer.yaml > catalog.yaml
opm validate .

Create PR and get it merged (veener.yaml and catalog.yaml).

%%{init: {'securityLevel': 'strict', 'theme':'forest'}}%%
sequenceDiagram
autonumber
participant OperatorOwner
participant Catalog
participant GHAction
participant ImageRepo
OperatorOwner--xCatalog: fork repo
OperatorOwner--xCatalog: adjust CI
OperatorOwner--xCatalog: push updates to remote
activate OperatorOwner
activate Catalog
Catalog->>+GHAction: testing
activate GHAction
GHAction->>GHAction: run sanity, integration, interoperability tests 
GHAction->>+ Catalog: test results
activate OperatorOwner
activate Catalog
OperatorOwner->>+Catalog: Approves PR, merges (auto-merge trivial case)
Catalog->>+GHAction: Integrate contribution to catalog
activate GHAction
GHAction->>GHAction: validate contribution's Operator Author 
GHAction->>GHAction: generate image containing updated catalog
GHAction->>GHAction: validate catalog in image
GHAction->>GHAction: run e2e tests
GHAction->>+ ImageRepo: push catalog image to repo
activate ImageRepo
deactivate ImageRepo
deactivate GHAction
deactivate Catalog
deactivate OperatorOwner
Loading

GH CI/CD pipeline would create new image and push it to the registry:

podman build . -f dbaas-catalog.Dockerfile -t ghcr.io/percona/dbaas-catalog:main
podman push ghcr.io/percona/dbaas-catalog:main

Questions:

  • could it be links to the veneers in other GH repos instead (submodules)?

Catalog tree

catalog
├── .indexignore          (to make `opm validate` ignore README.md)
├── README.md
├── OperatorA
│   ├── .indexignore      (to make `opm validate` ignore OWNERS)
│   ├── OWNERS            (owners of the operator catalog to review PRs)
│   ├── veneer.yaml       (Veneer to build catalog.yaml)
│   └── catalog.yaml
└── OperatorB
    ├── .indexignore
    ├── OWNERS
    ├── veneer.yaml
    └── catalog.yaml

Required files are:

  • veneer.yaml
  • catalog.yaml

Other files are optional, and individual catalog might also include some helpers, test and other yaml files.

Create a new platform

Platform is a variant of a community (main branch) catalog that might have additional quality gates and/or different set or versions of operators.

Platforms could be created in 2 ways:

  • adding new platforms tests and releases into main repo
  • forking a repo and maintaining same workflow but with additional tests and releases

In the main repo there probably would be a limited number of reference platforms (in a stable branches) as the test matrix and test resources needed could be quite big.

Git branching

All development happens in the main branch and Platform branches (or forks) are created for more advance testing and additional stability.

Platform branches (or forks) could also have less operators included, or include some custom ones that for some reason can't be landed into the main.

Platform branches should merge with main as often as possible and new tags trigger rebuild of latest platform catalog image.

%%{init: { 'logLevel': 'debug', 'theme': 'base' } }%%
gitGraph
       commit
       commit
       commit tag: "v1.0.0"
       commit
       branch PlatformX
       checkout PlatformX
       commit tag: "platformX/v1.0.0"
       checkout main
       commit
       commit id: "fix_1"
       commit tag: "v1.1.0"
       checkout PlatformX
       cherry-pick id: "fix_1"
       commit tag: "platformX/v1.0.1"
       checkout main
       commit
       commit
       checkout PlatformX
       merge main
       commit tag: "platformX/v1.1.0"
       checkout main
       commit
       branch PlatformY
       checkout PlatformY
       commit tag: "platformY/v1.0.0"
       checkout main
       commit
       commit
       commit tag: "v2.0.0"
       commit
       checkout PlatformY
       merge main
       commit tag: "platformY/v1.1.0"
       checkout PlatformX
       merge main
       commit tag: "platformX/v2.0.0"
       checkout main
       commit
       commit
Loading

Catalog images

  • new image for every commit in main branch github.com/percona/catalog:main
  • new image after main passes all the tests github.com/percona/catalog:latest
  • new image for platform branches with every commit github.com/percona/platformx:main
  • new image for every tag on platform branch github.com/percona/platformx:latest and github.com/percona/platformx:vX.Y.Z

Candidate Channel

Candiate channel could be used for CI to test on going operator development and integration with other components:

  • operator candidates with other released operators
  • operators candidates with other operator candidates

Failing CI pipelines in this case could be indicators but still could land into the catalog if basic tests are passing:

  • sanity tests
  • image tests

Use Catalog

To use latest upstream community DBaaS Platform Catalog:

kubectl apply -f https://raw.githubusercontent.com/percona/dbaas-catalog/main/dbaas-catalog.yaml
kubectl get catalogsource -n olm
kubectl get packagemanifest -n olm

Use needed image and tag in a standard catalog source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: dbaas-catalog
  namespace: olm
spec:
  sourceType: grpc
  image: repo_url/catalog:latest

See Catalog images section for images and tags.

Test Plan

[ ] I/we understand the owners of the involved components may require updates to existing tests to make this code solid enough prior to committing the changes necessary to implement this enhancement.

Unit tests
  • <package>: <date> - <test coverage>
Integration tests
  • :
e2e tests
  • :

Upgrade / Downgrade Strategy

Version Skew Strategy

Implementation History

Drawbacks

Alternatives

Infrastructure Needed (Optional)