I started the uaa by building from the tagged version in cf-release v215 and running it via tomcat with a custom config file, but I didn't specify a database. I have both a cf and admin section in the

ok, so the URL you have is /oauth/token, that's fine. your trace returns "authorization_endpoint":"http://localhost:8080","token_endpoint":" http://localhost:8080/uaa" indicating that there is a

Running that command against /uaa/oauth/token gives just a redirect to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf cli. What do you mean by deploy it as root "/"? As

Oddly, I can see your list on nabble here: http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html But it's just blank in the email, and also on the

ok, this should be an easy one to test (put in your username and password) curl -v -XPOST -H"Accept:application/json" -u "cf:" -d "username=marissa&password=koala&client_id=cf&grant_type=password"

Also: when i do 'uaac token get' with those same credentials, it succeeds.

curl exit code 6 means DNS failed. xip.io is flaky, so we this often in our dev environments where our app domains tend to be HA_PROXY_IP.xip.io. The CATS expect the apps to finish uploading,

Turn on trace, and post your data here. remember, if this is a prod environment, you may want to send me the token directly We can show you how to decode this token, and see why it is

I'm having an issue with my cloud controller/UAA setup where when I do cf login I get '401 unauthorized' back, but when I use the uaac command line tool to get a token it works fine. This makes me

johannes, the problem of upstream schema changes causing downstream change or breakage is the current situation: every addition of a metric type implies a change to the dropsonde-protocol requiring

Good afternoon! Our CF deployment fails 4 of the CATs. I have put the errors and the full output in a GIST here: https://gist.github.com/qanx/677d64df27d911f39acd Summary: * There's a curl error

Great! Thanks Dieu. Mike

Shannon recently pulled the story over into the Routing team's tracker [1] with the intention to submit a PR for it to the CLI team. -Dieu CF CAPI PM [1]

Route path support has been in the CC and Router for several months now. What is the status of getting these into the CLI? I did a quick search for a CLI tracker story and couldn't find one. Mike

I have disabled the timeout on the gorouter "-1" trusting our Front end load balancer to manage the timeout. That way I only need to worry about configuring timeout on one device in my proxy chain.

To follow up on this, I've been working with Simon Moser on an initial proposal for this and he is now taking lead on it. Simon just completed a PM dojo at the end of August. Dieu

The new routing-api and routing-api-cli allow you to register / unregister routes You will need to ensure you are also deploying routing-api with cf-release Routing

Yes, I was just talking with Onsi and Mark Kropf about this yesterday and plan to submit a talk on this with Mark Kropf for cf summit berlin. I'll take on getting the proposal for isolation groups

which cf-release are you using? newer versions support an http api for trusted components to register routes. shannon is the PM for the routing team and can explain more and perhaps point to

i would trace through the various system component logs to see where the timeout is starting with each component that the client connects to and seeing if that request came through. by submitting a