Spruce looks pretty good than the other merging tool. And it is easy to switch from the spiff. I'll try it. Thanks! BTW, is this tool already used in the Stark & Wayne?

Hi Kyle, I'm not sure what mean by "running it locally". Can you explain in more detail how you've deployed your CF installation? Zak + Dan

I also see this error in the DEA logs: {"timestamp":1441999712.400334,"message":"Error copying files out of container: command exited

using separate regions or geographies implies a separate CF installations. there is no way today to use a single quota across multiple CF installations. this "no sharing across region boundaries"

The following is what they have asked for: 1. Total quotas for their whole ORG; 2. Each Branch has its own quotas; 3. Super users for the ORG can access each Branch. What we have offered them: 1.

what specifically did you try and what specifically didn't they like? the more information you provide around your request the more productive the discussion will be. wrote:

Unfortunately, we have tried that but they didn't like it very much.

Whoops, I have egg on my face. We've now communicated better with the CAPI team and are using their changes to the relevant repos with bosh-lite.com Sorry for the confusion Zak + Dan wrote: --

Hi Folks, Due to recent instability with xip.io we've created a dedicated DNS entry at "bosh-lite.cf-app.com" that points to 10.244.0.34. We've changed over the default domain in our cf-warden

Siva brings up a good point, you haven't really told us anything about your environment :) wrote:

My understanding is calling POST on /auth/token 100 times in parallel. I'll find out more about the test scenarios when I'm able to reach them. Thanks!

That said, you should definitely be keeping an eye on Spruce!!! :: spruce is a domain-specific YAML merging tool, for generating BOSH <http://bosh.io/> manifests. It was written with the goal of

zongwei, if they could define multi-org quotas rather than requiring a hierarchical org structure would that meet their needs? b wrote:

100ms to 200ms sounds about the right value to get an Oauth token. We did a benchmark with UAA and found out that out of the box, the auto reconfiguration sets the default JDBC connection pool value

Hi Benjamin, For example, one of our customers today has to create two Orgs for their two braches in different geographic locations, in order to manage resources quotas and etc. separately. Also,

I'm not using bosh, just trying to run it locally. I can post the dea and warden configs though: dea.yml: warden test_vm.yml: > server: container_klass: Warden::Container::Linux #

What request are you doing to get a token? wrote:

We're having a situation where it took about 5 seconds to get auth TOKENs for 100 users (but only 100 ms for a single user). Does this sound right? Has anybody else done benchmark of UAA perf who can

zongwei, could you give more detail on the problem you are hoping to solve? multi-level orgs is a solution, but i want to make sure there is clarity on the problem so we can discuss what other

We've been asked to support multi-level of Orgs. I realized this is huge, probably bigger than I thought. If you can give me some hints of the whole implications of this (components need to be