Hey Guillaume, To be fair, this did take some time to figure out on our end. It has to do with the interaction between BOSH and Monit. As Dieu mentioned, runtime has a story to potentially determine

It looks like we were making this harder than it needed to be. Grepping through the

hi Bob, you can still leverage an outside login server, none of the endpoints to accommodate have changed. We are 100% backwards compatible. I don't believe that we ever stated that we would not use

Filip, When the uaa and login were merged it was state that replacing replacing the login server would remain a supported scenario and this seems a departure from that statement. At the very least,

hi Sree and Matt, Matt is actually not referring to the wild cards. He wants the login.<domain> for his own application. Matt, at this time we are claiming that domain name, as we did with the login

Hi Matt, This new wild card route pattern was introduced for multi-tenancy in UAA post merge. Anything before login or uaa in the URL is now treated as a zone subdomain and the zone context is derived

Thanks again Filip, I got that resolved. Gradle needed my proxy settings to be entered here. $cat

Oups, sorry, I had probably overlooked this faulty trace that should have hinted me. [2015-05-26 16:37:51+0000] ------------ STARTING cloud_controller_ng_ctl at Tue May 26 16:37:51 UTC 2015

Thanks a lot Mike and Dieu. Indeed moving the nfs_mounter last seemed indeed to fix the issue in v207. If ever this reproduces on master and can help, I submitted

Hi all, I'm working on some automation for my client to declaratively configure orgs and spaces across multiple Cloud Foundry instances (hopefully they'll permit open-sourcing this). I erroneously

Hi, Thanks for the response. It seems to get stuck here .. ./gradlew assemble --info Downloading

Prior to the consolidation of uaa and the login server in uaa release 2.0, we were running our own login server to handle auth to our platform. We simply reduced the instance of the bundled CF login

I updated my bosh (using bosh-init) with enabling ignore_server_availability_zone. but it still failed when I deployed my cf. Anything suggestion? openstack: &openstack auth_url:

Dan, We announce the PWS's CF version on status.run.pivotal.io: About This Site If you encounter any issues please contact support(a)run.pivotal.io. Pivotal Web Services is the latest public

I was testing an app on Diego today and part of the test was for the app to fail. I simulated this by putting some garbage into the `-c` argument of `cf push`. This had the right effect and my app

We recently experienced a similar issue. Not sure if it is the same. But it was caused when we moved the nfs_mounter job template to the first item in the list of templates for the CC job. We moved

We have environments on stemcell 2977 that are running well. We have an environment using NFS that ran into that same issue and we have this bug open. [1] Specifying the nfs_mounter job last should

We recently experienced a similar issue. Not sure if it is the same. But it was caused when we moved the nfs_mounter job template to the first item in the list of templates for the CC job. We moved

Hi, Corentin, Diego, like the DEAs, supports evacuation of LRP instances during controlled shutdown of a cell VM (the analog of a single DEA in Diego's architecture). If you're using BOSH to deploy

The script that is executing at the time is: https://github.com/cloudfoundry/cf-release/blob/master/packages/uaa/pre_packaging#L36 So what my suggestion is to test if this works is that you can