Skip to content
Closed
Changes from 26 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 100 additions & 0 deletions spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -841,13 +841,113 @@ For success responses, the following fields are defined:
| --- | --- | --- |
| dashboard_url | string | The URL of a web-based management user interface for the Service Instance; we refer to this as a service dashboard. The URL MUST contain enough information for the dashboard to identify the resource being accessed (`9189kdfsk0vfnku` in the example below). Note: a Service Broker that wishes to return `dashboard_url` for a Service Instance MUST return it with the initial response to the provision request, even if the service is provisioned asynchronously. If present, MUST be a non-empty string. |
| operation | string | For asynchronous responses, Service Brokers MAY return an identifier representing the operation. The value of this field MUST be provided by the Platform with requests to the [Last Operation](#polling-last-operation) endpoint in a percent-encoded query parameter. If present, MUST be a non-empty string. |
| extension_apis | array-of-objects | For extensions to the Service Broker API, Service Brokers MAY return one or more `extension_api` objects that describe additional API endpoints via an OpenAPI document. See [Extension API Object](#extension-api-object) for more information. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/openservicebrokerapi/servicebroker/pull/459/files is adopted then the 2nd column will need to change.


##### Extension API Object

The `extension_api` object MAY be used to describe any additional endpoint
to the Open Service Broker API. An example of this could be lifecycle
management of a Service Instance, (e.g. "Day Two Operations"), like Backup,

@gberche-orange gberche-orange Mar 26, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest the specs to clarify when an extension_api should be defined and used by broker authors w.r.t. to asking 1st class support in the OSB API.

Are platforms expected to provide UI/CLI tooling for any declared extensions (i.e. dynamically generating UI from the openAPI document) ? Would generated UIs and user workflows be restricted to single API endpoint calls, or would instead spawn across multiple API calls (e.g. list backups, restore backup, delete backup) ?

Are platforms instead expected to additionally support specific curated extensions and bring optimized user experience for them? If so, where/how would such curated extensions be defined and published ?

Can the specs recommend use-cases for extensions such as:
1- operator specific extensions : a platform operators is adding custom features to a broker and brings custom UI on along it.
2- service specific extensions (say stop/resume operation) that only applies to a category of services
3- vendor specific extensions (say K8S/CF vendor X way of offering backup which differ from vendor Y)
4- platform specific extensions (e.g. CF AR service metrics ingestion which differs from K8S metrics ingestion) that can't be supported by platform-specific profiles

Would the mentioned day 2 operations seem be fitting some of the cases above?

  • Backup, Restore: vendor specific extensions
  • Stop, Start, Restart and Pause: service specific extensions

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest the specs to clarify when an extension_api should be defined and used by broker authors w.r.t. to asking 1st class support in the OSB API.

The current thinking is it is entirely up to the broker author, and the platform can choose to provide, at minimum, the OpenAPI UI (or even just the OpenAPI url). Then platforms can extend the UI based on 'adheres_to'.

Are platforms expected to provide UI/CLI tooling for any declared extensions (i.e. dynamically generating UI from the openAPI document) ? Would generated UIs and user workflows be restricted to single API endpoint calls, or would instead spawn across multiple API calls (e.g. list backups, restore backup, delete backup) ?

We had talked about how to batch calls but it became clear that this could be designed forever and we decided to support just the single endpoint as a first step, but nothing stops a clever broker from providing batch/aggregation on their own.

Are platforms instead expected to additionally support specific curated extensions and bring optimized user experience for them? If so, where/how would such curated extensions be defined and published ?

adheres_to is the mechanism we think will do this. If it is proven that this is not enough we can always revisit the spec to add what is lacking.

Can the specs recommend use-cases for extensions such as:
1- operator specific extensions : a platform operators is adding custom features to a broker and brings custom UI on along it.
2- service specific extensions (say stop/resume operation) that only applies to a category of services
3- vendor specific extensions (say K8S/CF vendor X way of offering backup which differ from vendor Y)
4- platform specific extensions (e.g. CF AR service metrics ingestion which differs from K8S metrics ingestion) that can't be supported by platform-specific profiles

I suspect this is out of scope for the current PR, at least until we see some real world emergent behavior for generic actions.

Restore, Stop, Start, Restart and Pause.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these example operations seem like they would be long-running. Is there any way for a broker to report status of a long running action back to the platform?

@spadgett spadgett Feb 27, 2018

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to this, is there a way brokers can provide either success or failure messages for the platform to display when an operation is run? Ideally if the request fails, the UI can give a specific error about what went wrong instead of a generic failed error.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Async ops, if enabled, would be defined via the swagger file. The platform could detect and subscribe to ops based on the returned swagger.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Async ops, if enabled, would be defined via the swagger file. The platform could detect and subscribe to ops based on the returned swagger.

I'm not sure how a platform can detect it only from the swagger. A human looking at it might notice an endpoint called /backup/<id>/status and guess that it's for checking status of an async operation. But how can the platform know programmatically to do that?

As an end user, I'd be worried if I couldn't check the status of an operation like "Restore" and know that it completed successfully.

I could see it if the platform recognized the adheres_to and had special handling for that particular standard.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the short answer is it's not going to be possible across the board for all APIs.

My thought was that the platform could recognize a callback object in the openapi doc, (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#callbackObject) and other openapi patterns to figure out what it needs, but we won't know until someone tries.

It's the main issue with going the generic route on extensions.


The `extension_api` MUST include a URI to an OpenAPI 3.0+ document that the
Platform can use to determine the new endpoint(s), parameter(s) and
authentication mechanism. The new APIs are extensions to the Open Service Broker
API. As such they are intended to be invoked by the Platform on behalf of its
clients.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that occurred to me reading back through this is that it's not clear how the extensions are expected be invoked. Does the platform invoke them? Do users invoke them? This is probably entangled with @spadgett's question about long-running operations.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The answer to this from the googs perspective is yes. If the platform would like to invoke them then that should be ok, and if the platform provides all the information to a third-party that should work out as well.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the PR clarify the concurrency aspects that the platform/users should comply with when invoking extensions ? For instance, should a broker exposing a restore extension-api expect concurrent calls to the endpoint with potentially conflicting parameters ?

This relates to #467


See [OpenAPI Server Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#serverObject) for more information.

| Response Field | Type | Description |
| --- | --- | --- |
| discovery_url* | string | A URI pointing to a valid OpenAPI 3.0+ document describing the API extension(s) to the Open Service Broker API including, endpoints, parameters, authentication mechanism and any other detail the platform needs for invocation. The location of the API extension endpoint(s) can be local to the Service Broker or on a remote server. If located on a remote server acccessing the OpenAPI document MUST NOT require authentication. MUST be a valid URI. If `discovery_url` is a path, the Platform can assume it is to be called relative to the basepath of the Service Broker. The returned OpenAPI document MUST be in json format. See the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md) for more information. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're implying that if the location is not on a remote server then the OpenAPI doc MUST use the same auth as normal OSBAPI calls, correct? If so, we should probably state that.

| server_url | string | A URI pointing to a remote server where API extensions will run. This URI will be used as the basepath for the endpoint(s) described by the `discovery_url` OpenAPI document. If no `server_url` is present, the Platform MUST assume the extension API endpoint(s) are to be invoked using the Service Broker host and port. If present, MUST be a valid URI. If `server_url` is a path, the Platform can assume it is to be called relative to the basepath of the Service Broker. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that's been raised before is having a list of the operation names present in this object to make it easier to create UIs without hitting the URI.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a new object to try to cover this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that in the OpenAPI doc they can't put the full URL for each operation? If not, perhaps add to the end of the 2nd sentence " when those endpoints are relative URLs". maybe?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, the openapi endpoints are relative to one or more defined server objects. Will likely change to "path objects" which implies they are relative paths.

| credentials | object | A Service Broker MAY return authentication details for running any of the extension API calls, especially for those running on remote servers. If not present, the same authentication mechanism used for the normal Open Service Broker APIs MUST work for the new endpoint(s). If the Service Broker wants to use alternate methods of authentication, (e.g. on remote servers) it MUST provide details to that mechanism in the OpenAPI document via one or more [Security Scheme Objects](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#securitySchemeObject). Next, each extension endpoint in the OpenAPI document MUST have one or more [Security Requirement Objects](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#securityRequirementObject) defined that matches a [Security Scheme Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#securitySchemeObject). Lastly, the parameters needed by each [Security Scheme Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#securitySchemeObject), (e.g. username and password for basic authentication), MUST be provided as part of the `extension_api` object within the `credentials` object. If credentials are present in an `extension_api` object, the Platform will need to verify the authentication method from the OpenAPI document. |
| alt_instance_id | string | Refers to a parameter in the `discovery_url` OpenAPI document that maps directly to the Service Broker API `instance_id` parameter. If the extension API endpoint(s) use a different value to represent a Service Broker instance, then `alt_instance_id` MUST be present. If not present, the Platform can assume `instance_id` means Service Broker Instance in the OpenAPI document. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you investigating an alternative key name @rhodie27?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but none of them are great. Open to other suggestions.

  • openapi_instance_id
  • id
  • openapi_id

@mattmcneeney mattmcneeney Feb 22, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More brainstorming:

  • openapi_instance_key
  • extensions_instance_key
  • discovery_instance_key
  • openapi_instance_parameter

I don't like id as that makes me think of the value of the key-value pair, rather than the key if that makes sense.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @mattmcneeney on this, something other than id would fit better. Any of the above *_key variants seems acceptable. I think I like openapi_instance_key or extensions_instance_key the best.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openapi_instance_key is confirmed

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to push back on this field entirely and I apologize for not being in the original discussions for it.

I think alt_instance_id is an attempt at serving pre-processed open api information and the correct way to solve this issue is with vendor extensions in the open api doc. You could add a key, say "x-osb-instance-id": "instance_name" on the definition of the resource and it will allow you to do the same thing without polluting the response from provisioning.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apology accepted. I agree, this could be done via vendor extentions, however, the overall theme I have been trying to push is to not make the service provider change their OpenAPI document to fit the service broker's needs. Perhaps the service broker author doesn't have that ability/power or the service provider doesn't want a million different vendor customizations in their pretty swagger. I guess we could always say that the Service Broker author needs to maintain their own OpenAPI document... Sounds messy.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vote is to remove this for now. Mike to add language about the openapi doc must do this somehow.

| operation_display_names | object | A Service Broker MAY match operations in the `discovery_url` OpenAPI document with user consumable display names. If present, each key in this object MUST match an [operationID](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#operationObject) from the `discovery_url` OpenAPI document, with each value representing a human readable string. Platforms can use this object to show end users operations that are available on their Service Instance prior to calling the `discovery_url` OpenAPI document. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/calling/retrieving/

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this play with the idea of more than one broker supporting the same set of APIs? In particular, what if each provided their own set of display names and they're all different? As long as the platform never tries to do any kind of bulk action I guess that's ok - but even so, seeing a different phrase for the same semantics might give a funky UX.

While I understand the desire for this, it sure would be nice if we could say something like "use the last phrase in the operation's URL/path".

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are multiple implementation paths for platforms to accept the extensions api:

  1. Handle everything dynamically; use 'operation_display_names' to show operations before generating UI forms from the openapi doc.
  2. Have a platform specific definition for how operations and openapi documents are written. The platform can create pre-generated UIs based on known operation names and parameters.
  3. Utilizes adheres_to to pre-generate UIs on a case by case basis according to some standard(s).
  4. All of the above.

IMO, it's pick your poison and 'operation_display_names' gives some UI advantage for #1 in that you don't need to load up the OpenAPI doc prior to generating the form for the specific operation.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can operation_display_names be a subset of the list of operations in the OpenAPI document? And if so, should the platform only show the actions in this list, or all?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why display names should come back in this response. Why isn't display name included in the schema that comes from discovery_url?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zrob the request was to have a way to show something in a platform UI before having to call the openapi document. See the comment above this, https://github.com/openservicebrokerapi/servicebroker/pull/431/files#r171010501.

Also, OpenAPI doesn't have a consistent way to give operations display names. They have the operationid, description, summary, but they all serve other purposes. And I wanted to stay away from telling people how to define their openapi document, (as much as I could), so that existing ones could be used.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also push back on this field. operation_display_names could be accomplished in other ways, like a lookup service that takes the adhears_to (plus more data?) url and returns the same list, maybe hosted by the broker.

I think we need to draw a line on the data that is returned from a provision is data that is specific to the instance that was created, and when instances of the same type start to return the exact same data is a red flag for me.

Are we going to need the platform to remember the exact operation_display_names per instance? Because if we let it be in the response, the broker could make this list dynamically as provisioning happens.

Then we also need to talk about how does this list get updated as the instance is upgraded under the brokers control and new extensions are enabled. The only way to be sure is to fetch and process the open api doc.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also push back on this field. operation_display_names could be accomplished in other ways, like a lookup service that takes the adhears_to (plus more data?) url and returns the same list, maybe hosted by the broker.

The request from a few different people, (mostly RH), is they want a way to get a list of keywords associated with the service instance actions, prior to having to load and parse the openapi document. Adhears_to will not be available 100% of the time, and typically will not be used when you are interested in dynamically generating any returned openapi document.

I think we need to draw a line on the data that is returned from a provision is data that is specific to the instance that was created, and when instances of the same type start to return the exact same data is a red flag for me.

I do agree we need to draw a line, I believe this is it for validating phase. We can always remove/change if it doesn't work IRL.

Are we going to need the platform to remember the exact operation_display_names per instance? Because if we let it be in the response, the broker could make this list dynamically as provisioning happens.

The same could be said for the OpenAPI document, in general. Maybe it's different per service_instance...

Then we also need to talk about how does this list get updated as the instance is upgraded under the brokers control and new extensions are enabled. The only way to be sure is to fetch and process the open api doc.

The same response will be required on a service_instance update. I just haven't added that to the PR yet.

| adheres_to | string | A URI refering to a specification detailing the implementation guidelines for the OpenAPI document hosted at the `discovery_url`. While this property is a URI, there is no requirement for there to be an actual server listening at that endpoint. This value is meant to provide a unique identifier representing the set of extensions APIs supported. If present, MUST be a valid URI. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The semantics of this column could be clarified a little bit - what is the advantage of specifying a URI that points to a location where no server is running?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't follow. Which part are you referencing?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this property is a URI, there is no requirement for there to be an actual server listening at that endpoint. and If present, MUST be a valid URI. confuse me a little. If it's not required to be a server, why do we enforce it to be a URI?

Am I write in thinking that this field is going to be used to allow clients to spot "common" operations that they could do, say, in bulk across multiple service instances?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Often people push for unique IDs to be URIs so that they avoid strings that too simplistic - like "backup". By making it a URI its trying to force people to namespace things by including some domain name in the URI.

While I've heard bulk ops as one reason for this, to me the bigger reason is that a platform (or its UI) can know when it comes across some actions that it knows about and may want to do some special processing for. E.g. perhaps it has a dedicated UI for them. W/o some well defined URI to say "yes, these are the set of ops that's been defined by spec xxx" the platform can't really be sure what those ops do. Checking (strcmp) the names of the ops alone doesn't really guarantee anything.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per Paul's suggestion I will add some text here about what the Platform can do with this information. Should clear this up, (mildly).


\* Fields with an asterisk are REQUIRED.

#### Provisioning response

```
{
"dashboard_url": "http://example-dashboard.example.com/9189kdfsk0vfnku",
"operation": "task_10"
}
```
#### Provisioning response with extentions

```
{
"dashboard_url": "http://example-dashboard.example.com/9189kdfsk0vfnku",
"operation": "task_10",
"extension_apis":[{
"discovery_url": "http://example-openapi-doc.example.com/extensions",
"server_url": "http://myremoteserver.example.com",
"credentials": {
"basic": {
"username": "admin",
"password": "changeme"
},
"api_key": {
"api_key": "some_key_value"
},
"petstore_auth": {
"token": "some_token_value"
}
},
"operation_display_names": {
"createBackup": "Take Backup",
"postRestore": "Restore Instance"
},
"alt_instance_id": "serviceInstance",
"adheres_to": "http://example-specification.example.com"
}]
}
```

#### OpenAPI Security Scheme Object example

```
"securitySchemes": {
"basic": {
"type": "http",
"scheme": "basic"
},
"api_key": {
"type": "apiKey",
"name": "api_key",
"in": "header"
},
"petstore_auth": {
"type": "oauth2",
"flows": {
"implicit": {
"authorizationUrl": "http://example.org/api/oauth/dialog",
"scopes": {
"write:pets": "modify pets in your account",
"read:pets": "read your pets"
}
}
}
}
}
```
#### OpenAPI Path Object example

```
"post": {
"summary": "Backup Service Instance",
"operationId": "createBackup",
"responses": {
"201": {
"description": "backup response.",
}
}
}
```

## Updating a Service Instance

Expand Down