Following up on this, I fixed the issue by using a verification key between the CC and the UAA instead of a token secret

In Diego/Garden, container files are stored on btrfs subvolumes. When a container is destroyed, the subvolume is removed with btrfs subvolume delete. I don’t think this does anything particularly

Hello again, I'm sorry for having to revive this topic, but I'm still unaware about the deletion process. Could you please specify the term "standard removal tool". What's the standard? Is standard

Thank you for your reply. True i think it was a coincidence ... I've try on a playground config to shutdown hm9000 and etd, and I did not lose routes at all, apps were still running.

Thank you Joseph, I will pass it to Dies Ricky Yunata Software & Solution Specialist Fujitsu Australia Software Technology Pty Ltd 14 Rodborough Road, Frenchs Forest NSW 2086, Australia T +61 2 9452

A lot of this is set to change in the near future to make things more clear. But here is what is currently going on. BOSH will pre-create machines it is going to need, and it does that without any

That's true. This is one of the limitations of pure tcp (layer 4) routing. We will be hit by scalability limits in terms of public IPs. However, per public IP we can theoretically provide 64K ports

Another situation we have that you may want to keep in mind while developing cf-deployment: * We are using vsphere and currently we have a cf installation with 2 AZ using 2 separate vsphere

Stevo, Just a confirmation that I also saw your suggestion for defining the http method for a route. Thank you, Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.

Hello Stevo, Thank you for your suggestion of support for wildcards in route paths. I have noted the request and will keep an ear out for the same request from others in order to help me

Also worth noting: if you're cloning from the ssh endpoint at github you must have an ssh key in your ssh agent that authenticates against a real github user, even if the repo is public. It seems as

Here are some of the examples: * Sensitive property management as part of manifest generation (encrypted or acquired from an outside source) * We have our own internal bosh releases and config that

Add another +1. We are implementing something akin to this within out environment, having it standardised would be a big win.

+1 We'd love a metadata service as well when the dust settles. Mike wrote:

My very limited understanding is that NFS writes to the actual filesystem, and achieves persistence by having centralized NFS servers where it writes to a real mounted device, whereas the clients

Onsi, I can tell you that we (IBM) would welcome a secure metadata service for retrieving credentials, etc. I'm sure we'd help make that happen. Cheers, Christopher Ferris IBM Distinguished

Checking once more that no one is using the Routing API yet, so we can proceed with backward incompatible API changes. I believe we still have this opportunity as we have not yet announced the

The DEAs are responsible for broadcasting the routes for the apps they are running. I can't think of why an hm9000 problem would cause routes to get lost, unless there was some problem with NATS

Yeah, just as it is possible to create users in UAA, it is also possible to delete them there, thus orphaning the user accounts in the Cloud Controller. The orphaned users won't cause any problems in

Thanks Dmitriy, Just for clarity, are you saying multiple instances of a VM cannot share a single shared filesystem? wrote: