Generic Extensions (actions)

[rhodie27]

See issue https://github.com/openservicebrokerapi/servicebroker/issues/114.

First draft of the generic actions (aka extensions) proposal on a per-service-instance basis.

A couple notes:

1. In addition to updating Provisioning, I added a separate section for Extensions at the bottom b/c I suspect we will add actions/extensions at the service (and broker) level next. A lot of this can likely be handled in the same way so it made sense to me to separate it out now.
2. The OpenAPI, Auth & adheres_to sections obviously need more content/wording, but I wanted to get some quick feedback on the direction.
3. I haven't really looked at any changes required outside of spec.md yet.
4. I'm an awful speller today, so good luck.

[cfdreddbot]

Hey rhodie27!

Thanks for submitting this pull request!

All pull request submitters and commit authors must have a Contributor License Agreement (CLA) on-file with us. Please sign the appropriate CLA (individual or corporate).

When sending signed CLA please provide your github username in case of individual CLA or the list of github usernames that can make pull requests on behalf of your organization.

If you are confident that you're covered under a Corporate CLA, please make sure you've publicized your membership in the appropriate Github Org, per these instructions.

Once you've publicized your membership, one of the owners of this repository can close and reopen this pull request, and dreddbot will take another look.

[rhodie27]

Reopen please, my org was private for some reason. I fixed the CI issues.

[cfdreddbot]

Hey rhodie27!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

[duglin]

@rhodie27 overall I think it looks good! Just some editorial suggestions.

[duglin]

@rhodie27 any chance of addressing the comments before tomorrow's call?

[duglin]

thanks! Looks good!

[vaikas]

LGTM

[rhodie27]

Check out https://github.com/rhodie27/osb-actions-poc for this in action, (pun intended). Note, the verbs are slightly different and it is lacking credentials and adheres_to.

[duglin]

overall it looks good and I'm ok with moving to validate-thru-impl with the understanding that we'll do minor updates before we merge - I don't think any of my comments should block forward motion.

[rhodie27]

Generic Actions Proposal: https://docs.google.com/document/d/1fVBzqi6OK-lyfjDKADSk35hZD4YUqM2AMtoLOgrDDCE/edit

Generic Actions Usecases: https://docs.google.com/document/d/1fVBzqi6OK-lyfjDKADSk35hZD4YUqM2AMtoLOgrDDCE/edit#heading=h.b62bp6xehn25

[n3wscott]

LGTM

[jmrodri]

Nice work overall.

[duglin]

Platform invoked them

Sent from my iPad

On Feb 27, 2018, at 9:40 AM, Paul Morie notifications@github.com wrote:

@pmorie commented on this pull request.

In spec.md:

@@ -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 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 for more information. | + +##### 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, +Restore, Stop, Start, Restart and Pause. + +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. 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.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[duglin]

I believe we were supposed to find out how much interest we each had on this one... from our side we are still interested in the idea in general but have no immediate need for it. I guess that means its a "nice to have" but not a "show stopper" or "must have" for us right now.

[Samze]

After a period of inactivity we are now revisiting generic instance extensions. There is a new proposal doc here.

[mattmcneeney]

Closing this as we are planning on moving forward with https://github.com/openservicebrokerapi/servicebroker/pull/670