Thanks, Aaron, that's extremely helpful. I'll start a separate thread on cf-dev shortly soliciting more input on how the community would find richer health checks useful, but this specification seems

Hello Johannes, You have observed expected behavior. Wildcard routes are designed to catch all subdomains, unless other routes (wildcard or otherwise) exist to match. Primary use cases for wildcard

Hi Dieu, I had the same plans. But the solution feels a bit like a workaround. Is this behaviour expected? If not should I try to fix it? Cheers Johannes

I have setup uaa service, and trying to setup a non-browser client (another server actually) to get the authorization. In fact, I am trying to adapt sample "login" application to my needs. However,

Hi Gwenn Thanks for your feedback, and taking the time to look through the changelog! cf-release/consul-release have been on 0.5.2 (post BoltDB migration) since Jun

Thanks Filip and Shawn. I think Filip's suggestion would solve our problem. -- http://www.twitter.com/sivabalans

My biggest concern is the Data migration from LMDB to BoltDB, I know there is a CLI to do that but I am concern about the migration of the DATA itself. *" Previously, Consul would automatically

Thank you for the additional context, Carlo. I agree the loss of support for non-TLS requests would not only restrictive, but potentially backwards incompatible. Shannon Coen Product Manager, Cloud

The only known route limitation I am aware of on a CF org is the route quota associated with the org. If you type 'cf org [ORG_NAME]' you should see how many routes are allowed. You can also view

We would potentially be affected as we use Fog's Atmos provider for now. In the future we plan to implement fully s3 compatible Object storage so no problem then but may require some backwards

hi Siva, can't you just register *.uaa.test.com as a route? https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L173-L182

In support of work in progress to enable developers to specify application ports when mapping routes, cf-release v229 introduces a database migration for CCDB. *For deployments that use a PostgreSQL

Hi cf-dev, cf-diego The CF Infrastructure team which maintains consul-release ( https://github.com/cloudfoundry-incubator/consul-release) is considering bumping from consul 0.5.2 to 0.6.0. There are

Yes, I agree that setting the specific URI to check would be necessary as well so that developers could avoid some of the other concerns. So the ones I can think of: * URI / endpoint * Expected

Hello, We have an implementation of UAA using Identity zones where each zone in UAA is represented by a unique route and this route is bound to that UAA app in our cloudfoundry implementation. Eg: If

I can't comment on the common use cases, and who this change would break. However, I'm very much in favor of hiding this implementation detail from our API. Letting a library's internal API leak into

ps: forgot to mention that openStack Swift is of course in scope, too. Mit freundlichen Grüßen / Kind regards Simon Moser Senior Technical Staff Member / IBM Master Inventor Bluemix Application

Hi everybody, we are beginning work on the Bits Service proposed here [1] for handling all kinds of blobstore related operations - a functionality that is in the cloud controller today. Cloud

Hi, Aaron and Matt, Thanks for the thoughtful discussion of the Windows health-check issue. I too think for consistency that if the CF end user has specified 'port' as the type of health-check on

You might consider making a tiny custom 404 app and then map *.cf.bar.io and *.foo.bar.io and any other sub domains to it so that it doesn't fall through to your landing page app. Would that work for