- DBaaS Platform OLM Catalog
DBaaS Platform OLM Catalog would provide set of operators to extend Kubernetes to deliver DBaaS Platform based on it.
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.
Developing operators, creating/developing/maintaining operator bundles.
Creating/Developing DBaaS Platform.
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.
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
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.
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.
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.
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
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.
TBD
TBD
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:
- create their own bundles and images and push them to the operator's registry
- push operator's manifest and metadata to the Kubernetes Community operators repo
- 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")
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
EOFTo 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-bundleexample-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
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
├── .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.yamlcatalog.yaml
Other files are optional, and individual catalog might also include some helpers, test and other yaml files.
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.
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
- new image for every commit in
mainbranchgh.neting.cc/percona/catalog:main - new image after
mainpasses all the testsgh.neting.cc/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:latestandgh.neting.cc/percona/platformx:vX.Y.Z
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
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 olmUse 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:latestSee Catalog images section for images and tags.
[ ] 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.
<package>:<date>-<test coverage>
- :
- :