Move OSBA Contracts to main docs #1507
Conversation
klaudiagrz
requested review from
bszwarc,
kazydek and
tomekpapiernik
as code owners
|
please make sure screenshots follow guidelines and that they are up to date with current designs |
| * optional fields, which you can but do not have to define | ||
| * conventions, which are proposed fields that can be changed with your own fallbacks | ||
|
|
||
| The Service Catalog in Kyma is OSBA-compliant, which means that you can register a Service Class that has only the mandatory fields defined. Such Service Class displays in the Catalog view, however, it does not display in a pleasant and satisfactory way. Follow the UI Contracts and write your definitions in the recommended way to provide the best user experience. |
There was a problem hiding this comment.
The Service Catalog in Kyma is OSBA-compliant
it is not just in kyma, it is general SC goal, to be OSBA compliant so no need to write about it
just write that you can register a service class with mandatory fields
|
|
||
| UI Contracts are contracts between the Service Catalog views in the Kyma Console UI and the [Open Service Broker API](https://www.openservicebrokerapi.org/) (OSBA) specification. | ||
|
|
||
| There are three types of OSBA fields: |
There was a problem hiding this comment.
you write in general about OSBA fields, so do not mention UI here yet, just introduce those 3 different types of filelds
| - Instances view | ||
| - Brokers view | ||
|
|
||
| Read the **Catalog view**, **Instances view**, and **Brokers view** documents to learn more about the OSBA fields used in those particular Kyma Console UI views. |
There was a problem hiding this comment.
here you can mention about those fallbacks,
so read those 3 different docs do understand the contract mapping between UI and the OSBA and which fields are primary for us for best experience, and what fields are used as a fallback if you do not provide the primary ones
| type: UI Contracts | ||
| --- | ||
|
|
||
| This document describes the mapping of [OSBA service objects](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#service-objects) in the Kyma Console Brokers view. |
There was a problem hiding this comment.
this doc can be removed, there is nothing in brokers view that is taken from OSBA
| type: UI Contracts | ||
| --- | ||
|
|
||
| This document describes the mapping of [OSBA service objects](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#service-objects) in the Kyma Console Instances view. |
There was a problem hiding this comment.
I like the idea of linking directly to OSBA, just please make sure you link properly
it is not always service object section
for example for catalog and instance view it is also plan object, in other cases also other objects, depending what we display
maybe better link here https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#catalog-management ? what do you think?
| 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 changed with your own fallbacks |
There was a problem hiding this comment.
which are proposed fields that can be changed with your own fallbacks
no fallbacks
which are proposed fields that can be passed in the `metadata` object
| * optional fields, which you can but do not have to define | ||
| * conventions, which are proposed fields that can be changed with your own fallbacks | ||
|
|
||
| The Service Catalog is OSBA-compliant, which means that you can register a Service Class that has only the mandatory fields. |
There was a problem hiding this comment.
maybe add a sentence
Nevertheless it is recommended that for better user experience you provide much more detailed class definitions
?
|
|
||
| \*Fields with an asterisk are required OSBA attributes. | ||
|
|
||
|  |
|
|
||
| \*Fields with an asterisk are required OSBA attributes. | ||
|
|
||
|  |
* Ignore vscode files * Switch to new cbs tests * Fix tests
Description
Changes proposed in this pull request:
consolerepository to the mainkyma/docs/service-catalog/documentation