Service Catalog
Overview
The Service Catalog is a grouping of reusable, integrated services from all Service Brokers registered in Kyma. Its purpose is to provide an easy way for Kyma users to access services that the Service Brokers manage and use them in their applications.
Due to the fact that Kyma runs on Kubernetes, you can easily instantiate a service that a third party provides and maintains, such as a database. You can consume it from Kyma without extensive knowledge about the clustering of such a datastore service and the responsibility for its upgrades and maintenance. You can also easily provision an instance of the software offering that a Service Broker registered in Kyma exposes, and bind it to an application running in the Kyma cluster.
You can perform the following operations in the Service Catalog:
- Expose the consumable services by listing them with all the details, including the documentation and the consumption plans.
- Consume the services by provisioning them in a given Namespace.
- Bind the services to the applications through Secrets.
Architecture
The diagram and steps describe the Service Catalog workflow and the roles of specific cluster and Namespace-wide resources in this process:
The Kyma installation results in the registration of the default Service Brokers in the Kyma cluster. The Kyma administrator can manually register other ClusterServiceBrokers in the Kyma cluster. The Kyma user can also register a Service Broker in a given Namespace.
Inside the cluster, each ClusterServiceBroker exposes services that are ClusterServiceClasses in their different variations called ClusterServicePlans. Similarly, the ServiceBroker registered in a given Namespace exposes ServiceClasses and ServicePlans only in this specific Namespace.
In the Console UI or CLI, the Kyma user lists all exposed cluster-wide and Namespace-specific services and requests to create instances of those services in the Namespace.
The Kyma user creates bindings to the ServiceInstances to allow the given applications to access the provisioned services.
Resources
This document includes an overview of resources that the Kyma Service Catalog provides.
NOTE: The "Cluster" prefix in front of resources means they are cluster-wide. Resources without that prefix refer to the Namespace scope.
ClusterServiceBroker is an endpoint for a set of managed services that a third party offers and maintains.
ClusterServiceClass is a managed service exposed by a given ClusterServiceBroker. When a cluster administrator registers a new Service Broker in the Service Catalog, the Service Catalog controller obtains new services exposed by the Service Broker and renders them in the cluster as ClusterServiceClasses. A ClusterServiceClass is synonymous with a service in the Service Catalog.
ClusterServicePlan is a variation of a ClusterServiceClass that offers different levels of quality, configuration options, and the cost of a given service. Contrary to the ClusterServiceClass, which is purely descriptive, the ClusterServicePlan provides technical information to the ClusterServiceBroker on this part of the service that the ClusterServiceBroker can expose.
ServiceBroker is any Service Broker registered in a given Namespace where it exposes ServiceClasses and ServicePlans that are available only in that Namespace.
ServiceClass is an Namespace-wide representation of a ClusterServiceClass. Similarly to the ClusterServiceClass, it is synonymous with a service in the Service Catalog.
ServicePlan is an Namespace-wide representation of a ClusterServicePlan.
ServiceInstance is a provisioned instance of a ClusterServiceClass to use in one or more cluster applications.
ServiceBinding is a link between a ServiceInstance and an application that cluster users create to request credentials or configuration details for a given ServiceInstance.
Secret is a basic resource to transfer credentials or configuration details that the application uses to consume a ServiceInstance. The service binding process leads to the creation of a Secret.
ServiceBindingUsage is a Kyma custom resource that allows the ServiceBindingUsage controller to inject Secrets into a given application.
UsageKind is a Kyma custom resource that defines which resources can be bound with the ServiceBinding and how to bind them.
Add a service to the Catalog
In general, the Service Catalog can expose a service from any Service Broker that is registered in Kyma in accordance with the Open Service Broker API specification.
The Kyma Service Catalog is currently integrated with the following Service Brokers:
- Azure Broker
- Application Broker
- Helm Broker (experimental)
- GCP Broker
For details on how to register a sample Service Broker, see the Service Brokers tutorial.
NOTE: The Service Catalog has the Istio sidecar injected. To enable the communication between the Service Catalog and Service Brokers, either inject Istio sidecar into all brokers or disable mutual TLS authentication.
Provisioning and binding
Provisioning a service means creating an instance of a service. When you consume a specific ClusterServiceClass or a ServiceClass, and the system provisions a ServiceInstance, you need credentials for this service. To obtain credentials, create a ServiceBinding resource using the Service Catalog API. One instance can have numerous bindings to use in the application. When you raise a binding request, the system returns the credentials in the form of a Secret. The system creates a Secret in a given Namespace.
NOTE: The security in Kyma relies on the Kubernetes concept of a Namespace which is a security boundary. If the Secret exists in the Namespace, the administrator can inject it to any Deployment. The Service Broker cannot prevent other applications from consuming a created Secret. Therefore, to ensure a stronger level of isolation and security, use a dedicated Namespace and request separate bindings for each Deployment.
The Secret allows you to run the service successfully. However, a problem appears each time you need to change the definition of the yaml
file in the Deployment to specify the Secrets' usage. The manual process of editing the file is tedious and time-consuming. Kyma handles it by offering a custom resource called ServiceBindingUsage. This custom resource applies the Kubernetes PodPreset resource and allows you to enforce an automated flow in which the Binding Usage Controller injects ServiceBindings into a given Deployment or Function.
Provisioning and binding flow
The diagram shows an overview of interactions between all resources related to Kyma provisioning and binding, and the reverting, deprovisioning, and unbinding operations.
The process of provisioning and binding invokes the creation of three custom resources:
- ServiceInstance
- ServiceBinding
- ServiceBindingUsage
The system allows you to create these custom resources in any order, but within a timeout period.
When you invoke the deprovisioning and unbinding actions, the system deletes all three custom resources. Similar to the creation process dependencies, the system allows you to delete ServiceInstance and ServiceBinding in any order, but within a timeout period. However, before you delete the ServiceBinding, make sure you remove the ServiceBindingUsage first. For more details, see the section on deleting a ServiceBinding.
Provision a service
To provision a service, create a ServiceInstance custom resource. Generally speaking, provisioning is a process in which the Service Broker creates a new instance of a service. The form and scope of this instance depends on the Service Broker.
Create a ServiceBinding
Kyma binding operation consists of two phases:
- The system gathers the information necessary to connect to the ServiceInstance and authenticate it. The Service Catalog handles this phase directly, without the use of any additional Kyma custom resources.
- The system must make the information it collected available to the application. Since the Service Catalog does not provide this functionality, you must create a ServiceBindingUsage custom resource.
NOTE: The system allows you to create the ServiceBinding and ServiceBindingUsage resources at the same time.
Define other types of resources
The UsageKind is a cluster-wide custom resource which allows you to bind a ServiceInstance to any kind of resource. By default, Kyma provides two UsageKinds which enable binding either to a Deployment or a Function. You can add more UsageKinds if you want to bind your ServiceInstance to other types of resources. The UsageKind contains information on how the binding to these custom resources is conducted. The ServiceBindingUsage uses this information to inject Secrets to the application.
Delete a ServiceBinding
Kyma unbinding can be achieved in two ways:
- Delete the ServiceBindingUsage. The Binding Usage Controller deletes the Secret injection, but the Secret itself still exists in the Namespace.
- Delete the ServiceBinding. It deletes the Secret and triggers the deletion of all related ServiceBindingUsages.
Deprovision a service
To deprovision a given service, delete the ServiceInstance custom resource. As part of this operation, the Service Broker deletes any resource created during the provisioning. When the process completes, the service becomes unavailable.
NOTE: You can deprovision a service only if no corresponding ServiceBinding for a given ServiceInstance exists.
Service Catalog backup and restore
In the production setup, the Service Catalog uses the etcd database cluster which is defined in the Service Catalog etcd-stateful
sub-chart. The etcd backup operator executes the backup procedure.
Backup
To execute the backup process, set the following values in the core
chart:
Property name | Description |
---|---|
global.etcdBackup.enabled | If set to true , the etcd-operator chart and the Service Catalog backup sub-chart install the CronJob which periodically executes the Etcd Backup application. The etcd-operator also creates a Secret with the storage-account and storage-key keys. For more information on how to configure the backup CronJob, see the Etcd Backup documentation. |
global.etcdBackup.containerName | The Azure Blob Storage (ABS) container to store the backup. |
etcd-operator.backupOperator.abs.storageAccount | The name of the storage account for the ABS. It stores the value for the storage-account Secret key. |
etcd-operator.backupOperator.abs.storageKey | The key value of the storage account for the ABS. It stores the value for the storage-key Secret key. |
NOTE: If you set the storageAccount, storageKey, and containerName properties, the global.etcdBackup.enabled must be set to
true
.
Restore
Follow these steps to restore the etcd cluster from the existing backup.
Export the ABS_PATH environment variable with the path to the last successful backup file.
export ABS_PATH=$(kubectl get cm -n kyma-system sc-recorded-etcd-backup-data -o=jsonpath='{.data.abs-backup-file-path-from-last-success}') export BACKUP_FILE_NAME=etcd.backup
Download the backup to the local workstation using the portal or Azure CLI. Set the downloaded file path:
export BACKUP_FILE_NAME=/path/to/downloaded/file
Copy the backup file to every running Pod of the StatefulSet.
for i in {0..2}; do kubectl cp ./$BACKUP_FILE_NAME kyma-system/service-catalog-etcd-stateful-$i:/$BACKUP_FILE_NAME done
Restore the backup on every Pod of the StatefulSet.
for i in {0..2}; do remoteCommand="etcdctl snapshot restore /$BACKUP_FILE_NAME " remoteCommand+="--name service-catalog-etcd-stateful-$i --initial-cluster " remoteCommand+="service-catalog-etcd-stateful-0=https://service-catalog-etcd-stateful-0.service-catalog-etcd-stateful.kyma-system.svc.cluster.local:2380," remoteCommand+="service-catalog-etcd-stateful-1=https://service-catalog-etcd-stateful-1.service-catalog-etcd-stateful.kyma-system.svc.cluster.local:2380," remoteCommand+="service-catalog-etcd-stateful-2=https://service-catalog-etcd-stateful-2.service-catalog-etcd-stateful.kyma-system.svc.cluster.local:2380 " remoteCommand+="--initial-cluster-token etcd-cluster-1 " remoteCommand+="--initial-advertise-peer-urls https://service-catalog-etcd-stateful-$i.service-catalog-etcd-stateful.kyma-system.svc.cluster.local:2380" kubectl exec service-catalog-etcd-stateful-$i -n kyma-system -- sh -c "rm -rf service-catalog-etcd-stateful-$i.etcd" kubectl exec service-catalog-etcd-stateful-$i -n kyma-system -- sh -c "rm -rf /var/run/etcd/backup.etcd" kubectl exec service-catalog-etcd-stateful-$i -n kyma-system -- sh -c "$remoteCommand" kubectl exec service-catalog-etcd-stateful-$i -n kyma-system -- sh -c "mv -f service-catalog-etcd-stateful-$i.etcd /var/run/etcd/backup.etcd" kubectl exec service-catalog-etcd-stateful-$i -n kyma-system -- sh -c "rm $BACKUP_FILE_NAME" done
Delete old Pods.
kubectl delete pod service-catalog-etcd-stateful-0 service-catalog-etcd-stateful-1 service-catalog-etcd-stateful-2 -n kyma-system
ServiceBindingUsage
The servicebindingusages.servicecatalog.kyma-project.io
CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to inject Secrets to the application. To get the up-to-date CRD and show the output in the yaml
format, run this command:
kubectl get crd servicebindingusages.servicecatalog.kyma-project.io -o yaml
Sample custom resource
This is a sample resource in which the ServiceBindingUsage injects a Secret associated with the redis-instance-binding
ServiceBinding to the redis-client
Deployment in the production
Namespace. This example has the conditions.status field set to true
, which means that the ServiceBinding injection is successful. If this field is set to false
, the message and reason fields appear.
apiVersion: servicecatalog.kyma-project.io/v1alpha1
kind: ServiceBindingUsage
metadata:
name: redis-client-binding-usage
namespace: production
"ownerReferences": [
{
"apiVersion": "servicecatalog.k8s.io/v1beta1",
"kind": "ServiceBinding",
"name": "redis-instance-binding",
"uid": "65cc140a-db6a-11e8-abe7-0242ac110023"
}
],
spec:
serviceBindingRef:
name: redis-instance-binding
usedBy:
kind: deployment
name: redis-client
parameters:
envPrefix:
name: "pico-bello"
status:
conditions:
- lastTransitionTime: 2018-06-26T10:52:05Z
lastUpdateTime: 2018-06-26T10:52:05Z
status: "True"
type: Ready
Custom resource parameters
This table lists all the possible parameters of a given resource together with their descriptions:
Parameter | Mandatory | Description |
---|---|---|
metadata.name | YES | Specifies the name of the CR. |
metadata.namespace | YES | Specifies the Namespace in which the CR is created. |
metadata.ownerReferences | YES | Contains an ownerReference to the binding specified at spec.serviceBindingRef.name field if the binding exist. |
spec.serviceBindingRef.name | YES | Specifies the name of the ServiceBinding. |
spec.usedBy | YES | Specifies the application into which the Secret is injected. |
spec.usedBy.kind | YES | Specifies the name of the UsageKind custom resource. |
spec.usedBy.name | YES | Specifies the name of the application. |
spec.parameters.envPrefix | NO | Defines the prefix of the environment variables that the ServiceBindingUsage injects. The prefixing is disabled by default. |
spec.parameters.envPrefix.name | YES | Specifies the name of the prefix. This field is mandatory if envPrefix is specified. |
status.conditions | NO | Specifies the state of the ServiceBindingUsage. |
status.conditions.lastTransitionTime | NO | Specifies the time when the Binding Usage Controller processes the ServiceBindingUsage for the first time or when the status.conditions.status field changes. |
status.conditions.lastUpdateTime | NO | Specifies the time of the last ServiceBindingUsage condition update. |
status.conditions.status | NO | Specifies whether the status of the status.conditions.type field is True or False . |
status.conditions.type | NO | Defines the type of the condition. The value of this field is always Ready . |
message | NO | Describes in a human-readable way why the ServiceBinding injection has failed. |
reason | NO | Specifies a unique, one-word, CamelCase reason for the condition's last transition. |
Related resources and components
These are the resources related to this CR:
Custom resource | Description |
---|---|
UsageKind | Provides information where to inject Secrets. |
ServiceBinding | Provides Secrets to inject. |
These components use this CR:
Component | Description |
---|---|
Binding Usage Controller | Reacts to every action of creating, updating, or deleting ServiceBindingUsages in all Namespaces, and uses ServiceBindingUsage data to inject binding. |
UI API Layer | Exposes the given CR to the Console UI. It also allows you to create and delete a ServiceBindingUsage. |
UsageKind
The usagekinds.servicecatalog.kyma-project.io
CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define which resources can be bound with the ServiceBinding and how to bind them. To get the up-to-date CRD and show the output in the yaml
format, run this command:
kubectl get crd usagekinds.servicecatalog.kyma-project.io -o yaml
Sample custom resource
This is a sample resource that allows you to bind a given resource with the ServiceBinding. This example has a resource section specified as function
. You can adjust this section to point to any other kind of resource.
apiVersion: servicecatalog.kyma-project.io/v1alpha1
kind: UsageKind
metadata:
name: function
spec:
displayName: Function
resource:
group: kubeless.io
kind: function
version: v1beta1
labelsPath: spec.deployment.spec.template.metadata.labels
Custom resource parameters
This table lists all the possible parameters of a given resource together with their descriptions:
Parameter | Mandatory | Description |
---|---|---|
metadata.name | YES | Specifies the name of the CR. |
spec.displayName | YES | Specifies a human-readable name of the UsageKind. |
spec.resource | YES | Specifies a resource which is bound with the ServiceBinding. The target resource is specified by its resource group, kind, and version. |
spec.resource.group | YES | Specifies the group of the resource. |
spec.resource.kind | YES | Specifies the kind of the resource. |
spec.resource.version | YES | Specifies the version of the resource. |
spec.labelsPath | YES | Specifies a path to the key that contains labels which are later injected into Pods. |
Related resources and components
These are the resources related to this CR:
Custom resource | Description |
---|---|
ServiceBindingUsage | Contains the reference to the UsageKind. |
These components use this CR:
Component | Description |
---|---|
Binding Usage Controller | Uses the UsageKind spec.resource and spec.labelsPath parameters to find a resource and a path to which it should inject Secrets. |
UI API Layer | Exposes the given CR to the Console UI. |
CLI reference
Management of the Service Catalog is based on Kubernetes resources and the custom resources specifically defined for Kyma. Manage all of these resources through kubectl.
Details
This section describes the resource names to use in the kubectl command line, the command syntax, and examples of use.
Resource types
Service Catalog operations use the following resources:
Singular name | Plural name |
---|---|
clusterservicebroker | clusterservicebrokers |
clusterserviceclass | clusterserviceclasses |
clusterserviceplan | clusterserviceplans |
secret | secrets |
servicebinding | servicebindings |
servicebindingusage | servicebindingusages |
servicebroker | servicebrokers |
serviceclass | serviceclasses |
serviceinstance | serviceinstances |
serviceplan | serviceplans |
Syntax
Follow the kubectl
syntax, kubectl {command} {type} {name} {flags}
, where:
- {command} is any command, such as
describe
. - {type} is a resource type, such as
clusterserviceclass
. - {name} is the name of a given resource type. Use {name} to make the command return the details of a given resource.
- {flags} specifies the scope of the information. For example, use flags to define the Namespace from which to get the information.
Examples
The following examples show how to create a ServiceInstance, how to get a list of ClusterServiceClasses and a list of ClusterServiceClasses with human-readable names, a list of ClusterServicePlans, and a list of all ServiceInstances.
- Create a ServiceInstance using the example of the Redis ServiceInstance for the 0.1.38 version of the Service Catalog:
cat <<EOF | kubectl create -f -
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: my-instance
namespace: stage
spec:
clusterServiceClassExternalName: redis
clusterServicePlanExternalName: micro
parameters:
"imagePullPolicy": "Always"
EOF
- Get the list of all ClusterServiceClasses:
kubectl get clusterserviceclasses
Get the list of all ClusterServiceClasses and their human-readable names:
kubectl get clusterserviceclasses -o=custom-columns=NAME:.metadata.name,EXTERNAL NAME:.spec.externalName
Get the list of all ClusterServicePlans and associated ClusterServiceClasses:
kubectl get clusterserviceplans -o=custom-columns=NAME:.metadata.name,EXTERNAL NAME:.spec.externalName,EXTERNAL SERVICE CLASS:.spec.clusterServiceClassRef
- Get the list of all ServiceInstances from all Namespaces:
kubectl get serviceinstances --all-namespaces
Register a broker in the Service Catalog
This Getting Started guide shows how to register a broker in the Service Catalog. The broker can be either a Namespace-scoped ServiceBroker or a cluster-wide ClusterServiceBroker. Follow this guide to register a cluster-wide or Namespace-scoped version of the UPS Broker.
Prerequisites
Steps
Clone the
service-catalog
repository:git clone https://github.com/kubernetes-incubator/service-catalog.git
Run this command to install the chart with the
ups-broker
name in thestage
Namespace:helm install service-catalog/charts/ups-broker --name ups-broker --namespace stage
Register a broker:
- Run this command to register a ClusterServiceBroker:
kubectl create -f service-catalog/contrib/examples/walkthrough/ups-clusterservicebroker.yaml
- To register the UPS Broker as a ServiceBroker in the
stage
Namespace, run:
After you successfully register your ServiceBroker or ClusterServiceBroker, the Service Catalog periodically fetches services from this broker and creates ServiceClasses or ClusterServiceClasses from them.kubectl create -f service-catalog/contrib/examples/walkthrough/ups-servicebroker.yaml -n stage
- Run this command to register a ClusterServiceBroker:
Check the status of your broker:
- To check the status of your ClusterServiceBroker, run:
kubectl get clusterservicebrokers ups-broker -o jsonpath="{.status.conditions}"
To check the status of the ServiceBroker, run:
kubectl get servicebrokers ups-broker -n stage -o jsonpath="{.status.conditions}"
The output looks as follows:
{ "lastTransitionTime": "2018-10-26T12:03:32Z", "message": "Successfully fetched catalog entries from broker.", "reason": "FetchedCatalog", "status": "True", "type": "Ready" }
- To check the status of your ClusterServiceBroker, run:
View Service Classes that this broker provides:
- To check the ClusterServiceClasses, run:
kubectl get clusterserviceclasses
To check the ServiceClasses, run:
kubectl get serviceclasses -n stage
These are the UPS Broker Service Classes:
NAME EXTERNAL NAME 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 user-provided-service 5f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 user-provided-service-single-plan 8a6229d4-239e-4790-ba1f-8367004d0473 user-provided-service-with-schemas
- To check the ClusterServiceClasses, run:
Overview
UI Contracts are contracts between the Service Catalog views in the Kyma Console UI and the Open Service Broker API (OSBA) specification.
There are three types of OSBA fields:
- Mandatory fields which are crucial to define
- Optional fields which you can but do not have to define
- Conventions which are proposed fields that can be passed in the metadata object
The Service Catalog is OSBA-compliant, which means that you can register a Service Class that has only the mandatory fields. However, it is recommended to provide more detailed Service Class definitions for better user experience.
In the Kyma Console UI, there are two types of views:
- Catalog view
- Instances view
Read the Catalog view and Instances view documents to:
- Understand the contract mapping between the Kyma Console UI and the OSBA
- Learn which fields are primary to define, to provide the best user experience
- See which fields are used as fallbacks if you do not provide the primary ones
Catalog view
This document describes the mapping of OSBA service objects, plan objects, and conventions in the Kyma Console Catalog view.
Catalog page
These are the OSBA fields used in the main Catalog page:
Number | OSBA field | Fallbacks | Description |
---|---|---|---|
(1) | metadata.displayName | name*, id* | If metadata.displayName, name, or id fields are not present, a given Service Class does not appear on the landing page. |
(2) | metadata.providerDisplayName | - | If not provided, UI does not display this information. |
(3) | description* | - | If not provided, UI does not display this information. |
(4) | metadata.labels** | - | If not provided, UI does not display any labels. |
(5) | metadata.labels.local** and/or metadata.labels.showcase** | - | If not provided, it is not possible to choose a Basic Filter. |
(6) | tags | - | If not provided, it is not possible to filter by Tag. |
(7) | metadata.labels.connected-app** | - | If not provided, it is not possible to choose Connected Applications. |
(8) | metadata.providerDisplayName | - | If not provided, it is not possible to filter by Provider. |
*Fields with an asterisk are required OSBA attributes.
**metadata.labels is the custom object that is not defined in the OSBA metadata convention.
Catalog Details page
These are the OSBA fields used in the detailed Service Class view:
Number | OSBA field | Fallbacks | Description |
---|---|---|---|
(1) | metadata.displayName | name*, id* | - |
(2) | metadata.providerDisplayName | - | If not provided, UI does not display this information. |
(3) | not related to OSBA | - | - |
(4) | metadata.documentationUrl | - | If not provided, the link with documentation does not appear. |
(5) | metadata.supportUrl | - | If not provided, the link with support does not appear. |
(6) | tags | - | If not provided, UI does not display tags. |
(7) | metadata.longDescription | description* | If not provided, the General Information panel does not appear. |
(8) | not related to OSBA | - | - |
*Fields with an asterisk are required OSBA attributes.
Add to Namespace
These are the OSBA fields used in the Add to Namespace window:
Number | OSBA field | Fallbacks | Description |
---|---|---|---|
(1) | plan.metadata.displayName | plan.name*, plan.id* | |
(2) | not related to OSBA | - | |
(3) | not related to OSBA | - |
*Fields with an asterisk are required OSBA attributes.
Plan schema
A plan object in the OSBA can have the schemas field. Schema is used to generate a form which enables provisioning of the Service Class.
See the sample schema:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"properties": {
"imagePullPolicy": {
"default": "IfNotPresent",
"enum": [
"Always",
"IfNotPresent",
"Never"
],
"title": "Image pull policy",
"type": "string"
},
"redisPassword": {
"default": "",
"format": "password",
"description": "Redis password. Defaults to a random 10-character alphanumeric string.",
"title": "Password (Defaults to a random 10-character alphanumeric string)",
"type": "string"
}
},
"type": "object"
}
This sample renders in the following way:
Follow these rules when you design schema objects:
- If the field has limited possible values, use the enum field. It renders as a dropdown menu, so it prevents the user from making mistakes.
- If the field is required for the Service Class, mark it as required. UI blocks provisioning if you do not fill in the required fields.
- Fill the default value for a field whenever possible, it makes the provisioning faster.
- If the field, such as the password field, must be starred, use the format key with the password value.
Instances View
This document describes the mapping of OSBA service objects, plan objects, and conventions in the Kyma Console Instances view.
Service Instances page
These are the OSBA fields used in the main Instances page:
Number | OSBA field | Fallbacks | Description |
---|---|---|---|
(1) | not related to OSBA | - | It is the name of the Service Instance, created during service provisioning. |
(2) | metadata.displayName | name*, id* | If not provided, UI does not display this information. |
(3) | plan.metadata.displayName | plan.name*, plan.id* | If not provided, UI does not display this information. |
(4) | not related to OSBA | - | |
(5) | not related to OSBA | - | |
*Fields with an asterisk are required OSBA attributes.
Service Instance Details page
These are the OSBA fields used in the detailed Service Instance view:
Number | OSBA field | Fallbacks | Description |
---|---|---|---|
(1) | metadata.displayName | name*, id* | - |
(2) | plan.metadata.displayName | plan.name*, plan.id* | - |
(3) | metadata.documentationUrl | - | If not provided, UI does not display this information |
(4) | metadata.supportUrl | - | If not provided, UI does not display this information |
(5) | description* | - | If not provided, UI does not display this information |
*Fields with an asterisk are required OSBA attributes.