Hi Nils, I cannot seem to reproduce this. I am logged in as an org-manager: $ cf services Getting services in org ncalugar-a1 / space ncalugar-a1 as ncalugar+a1-org-manager(a)pivotal.io... OK name

Hi Ryan, Thanks for your e-mail. I'm following the instructions from https://github.com/cloudfoundry-incubator/diego-release This is how I generate my certificates CA certificate $ certstrap init

Before confirming the new version of fog fixed this, I tried to reproduce the error using CF v233. Instead of reproducing the error, it actually worked. V2 CONFIG: provider: 'OpenStack'

Hi Ricky, We think there might be an issue with the TLS certs that you provide in the etcd properties of the manifest. Can you tell us how you generated these certs? We also discovered an issue with

Hi Rich, We investigated and determined the recursive chown was not necessary. The commit is still working it's way through CI, but will hopefully make it in the next

Wohoo!!!!!!!!

Hi, "execution expired" in most cases means that the registry cannot be reached from the newly created VM. Make sure that your BOSH director is reachable on port 25777 from the new VM. As Gwenn

Hi, There seems to be a difference between how "cf services" and "cf service" are working in regard of permissions and I would like to understand why. As organization manager but without a role in a

Hello Hope you are doing well. I wanted to bring to your attention the latest SNS Research report in which you might be interested, " The M2M, IoT & Wearable Technology Ecosystem: 2015 - 2030 -

Hi Adrian, Thanks for your reply. The log file for the database is too big to be attached by e-mail, so I have uploaded to dropbox. You can access it

Per the thread in here <https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/E4XL4GTTDAPNDDEGE7NASKPMLESRIT3Z/#E4XL4GTTDAPNDDEGE7NASKPMLESRIT3Z> a while back, the varz

Hi Sam, Sorry for the slow response - Monday and Friday were public holidays in the UK (where the Garden team are based) so we didn't get a chance to look in to this. I think your understanding of

Hi Ricky, Thanks for the clarification, if you can give us the logs for all three etcd instances, we can help debug exactly whats going on. You can retrieve the logs from the etcd instances by

wrote: It's getting a 404. Are you trying the correct URL? Try wss instead of ws. Maybe that will help. By the way, what CF are you targeting? Did you install your own? a public cloud? Dan

Hi again, We created https://github.com/cloudfoundry/cloud_controller_ng/pull/569 Can you please take a look and comment on possible problems and missed use-cases? Regards, Hristo Iliev 2016-03-24

Please need your inputs on above mail chain query. Thanks

Thanks so much for bringing this up. This sounds like something that's probably easily fixable; though it would be great if we could have a bit more information about your directory layout. Would you

Hi Adrian, Thanks for your comment. I do have consul server in my cf-release deployment. Currently it’s database_z2/0 that is failing, however if I stop all running etcds on database_z1 and

I'm also interested in knowing when we can begin removing support for /VARZ from CF components. +bcc Jim Campbell (PM for Loggregator) Shannon Coen Product Manager, Cloud Foundry Pivotal,

The consul server cluster will be part of the cf-release deployment. This Diego deployment will be talking to the consul server cluster in the cf-release deployment. wrote: