Just to clarify your reference to [1], the proxy has keep alive support for ssh connections - it's the HTTP client used for authentication that was not configured with a keep-alive.

For the DEA's, I think it was removed here [1] with the removal of `vcap/component`. For health manager, I believe it was removed here [2] when the `cfcomponent` dependency was removed. In both cases,

Container networking is aimed at your requirement. Once it's ready, you would deploy your apps without external routes and rely on the private network for communication. We expect we'll have facilitie

Can you explain how staging tasks will be recorded? We have already seen a number of custom buildpacks that use the 15 minutes of staging time in interesting ways that consume significant resources. T

This has as much to do with finding the "right" place for the CATS as it does anything else. The CATS are the end-to-end acceptance tests that are associated with what used to be called `cf-release` -

The buildpack set event was implemented to enable usage based billing for buildpack applications where the rates differed by the buildpack used to stage the application. When staging an application in

Warden does not create a bind mount to the network namespace. If you want to find the namespace, locate the pid of the wshd associated with the container and use /proc/${pid}/ns/net as the namespace.

There are dozens of metrics emitted by diego but I don't know of any documentation for them in the open source repositories. You can find most of them with a quick search of the diego-release submodul

Looking again, it seems the cli *tries* to set the mode but, for some reason, the package that gets sent up doesn't have the permissions. https://github.com/cloudfoundry/cli/blob/master/cf/app_files/z

I can confirm that the problem is with how the cli handles zip entries in archives. When the cli extracts the zip into a temporary directory, it does not set the file mode on the files it creates. [1]

Try these: https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L220-L225 wrote:

resources we specified for the application? It asks for the larger of the minimum staging resources or the requested application instance resources. [1] [1]: https://github.com/cloudfoundry/cloud_cont

There are three resources that you can run out of that would result in that error: memory, disk, or containers. [1] These resources are validated during the auction that determines where a task or LRP

https://github.com/cloudfoundry-incubator/diego-ssh#cloud-foundry-via-cloud-controller-and-uaa bren(a)juanantonio.info> wrote:

For those that are interested, I want to make sure that you're aware that the daemon supports sftp and scp as well as the interactive shell. I don't think it would be hard for the cli team to pull in

Sure. I'm guessing you got a redirect from the cloud controller that points to a private blob store that external clients don't have access to. That blob store endpoint likely works fine for the cloud

Look closely at the IP address in your error message. You're targeting a private IP. Unless you're part of that deployment, I'm guessing you won't be able to access that address. bren(a)juanantonio.in

This is probably a question for bosh-dev. ...better known as cf-bosh now. :) (whoops) carlo.ferraris(a)rakuten.com> wrote:

This is probably a question for bosh-dev. carlo.ferraris(a)rakuten.com> wrote:

Instead of using a pivotal tap, why don't we create a cloudfoundry tap for the open source bits? Shannon raised this as an issue[1] on the CLI repo and I think it makes a lot of sense. Not only will i