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

I was about to suggest a similar UX for expressing a list of route services, by relying on params ordering cf update-route DOMAIN [-n HOST] (-s 'service instance' )* cf update-route DOMAIN [-n HOST]

No. My endpoints don't change. I envision having a number of 12 factor stateless applications getting deployed using CF push (java buildpacks). Some of these stateless apps need to talk to each

can you describe the architecture of your applications? do the endpoints change often after some mircoservices have been started? your app needs some way to look up other network endpoints it needs.

database, Consul..can it be used for stateless components as well? Well here is a way to look at it. You can have consul to discover a bunch of cassandra nodes in a cluster, and you can remove a node

looks like the docs are only at 2.4: http://docs.cloudfoundry.org/services/api.html 2.5 should only have been incremental changes and should be backward compatible with other 2.x versions. when you