|
Guillaume Berche
Great, thanks Dieu.
Guillaume.
toggle quoted message
Show quoted text
On Fri, Sep 4, 2015 at 8:44 AM, Dieu Cao <dcao(a)pivotal.io> wrote: Thanks Guillaume for the feedback. I've now gathered enough feedback to
bring async operations out of the experimental phase and bump the service
broker api version.
I've added stories to the CAPI backlog [1] and we'll get the diagram
updated too.
Localized error messages is not something we are looking to work on right
now. I believe there was a previous attempt to have CC errors localized
that ended up not being merged due to issues with the way v2 constructed
error messages and not being backwards compatible. As these descriptions
passed from brokers via the last_operation end point don't go that route,
there's perhaps a path forward there.
Happy to discuss if it's work that anyone is interested in taking on via
PR.
-Dieu
CF CAPI PM
[1] https://www.pivotaltracker.com/epic/show/2058352
On Wed, Sep 2, 2015 at 5:00 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
Thanks Dieu for your response.
We have successfully implemented an async service broker for out internal
dbaas [1], [2] which db farms provisionning sometimes takes longer than
30s.
Concerning improvement suggestions on the documentation, I could only
spot an inconsistency on the sequence diagram, where the last operation
description is mismatching between broker response (1/3 nodes") and CC api
response ("40% complete") whereas the 'description' is a string which
should be returned as is. Hard to propose a PR on that since the source
file for this diagram does not seem available under docs-services [4]. BTW,
It would be great if bookbinder would support rendering diagrams from a
text format such as plantuml [5], or rely on plantuml public service [6]
for such rendering.
Wouldn't is make sense to exit the experimental status of the async api,
even if it's not feature complete ? i.e. considering the api is stable
enough and won't change in an incompatible maneer soon, thereby enabling
clients such as cf-java-client to rely on them.
One other potential improvement I see to the API would be to support
localized user-facing operation status description. Having the CLI being
I18Ned but brokers enable to return user facing messages in the user
language seems limiting. Maybe it could be the case of having the CLI add a
usual 'Accept-Language: zh_Hans" matching the current CLI locale, and
the CC propagating this header in the last_operation broker endpoint [7] so
that they can return the status message in the smae language when
translations are available.
Thanks,
Guillaume.
[1]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/master/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L60
[2]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/a3f150fc7d3bb889875aac202496a4f63efc3595/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L67-L73
[3]
http://docs.cloudfoundry.org/services/images/async-service-broker-flow.png
[4]
https://github.com/cloudfoundry/docs-services/blob/master/images/async-service-broker-flow.png
[5] http://plantuml.com/sequence.html
[6] http://plantuml.com/plantuml/
[7]
http://docs.cloudfoundry.org/services/asynchronous-operations.html#polling
On Tue, Sep 1, 2015 at 5:50 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
Hi Guillaume,
We are looking for a couple more pieces of feedback. All feedback I've
received so far has been positive.
There was one report recently from Robert Moss about being able to
provide the dashboard_url asynchronously instead of part of the original
response [1].
I'm also considering whether that needs to be addressed prior to marking
the feature complete, or if it should be a separate/additive change to the
service broker api.
If you've had success with the current implementation, I would be
greatly interested in hearing that.
-Dieu
[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/
On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
Hi,
I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]
We have a pending PR in cf-java-client [2] which is waiting for the
async broker spec to be made official.
Thanks in advance,
Guillaume.
[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984
On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:
i'm very happy to see this work delivered as the 60 second limit has
come up so often as a pain point in the past. great job to all who
contributed!
On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Well done Services API! This is an awesome milestone!
On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:
Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.
Nice work everyone!
On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.
As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!
This feature is currently considered experimental, as we'd like you
all to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.
We have not bumped the broker API yet for this feature. You'll
notice that our documentation for the feature is separate from the stable
API docs at this point. Once we're confident in the design (we're relying
on your feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.
Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q
tl;dr
Cloud Foundry expects broker responses within 60 seconds. Now a
broker can return an immediate response indicating that a provision,
update, or delete operation is in progress. Cloud Foundry then returns a
similar response to the client, and begins polling the broker for the
status of the operation. Users, via API clients, can discover the status of
the operation ("in progress", "succeeded", or "failed"), and brokers can
provide user-facing messages in response to each poll which are exposed to
users (e.g. "VMs provisioned, installing software, 30% complete").
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Thanks Guillaume for the feedback. I've now gathered enough feedback to bring async operations out of the experimental phase and bump the service broker api version. I've added stories to the CAPI backlog [1] and we'll get the diagram updated too. Localized error messages is not something we are looking to work on right now. I believe there was a previous attempt to have CC errors localized that ended up not being merged due to issues with the way v2 constructed error messages and not being backwards compatible. As these descriptions passed from brokers via the last_operation end point don't go that route, there's perhaps a path forward there. Happy to discuss if it's work that anyone is interested in taking on via PR. -Dieu CF CAPI PM [1] https://www.pivotaltracker.com/epic/show/2058352
On Wed, Sep 2, 2015 at 5:00 AM, Guillaume Berche <bercheg(a)gmail.com> wrote: Thanks Dieu for your response.
We have successfully implemented an async service broker for out internal
dbaas [1], [2] which db farms provisionning sometimes takes longer than
30s.
Concerning improvement suggestions on the documentation, I could only spot
an inconsistency on the sequence diagram, where the last operation
description is mismatching between broker response (1/3 nodes") and CC api
response ("40% complete") whereas the 'description' is a string which
should be returned as is. Hard to propose a PR on that since the source
file for this diagram does not seem available under docs-services [4]. BTW,
It would be great if bookbinder would support rendering diagrams from a
text format such as plantuml [5], or rely on plantuml public service [6]
for such rendering.
Wouldn't is make sense to exit the experimental status of the async api,
even if it's not feature complete ? i.e. considering the api is stable
enough and won't change in an incompatible maneer soon, thereby enabling
clients such as cf-java-client to rely on them.
One other potential improvement I see to the API would be to support
localized user-facing operation status description. Having the CLI being
I18Ned but brokers enable to return user facing messages in the user
language seems limiting. Maybe it could be the case of having the CLI add a
usual 'Accept-Language: zh_Hans" matching the current CLI locale, and the
CC propagating this header in the last_operation broker endpoint [7] so
that they can return the status message in the smae language when
translations are available.
Thanks,
Guillaume.
[1]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/master/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L60
[2]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/a3f150fc7d3bb889875aac202496a4f63efc3595/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L67-L73
[3]
http://docs.cloudfoundry.org/services/images/async-service-broker-flow.png
[4]
https://github.com/cloudfoundry/docs-services/blob/master/images/async-service-broker-flow.png
[5] http://plantuml.com/sequence.html
[6] http://plantuml.com/plantuml/
[7]
http://docs.cloudfoundry.org/services/asynchronous-operations.html#polling
On Tue, Sep 1, 2015 at 5:50 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
Hi Guillaume,
We are looking for a couple more pieces of feedback. All feedback I've
received so far has been positive.
There was one report recently from Robert Moss about being able to
provide the dashboard_url asynchronously instead of part of the original
response [1].
I'm also considering whether that needs to be addressed prior to marking
the feature complete, or if it should be a separate/additive change to the
service broker api.
If you've had success with the current implementation, I would be greatly
interested in hearing that.
-Dieu
[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/
On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
Hi,
I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]
We have a pending PR in cf-java-client [2] which is waiting for the
async broker spec to be made official.
Thanks in advance,
Guillaume.
[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984
On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:
i'm very happy to see this work delivered as the 60 second limit has
come up so often as a pain point in the past. great job to all who
contributed!
On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Well done Services API! This is an awesome milestone!
On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:
Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.
Nice work everyone!
On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.
As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!
This feature is currently considered experimental, as we'd like you
all to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.
We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.
Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q
tl;dr
Cloud Foundry expects broker responses within 60 seconds. Now a
broker can return an immediate response indicating that a provision,
update, or delete operation is in progress. Cloud Foundry then returns a
similar response to the client, and begins polling the broker for the
status of the operation. Users, via API clients, can discover the status of
the operation ("in progress", "succeeded", or "failed"), and brokers can
provide user-facing messages in response to each poll which are exposed to
users (e.g. "VMs provisioned, installing software, 30% complete").
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Guillaume Berche
toggle quoted message
Show quoted text
On Tue, Sep 1, 2015 at 5:50 PM, Dieu Cao <dcao(a)pivotal.io> wrote: Hi Guillaume,
We are looking for a couple more pieces of feedback. All feedback I've
received so far has been positive.
There was one report recently from Robert Moss about being able to provide
the dashboard_url asynchronously instead of part of the original response
[1].
I'm also considering whether that needs to be addressed prior to marking
the feature complete, or if it should be a separate/additive change to the
service broker api.
If you've had success with the current implementation, I would be greatly
interested in hearing that.
-Dieu
[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/
On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
Hi,
I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]
We have a pending PR in cf-java-client [2] which is waiting for the async
broker spec to be made official.
Thanks in advance,
Guillaume.
[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984
On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:
i'm very happy to see this work delivered as the 60 second limit has
come up so often as a pain point in the past. great job to all who
contributed!
On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Well done Services API! This is an awesome milestone!
On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:
Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.
Nice work everyone!
On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.
As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!
This feature is currently considered experimental, as we'd like you
all to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.
We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.
Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q
tl;dr
Cloud Foundry expects broker responses within 60 seconds. Now a broker
can return an immediate response indicating that a provision, update, or
delete operation is in progress. Cloud Foundry then returns a similar
response to the client, and begins polling the broker for the status of the
operation. Users, via API clients, can discover the status of the operation
("in progress", "succeeded", or "failed"), and brokers can provide
user-facing messages in response to each poll which are exposed to users
(e.g. "VMs provisioned, installing software, 30% complete").
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Hi Guillaume, We are looking for a couple more pieces of feedback. All feedback I've received so far has been positive. There was one report recently from Robert Moss about being able to provide the dashboard_url asynchronously instead of part of the original response [1]. I'm also considering whether that needs to be addressed prior to marking the feature complete, or if it should be a separate/additive change to the service broker api. If you've had success with the current implementation, I would be greatly interested in hearing that. -Dieu [1] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/
On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com> wrote: Hi,
I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]
We have a pending PR in cf-java-client [2] which is waiting for the async
broker spec to be made official.
Thanks in advance,
Guillaume.
[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984
On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:
i'm very happy to see this work delivered as the 60 second limit has come
up so often as a pain point in the past. great job to all who contributed!
On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Well done Services API! This is an awesome milestone!
On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:
Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.
Nice work everyone!
On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.
As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!
This feature is currently considered experimental, as we'd like you all
to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.
We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.
Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q
tl;dr
Cloud Foundry expects broker responses within 60 seconds. Now a broker
can return an immediate response indicating that a provision, update, or
delete operation is in progress. Cloud Foundry then returns a similar
response to the client, and begins polling the broker for the status of the
operation. Users, via API clients, can discover the status of the operation
("in progress", "succeeded", or "failed"), and brokers can provide
user-facing messages in response to each poll which are exposed to users
(e.g. "VMs provisioned, installing software, 30% complete").
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Guillaume Berche
toggle quoted message
Show quoted text
On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote: i'm very happy to see this work delivered as the 60 second limit has come
up so often as a pain point in the past. great job to all who contributed!
On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Well done Services API! This is an awesome milestone!
On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <cchilders(a)cloudfoundry.org
wrote: Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.
Nice work everyone!
On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
On behalf of the Services API team, including Dojo participants from IBM
and SAP, I'm pleased to announce experimental availability and published
documentation for this much-anticipated feature.
As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!
This feature is currently considered experimental, as we'd like you all
to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.
We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.
Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q
tl;dr
Cloud Foundry expects broker responses within 60 seconds. Now a broker
can return an immediate response indicating that a provision, update, or
delete operation is in progress. Cloud Foundry then returns a similar
response to the client, and begins polling the broker for the status of the
operation. Users, via API clients, can discover the status of the operation
("in progress", "succeeded", or "failed"), and brokers can provide
user-facing messages in response to each poll which are exposed to users
(e.g. "VMs provisioned, installing software, 30% complete").
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
