Yup - I can confirm as well. All buildpacks relying on download.run.pivotal.io are failing now. S. wrote:

Hi, My 2 cents - but have you look at sensu (https://sensuapp.org/) - I was in need of something similar, and so end up deploying along with every pushed app an sensu client (agent) that pull metrics

Hi, Bug ? Pushing an application using a manifest.yml file with an host entry set to 'api', you are able to override the default route api.<<mycf.domain>> with the application - preventing further cf

Hi, Thanks for the clarification - it should be worth to update the documentation (http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html) - as I followed this one, and this setting is not

Hi, Trying to a fresh new installation of CF on AWS - I'm hitting the following issue when the deployment is trying to update the api_z1/0 jobs. I'm following the instruction - http://docs.cloudfoundr

Hi, i end up regenerating the whole stack using v234 instead and it worked - using the same consul certificates. Sylvain

Hi all, Following as example the aws-broker-release (https://github.com/cf-platform-eng/aws-broker-boshrelease) - please find an addition for anyone you wish to provide AWS S3 service as a broker. It'

Hi all, Following as example the aws-broker-release (https://github.com/cf-platform-eng/aws-broker-boshrelease) - please find an addition for anyone you wish to provide AWS ElastiCache service as a br

Hi, Diego has been default in my CF installation (H/A over 3 AZ) - and today, while trying a simple BOSH CF update of a stemcell - the consul_z1/0 keeps on "failing after update". If I look in the log

Hi, Any hint on how to fix it ? From a network topology - nothing changed, and I can't find anything usefull in consul documentation for reforming my cluster. Currently the 2 second consul node server

Hi, Ok - after doing the recovery scenario - the cluster was back, and finally ping point the root cause. The reason - on 2 DIEGO cells - the consul_agent (client) is running out of disk space to writ