SSH into the virtual machine via bosh ssh -d cf api and do a sudo su, then monitor summary. If something there is failing, please provide the logs from /var/vcap/sys/log/ComponentThatIsFailingInMonitO

That looks good. And you are able to reach neutron or does it give you a 404? Could you please provide the full logs of the deployment.

Russel could you show a list of enabled OpenStack Services?

Hi Pranith, what is the reason you need to upload a complete folder and not just the jar itself?

Remove the comments, I meant. :-)

Comment out the keys for serviceProviderKey in uaa.yml and the application should start. BR, Johannes

That's very neat. Thanks for that hint Johannes!

For all except commercial it is. :-)

Hi, it is opensource as long as you don't use commercially.

Hi Samuel, this a bit more difficult than just deploying containers. There is a lot of work going into the preparation of scripting and so on. We are currently working on an implementation of standard

Gerne Matthias. :-) Swift should be an easy way to go if you know the S3 API quite well.

Hi Mathias, the assumption you have is wrong. There are two issues regarding your suggestion: 1) you don't have any control on the cf side (client) over nfs in warden containers. As far as I know this

Are you sure your logregator endpoint is configured on 443 and not 4443?

Go for it and let's see if we can document this issue afterwards with some logs for other people. daniel.jones(a)engineerbetter.com> wrote:

Daniel, I have had a problem with the deployment of Spring applications on Openstack recently as well. I am also not sure, without seeing the logs, what could be the reason, but did you try: http://ww

Documented it, here you go: http://www.evoila.de/cloud-foundry/adding-diego-release-to-cloud-foundry-release-v212/?lang=en

I just went through the process of deploying diego along with v212 on Openstack and I am sorry but I need to disagree with Gwenn. The whole setup was more or less trial and error. The documentation es