I feel that we are stearing this conversation into the wrong direction. Gist it, I would like to with cf logs app / firehose-to-syslog see my RTR-logs as blurgh.dev.cf.private.domain.com -

So if you move to Heroku you will be able to change the platform ??? I don't think so.. So you can put the new header from your app or at least the runtime buildpack or docker. Your application

WAKAWAKA is just an example But the difference is that WAKAWAKA is not platform specific whereas X-Cf-Requestid is. If we want to move our app to Heroku, or a VM, or whatewher we have platform

Have you looked at the `uaac` tool? I'm not quite sure I understand what you're trying to do, but you can map an LDAP group DN to a UAA group with `uaac`. Then if a user in that LDAP group logs in,

Very cool!

What Josh said!! WOW!

I am guessing a problem in your yaml file and the spring profile shoud be 'saml,default,fileMetadata' for saml no ? But I am not sure about the exact format

WOW! --  Thanks, Josh Long the Spring Developer Advocate, Pivotal http://joshlong.com || http://twitter.com/starbuxman || http://spring.io/team/jlong

Hi Tony, The logs you've retrieved only go back to Jul 21, which I can't correlate with the "?/2" issues you were seeing. If you could possibly record again a bunch of occurrences of flapping

You should definitely not run etcd with 2 instances. You can read more about recommended cluster sizes in the etcd

cloudfoundry.gr.jp, a Cloud Foundry user group in Japan, is currently running a project (or a campaign, more properly) called "Cloud Foundry 100-day challenge" ("Cloud Foundry 100-nichi Gyou" in

No problem, more than happy to clarify! Amit

Hi, We have cloud foundry v197 env wants to integrate UAA server with existing ADFS. But uaa server not working properly when changing uaa.yml from spring_profiles: postgresql to spring_profiles:

Thank you for the scrupulous answer, Amit. (I apologize this late response) -- View this message in context:

I don't see the difference between WAKAWAKA and X-Cf-Requestid. Gorouter would have to add some header with a uuid for the request. Your apps have to have logic to pass this header on, so that a log

Sure that header can be used. But then we are adding CF specific stuff into the implementation of our services, which is something we want to avoid at all costs. Also Im not entirely sure if all the

Hello Simon, The X-Cf-Requestid header already provides a uuid. Couldn't app "a" add the value of X-Cf-Requestid to a header of your choosing? Call it WAKAWAKA or X-Random-Header, but it doesn't need

The CF messages ingest OK into Splunk; None of the Diego messages ingest, not even the first line of their payload. The problematic deployment: · CF v212 · Stemcell 3012

Howdie! We have some devs who want to be able to trace a request troughout their applications. user -> a -> b -> c | |-> d -> e When a user makes a request to "a" uuid is

Thanks, it works now! Felix