Hey Mike, Regarding the unsharing workflow, the app developers we've spoken to suggested that they would be frustrated if they were not able to unshare or delete a service instance that they had

I'm testing cloudfoundry doppler client using cf-cf-java i'm using firehose subscribe to receive data from cloud foundry and receive well data a few minute, but few minutes later firehose do

Thanks Matt. It also helps to know that bind will include space and org guid. Any thoughts on my other comments? For your convenience I've pasted them below. Mike Thanks for the feedback Mike,

Mike: get the application the service is being bound to and add an ASG to that space. Then on unbind I'd need to see if all the applications in the space with the binding are unbound from the

Peter: The org and space GUIDs will be sent to brokers in the bind request using the same context object that is sent when provisioning a service instance (this work is underway now). Good spot

Hi, So far it was safe to assume that a service instance and bound applications are in the same space. If a service instance is shared across args/spaces, this is no longer true. Currently a service

That said, this isn't a big deal. if it were a difficult thing for the platform to allow a broker to opt out of sharing then I would say forget about it. I'm only thinking that since the platform

Good point. I should have clarified I have services today that won't function *without modification*. That said, the modification in some cases wouldn't be pretty. For example, I have a broker that

*IMO as a broker developer of services that will not function if shared, I would really like a permission for the broker to opt in/out of services of it's type being shared. I'd hate for my users to

The CF CLI team cut 6.29.2 today. Deb, yum and Homebrew repos have been updated; binaries, installers and link to release notes are available at: https://github.com/cloudfoundry/cli#downloads Fixed

Looks good! wrote: -- *Zach Brown* | Strategic Product Owner 650-954-0427 - mobile zbrown(a)pivotal.io <http://pivotal.io>

Thanks for the response! See comments inline: Interesting. That behavior is different for bindings in the owning space. Today if a space developer wishes to delete a service in its owning

Hi Zach, Disregard that last message. Paul found the bug, fixed it. Video is playing correctly now and looks great. Thank you! -Chris

Hi Zach, Nice catch. I hadn't been told the video was up yet. Asciinema is pretty cool and also frequently annoying, it seems. I looked at the json file for your video, and the curl and response

Thanks for the feedback Mike, and great questions! We're currently working off slightly different assumptions, but are working through these to validate that they are the expected behaviour for the

Exciting!

Hey Chris Noticed the .NET ascii video is up on cloudfoundry.org/platform. There seems to be a formatting issue with this one too. I think it has to do with the number of lines in the terminal. It

Great! I just thought of some questions and didn't see them listed in the thread. * I assume that the space that originally created the service would be a kind of "owning" space right? So that

Super excited to start the process for incubation to the Runtime PMC for this! This set of features has long been requested and I'm excited to see forward progress on it. Will reach out to you with

Hello, Pivotal would like to propose to the CF Runtime PMC a new incubation project, "CF Permissions", focusing on improving the authorization experience in Cloud Foundry. This project aims to enable