Hi, We're going to use diego in production. Could you please give the date of the first formal release? Thanks.

i think i understand what you mean now. shannon has thought through those concepts and relationships and the options for how to express them. i'll let him comment on his current thinking. i got hung

It should work since our acceptance tests validate this on every build we cut [1]. Are you running the operation as someone with a cc admin scope? If you want to create a gist with the log (with

Depends on your role and where your app is in the deployment pipeline. Most of the scenarios I envisioned were for the tail end of development where you need to poke around to debug and figure out

I would rather that scp would throw an error than having it copy the file and then immediately kill the instance. I still don't understand how that would ever be useful. Or would having a

On behalf of many customers that I have spoken to, the default behavior of disposing of any container that could be tainted is the right choice. Not providing rope is a huge feature of the platform.

I'm having an issue where I can't upload any buildpack to cloudfoundry; it says "The buildpack upload is invalid: a filename must be specified" and the cf_trace confirms it's sending a null value for

Hello, A commit to increment the broker API version header went out by mistake. We are currently backfilling docs for 2.5 (should be published very

Thanks for the response Mike. I'll take a look this afternoon when I get a chance and get back to you. Josh Ghiloni Senior Consultant 303.932.2202 o | 303.590.5427 m | 303.565.2794

Hi Josh, I can't reproduce what you're describing, so in order to diagnose what's going on, we'll probably need more information. Here's what I did to attempt to reproduce, so that you can compare

It feels like the right behavior, but also very unexpected. My vote would be to enable it by default, but as Matt suggests, make clear to the user that their actions will have unrequested

Let me clarify. I'm still 100% on board with binding a service to a route. What I'm proposing with my different perspective is to decouple the idea of a Route service being a proxy and think of a

we explored the ux of app to service binding in detail, but it is problematic. apps will soon support multiple routes on different ports. e.g. imagine an app with 3 ports: web traffic goes to

This thread [0] on Route services has got me thinking. I'd like to propose a slightly different perspective on the route services concept. A typical service today, lets call them "App Services" at

executing a command, concluding an interactive session, or copying a file into an instance, that instance will be restarted. I have to agree with Matt S here - having this as default behavior

I can certainly confirm that for Intel this feature would be required for us to use ssh/scp access at all, and maybe not even then. We've been selling Cloud Foundry to our security folks as a huge

matt, could you elaborate a bit on what you believe ssh access to instances is for? b wrote:

thanks for sharing your view matt. i happen to disagree. i've talked to many more conservative enterprise operations people and they really don't want to enable snowflakes by default. since we plan

i would encourage you to consider a circuit breaker pattern like hystrix which will have graceful degradation if a remote endpoint is unavailable because it has not started yet, has too many failures,

My concern is the default behavior. When I first prototyped this support in February, I never expected that merely accessing a container would cause it to be terminated. As we can see from Jan's