Problem:

Currently, SBO has different strategies to enable services to be bindable, e.g., annotations, out-of-the-box, and provisioned services. Currently all of this are Operator Based services that are able to define their own CRDs. There are many other sources of services from managed services running on external OCP clusters, to the countless services running today on Public Cloud platforms. There is a need the define an approach that will abstract away from the sources of service but focus on what is common between them: Protocols, connection strings, credentials and endpoint.

Goal:

The goal of this epic is to define a consistent way that we can represent Service Endpoint Definitions (SEDs) independently of the source of the service. The first attempt will use Helm Charts that will define the SED layer and can potentially be used as sub-charts of other helm charts that packages services. This will be a stepping stone to unleash the potential of SBO

Why is it important?

We need to focus on the low hanging fruit efforts that enable all service types: Operators, Helm Charts, External Services.

Use cases

• As a workload developer, I would like to be able to bind to any services I need regardless of location, provider and packaging, so that I can focus on workload development and not on the details of the service implementation.
• As a workload developer, I would like to be able to bind to the same service in different environments (dev, stage, prod), even if my environments use different providers, packaging mechanism, and location.
• As an OCP administrator, I would like to be able to define SEDs, so that workload developers do not need to worry about details about the services they need to use.
• As a service provider, I will like to be able to define my SED as helm charts, so that OCP administrators and Developer can easily use without know the details about how my service is implemented.

Acceptance criteria

• A PostgreSQL service can be represented by a SED chart in OpenShift and installing will allow me to connect to any PostgreSQL DB regardless of location and source. Multiple sources can be used for testing (Helm Charts, Operators and Even public cloud DBaaS).
• A MySQL service can be represented by a SED chart in OpenShift and installing will allow me to connect to any MySQL DB regardless of location and source. Multiple sources can be used for testing (Helm Charts, Operators and Even public cloud DBaaS).
• An ElasticSearch service can be represented by a SED chart in OpenShift and installing will allow me to connect to any ElasticSearch Instance regardless of location and source. Multiple sources can be used for testing (Helm Charts, Operators and Even public cloud ElasticSearch instances like AWS OpenSearch).
• A Redis service can be represented by a SED chart in OpenShift and installing will allow me to connect to any Redis Instance regardless of location and source. Multiple sources can be used for testing (Helm Charts, Operators and Even public cloud Redis instances like AWS ElasticCache).
• ODC can discover SEDs and make them available for binding using SBO
• There is documentation provided with above SEDs as samples so that services providers can defined their own SEDs
• There is documentation provided with instructions on how to include SEDs charts as sub-charts of services providers that package their services as charts.

Dependencies (External/Internal)

Design Artifacts

Instead of focusing on service that come from charts vs services that come from operators or even services that come from public cloud providers we will first focus on service endpoint definitions (SED). These SEDs will be represented as a secret that is compliant with the SBO spec. The idea here will be to create a set of charts that will contain the following:

1. A secret template representing the SED including endpoint and authentication credentials.
2. A values spec json describing the fields in the secret. This will make it easy to create dynamic forms when deploying on ODC
3. Values file with parameters that can be changed at installed time
4. Charts file with appropriate annotations making it compliant with our certification flow
5. A helm test that can be run to verify that the Service represented by the SED is indeed healthy

These chart defining the SEDs will be sent for certification following the Red Hat certification path described here. However, the charts source will be developed under the SBO GitHub repo so that we can collaborate there first before sending for certification. Once the charts are certified they will be available for installation on all OCP versions 4.8 or older making it easy for a developer or an administrator to deploy and test a SED.

As also indicated on the SBO spec, direct secret binding is also supported, and SBO already implements. The motivations for this approach is based on the fact that regardless of the source of the service or the level of interest from the service providers it is possible to create a SED that represents the service and the SED itself is bindable object. See the SBO Connecting Service to Workloads diagram for a visual representations of SEDs and their relationship to service and workloads.

Exploration

Note