1. Yes - the source address observed by listeners accessed from a container will be a DEA address. 2. Yes - DEAs implement a default egress policy of deny; you must explicitly enable access to address

Just adding a couple of technical bits to Jason’s response. To be more explicit, NATS is a/topic based message bus. The DEAs do subscribe to a number of topics but routing isn’t one of them. Basically

... or any other Cloud Foundry 2016 certified platform. You can find a list of them here: https://www.cloudfoundry.org/use/cloud-foundry-certified/ wrote:

You have a lot of questions here and some of them may depend on how you’re deploying Cloud Foundry. I’ll add some answers inline. A container is created for each desired instance of an application and

James Bayer posted about a fun experiment with web sockets a while back. Might be a good starting point: http://www.iamjambay.com/2013/12/send-interactive-commands-to-cloud.html You need to make sure

Regarding Nic's ssh comment, if you're running Diego, I'd recommend using the port forwarding feature instead of copying the data. It was actually one of the scenarios that drove the implementation of

The blob names in the store should match the buildpack key from the buildpacks table in the CCDB. (The key is basically the buildpack guid concatenated with the sha1 hash of the buildpack bits by an u

Sorry - misread the question. You're looking for the actual buildpacks instead of the droplets. You can construct the file names from the information in the admin buildpack table. I'll post details in

If you're on a new enough level, you can try the droplet download endpoint [1]. [1]: https://apidocs.cloudfoundry.org/225/apps/downloads_the_staged_droplet_for_an_app.html wrote:

wshd is simply reporting [1] the pivot_root [2] failure. It looks like you're getting an EINVAL from the call which implies warden is running in an unexpected environment. If I were to guess, I'd say

`restage` will stop your application, run the application bits through the staging process to create a new droplet, and then start the new droplet. It's a lot like `push` but without actually pushing

With DEA's, you can't. With Diego, you can look at the new TCP routing support [1] if you want the port to be accessible to everyone, all the time, or ssh port forwarding [2] if you only want someone

No formal extension process currently exists to do what you're asking for. The topic has been raised at the runtime PMC as others have similar needs. It sounds like the identity team may have some pla

It doesn't mean that the process *can't* swap but it does mean that when memory usage exceeds the limit, the kernel won't swap out any pages to avoid the oom killer. There were some discussions about

As a user, you can't. Even though somaxconn is associated with the network namespace, you need to be privileged (root) to change it. If you wanted a higher default across all containers, you could mod

I did the work on the cli plugin but not on the integration into the cli. Based on your first error, it looked like we were having a problem getting the one time code, not authenticating with the ssh

That's not the request that the plugin is making to get the token. We're using the API that was created for us [1]. If you use straight curl with something like this, what does the flow really look li

Does /v2/info contain the `app_ssh_auth_client` key? If not, it should be set to the client ID of the ssh proxy. If it's not set, I think that's one of the symptom. https://github.com/cloudfoundry-inc

Given the scope and cross cutting nature of the issue, I think it's something better handled by the CLI team via prioritized stories. Speaking from experience, large PRs and PRs that involve refactors

There are a number of places in the cli where a user needs to provide a json payload to the cli. For example: create-service/update-service bind-service create-service-keys create-security-group/updat