Is there a method to retrieve some basic metadata about a running task from within the task container? For example determine the user who launched the task so the task can email results. Or the task

Pivotal would like to propose the CF Services API project for inclusion in the Runtime PMC as an Active project. Please find the proposal document attached [1], and let us know if you have any

Hi Ketaki, I'm not able to reproduce that issue on latest CF. -Zach

Hello Prasad, This is actually expected behavior. You can find documentation about service access here https://docs.cloudfoundry.org/services/access-control.html. It notes a limitation at the

Hi everyone, The CF networking project (also known as Diego networking, container networking, c2c) is currently under the cloudfoundry-incubator. We would like to propose moving it from incubation to

Matt, I'd suggest also looking into reflecting the sharing of service instances via service usage events. -Dieu

This is likely due to the nozzle not being able to keep up with the load from Traffic Controller. You can confirm this by looking for slow consumer alerts [1]. It is recommended to scale your nozzle

Chris; - We're not yet sure how instances would count towards quotas, but this is on our list of things we will investigate as we move forward. - This is true, however our research has shown

Hi all, Good proposal, it rises some questions: * Org1 probably pays money for the service and when sharing the service to Org2 the payment should be shared as well --> how can this be

Hi there, Interesting proposal, thank you for suggesting it! I have a few questions around some of the practicalities: - How would shared services count towards the service instance quotas in

Mike, I agree with both of those thoughts. I'll speak to the CLI time as consistency across the commands is important, and will ensure that we treat failed unbinds the same as we do with normal

I think the logic of auto-unbinding the service makes sense as long as the user doing the delete has a way to know that other applications (potentially in other spaces) are bound to the service and

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