My concern is that the HTTP check (mislabeled as "port") would still be the default and I'd have to expect users to opt out of it per app. It's confusing and not what users of the platform have come

Hi All, Starting cf-release V227, UAA is being consumed as a separate bosh release as opposed to a job. The release notes published earlier was not covering the details of all the spec changes that

Hi, The Routing team has the Route Services work in progress [1]. I believe once that work is complete you could develop a route service to be able to do this type of rate limiting. Shannon may be

wrote: Setting the health check to none does not actually disable health checks. This setting simply disables the HTTP healthcheck, and Diego will continue to monitor the process. I'm not sure why

Thanks a lot Dieu, that answers my question. I have another question about creating a deployment manifest using the following as guidelines:

Hey Jack, Thanks for putting the putting the pull request in. We'll review it shortly and get back to you on the thread.

Hi Kinjal, We generally recommend naming it with a specific identifiable folder name that is not the bucket root. This might look like: ... buildpack_directory_key:

Yes that should work too, but it's still nice to be able to install the gems during staging. Jack

Could using a custom gem mirror be achieved by caching the dependencies before push? Operating in a "airgapped" or "Disconnected environment" and operating in a "whitelist firewall environment" often

Can someone merge this PR: [1]? It provides useful features to allow operators to set a global gem repo mirror (via environment variable group) where the default repo is slow to reach.

Sorry, for the typo I meant 6868 Thanks, Kinjal

Thanks for all the replies. I think I've got what need. Jack

Hi Amit, This does not seem to be a port issue on 6968. I tried the same deployment by modifying the security groups (both bosh and cf ) to allow All Protocol All Ports. even wit this change the

Just to clarify as well why I think this is so important - a majority of apps on our internal platforms require authentication and will return a 401 on the root page, making them unusable on Diego for

I agree with your root argument that the port check doesn't really address application health and it's easy to push a non-working app and have the healthcheck still pass. My argument is that is

I updated the RFC pointed at in Danny's email, but figured I'd reply here as well, in the spirit of overcommunication. I'll state my opinion as the Buildpacks PMC Lead: I think we should sunset HHVM

CVE-2016-0732 Privilege EscalationSeverity Critical Vendor Cloud Foundry Foundation Versions Affected Cloud Foundry v208 through v229 UAA v2.0.0 - v2.7.3 & v3.0.0 UAA-Release v2 through

Hi, I have a question regarding the configuration of cloud controller. It is described at http://docs.cloudfoundry.org/deploying/aws/cf-stub.html#editing that DROPLET_DIRECTORY_KEY should be

In talking with a former team member, I came across the story [1] where we made this change. The WebAppServer will listen on the port immediately upon starting, even if the app has not successfully

Hey Aaron - You're right; it looks like the port check is only ever used. I don't have the history as to why we (the CF .NET team) implemented an HTTP check instead of a port check, but that's how it