Open Samze opened 5 years ago
:white_check_mark: Hey Samze! The commit authors and yourself have already signed the CLA.
Why is the path part of the ID? I think the extension ID should be something globally unique to distinguish - let's say - two different backup and restore specifications.
Here are a few opinions:
Two outstanding things for this PR:
I would expect the extension ID to be globally unique and not having the extension base path in it.
For example, if I see the extension urn:osbext:pivotal.io:mysqlbackups:v1
, I know that the broker implements Pivotals MySQL backup. If that is a well-known extension, the platform might not even need the OpenAPI document for this extension (although I would strongly recommend always providing an OpenAPI document). The extension base path would then need to go into another field.
For example:
{
"id": "urn:osbext:pivotal.io:mysqlbackups:v1",
"path": "/p-backup",
"openapi_url": "https://pivotal.io/osb-extensions/backup_restore_v1.yaml"
}
If the broker also supports another backup extension, it is free to set a different path for that extension.
I would expect the extension ID to be globally unique and not having the extension base path in it. For example, if I see the extension
urn:osbext:pivotal.io:mysqlbackups:v1
, I know that the broker implements Pivotals MySQL backup. If that is a well-known extension, the platform might not even need the OpenAPI document for this extension (although I would strongly recommend always providing an OpenAPI document). The extension base path would then need to go into another field. For example:{ "id": "urn:osbext:pivotal.io:mysqlbackups:v1", "path": "/p-backup", "openapi_url": "https://pivotal.io/osb-extensions/backup_restore_v1.yaml" }
If the broker also supports another backup extension, it is free to set a different path for that extension.
The current proposal specifies the extension path implicitly from the openapi urn.
`:extension_path
MUST be the namespace specific string(NSS) part of the extension URN plus the path in the OpenAPI document.`. As you suggest, the other approach is that the broker author can explicitly declare which path to use, perhaps that would be less confusing.
We discussed this on the call and decided:
I will update the PR.
This has been updated.
Some folks from Heroku are playing around with an experiment for this right now. They may leave comments in this PR when they have them.
If they have something worthy of presenting they will bring to the group for review. Thanks!
any update?
I think it need to define an
operation
as the implementation ofextension
, just likeinstance
is the implementation ofplan
.
Could you elaborate on this?
I may be reviving a necro-thread here, but...
I mostly wonder why we're opting to couple extensions to service instances? More to the point: can we generalize this proposal further so that the broker itself can be extended?
I'm thinking about additional broker authz/n implementations, for example.
This wouldn't mean a loss in functionality from the current proposal either. In theory, a broker could still specify an instance_id
parameter in the extension's OpenAPI spec, but dropping the broker extension path from /v2/service_instances/:instance_id/extensions/broker-extension-path/backup
to /v2/extensions/broker-extension-path/backup
might give brokers a bit more flexibility.
Thoughts?
@Samze Can you provide some insights here or hand off to someone else?
@WalkerGriggs Yeah there are definitely use-cases for both extensions on brokers and on instances. The original idea was to break down the problem into two, start with extensions on instances and then follow up with extensions on the service broker itself. We started on extensions for instances as we had the most practical usecases for that. e.g. backup an instance.
@pivotal-marcela-campo yeah happy to chat more about this proposal if someone wants to take over driving this. It really stalled because while we had agreement in the PMC about this approach, neither CF or Service catalog had done any experimentation to validate this approach.
Why
The specification defines endpoints that allow the lifecycle management of service instances and service bindings. However, a common complaint is that it does not support some of those important “day 2” operations that developers might want, e.g backup and restore. Also that it does not allow service specific operations, e.g. MySQL set leader. To accomplish this Service Brokers authors have the option to either go off-spec or to misuse the spec (e.g.
cf update-service -p ‘{“trigger-backup”: true}’
).The specification needs an extension mechanism to allow authors to define new endpoints.
There was a previous PR attempt to provide this functionality through “generic extensions” which was opened in 26 Jan 2018. This PR proved complex to implement in part extensions could be hosted anywhere and it allowed any authentication via OpenAPI security schemas.
What
This is our first attempt to revive generic extensions!
This PR is similar to the previous PR in that:
It differs in that:
In order to not limit platform implementations we have not provided guidance on HOW the extension is triggered. Since the endpoint is hosted by the broker it is likely that platform makes a request to trigger the extension on the user’s behalf. This is the same as how all endpoints are called today from known platforms.
Open questions:
Notes
This PR came from this doc.
Sam & @georgi-lozev
(If this is unmerged in 2025, please close)
Closes #114