Hi, Daya, Hmm, that sounds like something strange with the local networking on your machine. The 'can't assign requested address' error is coming from the Golang standard networking libraries, and

Hi Dmitriy, Actually, after I generated the bosh release and bosh-openstack-cpi release locally, I deployed them with bosh-init and failed with keystone v3. I found this is caused by fog-1.27.0 code

Hi Dmitriy, Thanks for your guiding. I can run bundle exec rake spec:lifecycle under bosh_openstack_cpi in bosh repo. but cannot know what's the command "be rspec spec/unit/"? It seems you missed

First two snippets need to run from bosh repo (github.com/cloudfoundry/bosh). Last one is from bosh-openstack-cpi-release

I tried to run these commands. but got failure. Anything specific to set? How to get the Gemfile? ubuntu(a)boshclivm:~/git/bosh-openstack-cpi-release$ bundle install Could not locate Gemfile or

Yup, you're right. I looked through the debug logs of my deploy and they look the same. I guess it threw me off that it was draining and deleting so fast (10 seconds in my case). Thanks for helping

Hey, ci/ directory is meant to be used with concourse CI (http://concourse.ci/). Alternatively... To run unit tests: cd bosh_openstack_cpi bundle install be rspec spec/unit/ To run lifecycle tests

I've looked at the debug logs for when instances are decreased. It does make the correct calls: drain, then stop before deleting the VM: I, [2015-07-16 00:18:30 #6206] [] INFO -- DirectorJobRunner:

Hi Eric, I have successfully deployed the Diego release as per the recommended compatible versions you mentioned, but now hitting the next road block while executing “cf api” commands. Also I

Despite that message being displayed (it’s displayed before stop/shutdown commands are sent to the VMs), it should’ve still triggered the drain script [1]. Looks like the drain log file isn’t

Hi , Our microbosh has been deleted accidentally and we do not have the micro bosh deployment manifests as well. Is there any way that we can recover from this? Thanks, Guru

Thanks, for the record I'm on release 2889. Mike wrote:

well you can always can add any command to vagrantbox, but i can't see how this is the problem, interfaces should not overload, and anyway it's the VM interfaces that is overloaded, so routing to host

You should not have to specify resource pool sizes (in fact we are deprecating this feature soon). I'll look into this tomorrow morning. Sent from my iPhone

Ah, we aren't specifying resource pool sizes. Letting bosh manage that. Mike wrote:

Hi, Did you decrease resource pool size too ? Thanks

We recently scaled down a bunch of our DEAs. We did this by simply reducing the instances in our job and deploying. When doing this it didn't appear that bosh shut down these extra VMs allowing them

Hi, Daya, Good luck with the refreshed deployment! Please do note that CF v213 was not recommended for general use, as it contained a CCDB migration that was not backwards compatible. For a new

Hi Eric, Thanks for responding, as far as I can tell, I did generate the deployment manifest correctly. But just to make sure I deleted the deployment and my cf-release repo and redid the whole

Hi, Daya, It looks like the consul service data in your deployment manifests is incompatible with the data that the consul agent job expects to consume in its agent_ctl.sh.erb script template. These