-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow updated dashboard_url to be returned by update service instance #437
Conversation
Hey duglin! 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. |
Hey @duglin Can you explain the use case for changing the Does this happen when changing plans? I wonder if either the GET endpoints or extensions proposals could help here... |
I like the idea of the service broker being able to indicate to the platform that it should do a GET. Would work well in the async world. Likely need to think more on this, also interested in the use case. |
This could also be an opportunity to help brokers who may not be able to return a |
@mattmcneeney we have situations where updating the plan or parameters causes something similar to a migration and as a result a new dashboard_url is needed. In our cases the URL/creds of the service itself don't change, just the dashboard_url. |
05fa96f
to
3ead207
Compare
@mattmcneeney We also have brokers that cannot return a |
3 more needed |
@@ -1003,10 +1003,22 @@ For success responses, the following fields are defined: | |||
|
|||
| Response Field | Type | Description | | |||
| --- | --- | --- | | |||
| dashboard_url | string | The updated 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 (`0129d920a083838` 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 update request, even if the service is updated asynchronously. If present, MUST be a non-empty string. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really the updated URL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following your question
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume he means that it's not necessarily updated? It could be the original one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an impl choice I guess - we don't mandate the value sent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The (possibly) updated URL?
I’m happy to move this into validation through implementation, but whoever picks this up, it would be good to weigh up the pros and cons of using the new service instance GET endpoint to look for an updated dashboard URL after an update has completed vs adding this additional logic. Using the GET endpoint has the additional benefit of working for async updates where the broker cannot return the dashboard URL at the start of the operation. |
Agreed to move to validate- thru-impl on today's call |
This has been implemented in Kube Service Catalog, see the linked PR's up above and review this for merging into the spec. |
We have cases where upon doing an update we have a new dashboard_url for the service instance. This PR allows for the Platform to indicate that it supports the Broker sending back a new URL, and it allows for the Broker to do it. Signed-off-by: Doug Davis <dug@us.ibm.com>
Signed-off-by: Doug Davis <dug@us.ibm.com>
rebased and ready for review. Removing the "validate thru impl" flag per today's call. |
Need some reviews of this |
1 similar comment
| 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. | | ||
|
||
The ability to include updated metadata in the response message was | ||
added in version 2.14. Any Platform sending an API Version Header with a | ||
value of 2.14 or greater MUST use the new values specified in the response |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it should be added, and that is why we need to commit the matrix PR :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm confused! This feature shouldn't be in the matrix (which implies platforms MAY support it) if we are using MUST here, right?
We have cases where upon doing an update we have a new dashboard_url
for the service instance. This PR allows for the Platform to indicate
that it supports the Broker sending back a new URL, and it allows for
the Broker to do it.
Signed-off-by: Doug Davis dug@us.ibm.com