Thanks Amit! A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for

We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of

Hey Omar, You can set the "serial" property at the global level of a deployment (you can think of it as setting a default for all jobs), and then override it at the individual job levels. You will

Zach, Thanks for the hints. You are right, I am not using latest stemcell: vagrant(a)agent-id-bosh-0:~$ bosh

One of the things we've started going in the Runtime-specific meetings is asking that individual team status updates are provided ahead of time, and then we use the time in the meeting for Q&A only,

Wayne, Can you verify that you are using the latest bosh-lite stemcell 3147? Older stemcells are known to have issues with consul which is what many of the CF components use for service

As of cf v231, CC has switched from using NFS to WebDav as the default blobstore. There are more details in the release notes: https://github.com/cloudfoundry/cf-release/releases/tag/v231. I don't

Kayode, I am using the default bosh-lite-v231.yml file and the instances for nfs server is set to 0: vagrant(a)agent-id-bosh-0:~$ egrep -i "name:.*nfs|instances"

Hello everyone, I know it is possible to update and redeploy components in parallel in cloud foundry by setting the "serial" property in the deployment manifest to "false". However, is such a thing

For anyone interested we have also now added a smoke tests project for chaos-galago that can be used to monitor the service-broker. This can be found:

Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar

Wayne, is the nfs_server-partition running?

I checked the blobstore is running: root(a)e83575d2-dfbf-4f7c-97ee-5112560fa137:/var/vcap/sys/log# monit summary The Monit daemon 5.2.4 uptime: 4h 14m Process 'consul_agent'

Amit, Thanks for letting me know I might have looked at the wrong log files. I saw the following in cloud_controller log files: root(a)7a1f2221-c31a-494b-b16c-d4a97c16c9ab:/var/vcap/sys/log#

Hi, Is the solution same as the one offered in IBM Bluemix? Where can I find more information on IBM's solution [open-Autoscaler], current/planned features, their roadmap, timeline etc. ? Kind

The log lines saying "/var/vcap/sys/run/cloud_controller_ng/cloud_controller.sock is not found" is probably just a symptom of the problem, not the root cause. You're probably seeing those in the

Hi Wayne, Looks like it, It is trying to connect to loggregator and failing I

Hi, I'm no expert but “monit” is a component of BOSH, not Cloud Foundry. Your question would get answered if asked on the “bosh-dev” mailing-list. Cheers

Since it is complaining /var/vcap/sys/run/cloud_controller_ng/cloud_controller.sock is not found, I thought I would just touch that file. Now I get: 2016/03/06 17:14:11 [error] 18497#0: *5

Sridhar, Thanks for your response. I have tried your suggestion and it doesn't help. But I might have misled you with the consul error. That error only got logged once at the beginning. So like