I'll let the Loggregator team respond formally. But, in my conversations with the Loggregator team I think we're basically stuck not sure what the right thing to do is on the client side. How does the

Hmm... I suppose so. Conversely, by putting them all in one library you've added greater complexity and bloat by potentially including more transitive dependencies by default to use a given component

Nice work! This looks like an excellent client library. I'm glad it supports v2 and v3 apis. Any thoughts or plans for producing uaa and loggregator/firehose clients as well? Perhaps as separate modul

We heavy over commit our DEAs (like 4x) and we charge the customer the memory they've requested. But we also ensure our DEAs have in total some percentage of free memory on the DEAs just in case. So,

Thanks Dieu, I don't have a problem with the change request. It just seems like an oddly specific change given the current not very well defined set of roles we have. I'd like to see a more clear defi

So Bernd, it sounds like you would be against the change then that Dieu is proposing correct? I see your line of argument Bernd and could go with that. What I don't want to see is a gradual promotion

For some history this is the last discussion I recall having on the subject: https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/8Owzq9pzDSs/FzKX60KBdAkJ Mike

In our case we'll use the arbitrator because we only have 2 AZs in some datacenters. The Arbitrator allows us to place the 3rd member of the cluster in another datacenter minimal performance impact. N

I debated long ago and still believe that a space manager should be able to do everything a space developer can do. Could this be simplified just by making that change? Or are there still reasons to l

* In this case a release for each buildpack will reduce release download sizes significantly. My org only uses Java and Node. * Easily knowing what releases changed and which didn't will be nice. (Not

This is excellent! I love the decomposition of the buildpacks. I look forward to the day when cf-release disappears and we just have a bunch of small independent releases. Hopefully that day is gettin

Thanks Will. Does anyone know if this bug could also impacts Warden? Mike

That's ok. Just felt like venting a little is all. The simple revert worked. I'm probably the only one user still converting v1 services anyway. :) Mike

For anyone else that runs into this. I was able to revert https://github.com/cloudfoundry/cloud_controller_ng/commit/94ab558675641c8b325f821f9823721569c44fab from v227's CC commit a07fcc957ecf07d6c0f8

Not very nice removing the v1 service migration endpoint before actually removing v1 service support. Do you see any issue with my reverting that commit on the CC that went into v227? https://www.pivo

Yes I think that should work fine. Thanks, Mike

Hi Dieu, We are currently directly using an NFS mount provided by our enterprise NetApp appliance. We have been aware of this desired change but haven't had time to investigate what we will do about i

Awesome! Excited for route paths. Thanks! Mike wrote:

Stevo, I would recommend creating an issue on the gorouter project with details about your test case. That should bring some attention to this issue. I'm about to start utilizing context path routing

The addition of global config to disable this new functionality for a deployment has been proposed to maintain backwards compatibility. If you're interested in such a flag let the team know. Mike