Update the Service Catalog documentation to include namespaced resources #1102
Conversation
kazydek
added
the
area/service-management
|
Removed examples of (Cluster)ServiceBroker from the diagram ;) |
|
|
||
| * **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 obtain access credentials for their applications. |
There was a problem hiding this comment.
not really or I just misunderstood, ServiceBinding requests credentials or configuration for a given instance and results in Secret creation
|
|
||
| * **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 obtain access credentials for their applications. | ||
|
|
||
| * **Secret** is a basic resource to transfer logins and passwords to the Deployment. The service binding process leads to the creation of a Secret. |
There was a problem hiding this comment.
I would say credentials/configuration because in many cases it is not login and password
transfer also sounds strange, it simply contains credentials that can be later used in your application to consume instance
Deployment narrows the possibilities, it is not necessary Deployment only
There was a problem hiding this comment.
I changed it. I also updated 012-details-provisioning-and-binding.md as it stated Deployment or Function instead of application.
| * **Secret** is a basic resource to transfer logins and passwords to the Deployment. 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 allows you to bind a ServiceInstance to any resource. |
There was a problem hiding this comment.
it actually allows you to specify what kind of resource is bindable to the instance through the SBU
|
|
||
|  | ||
|  |
There was a problem hiding this comment.
Service Catalog frame should be more visible, more exposed and cover only service classes, brokers also should be excluded
|
|
||
| 3. The user gets a list of the available services in the Kyma web console or CLI. | ||
| 3. In the Console UI or CLI, the Kyma user lists all exposed cluster-wide and Environment-specific services and requests to create their instances in the Environment (ServiceInstances). |
There was a problem hiding this comment.
their instances in the Environment (ServiceInstances) ?
There was a problem hiding this comment.
What's unclear about that sentence? Is requests to create instances of those services in the Environment. better?
|
|
||
| 1. During the Kyma installation, the system registers the default Service Brokers in the Kyma cluster. The cluster administrator can manually register other Service Brokers in the Kyma cluster. | ||
| 1. 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 (ServiceBroker) in a given Environment. |
There was a problem hiding this comment.
"The Kyma user can also register a Service Broker (ServiceBroker) in a given Environment." -> Is there any need to double Service Broker here?
Description
Changes proposed in this pull request:
Related issue(s)
Relates to #298