Hi all, If you are familiar with the proposed Elastic Clusters feature narrative (or even if you're not), I welcome you to take a look at the below proposal for Consul-based service discovery for

I tried v231. Unfortunately, same issue.

Tracked down the issue, route_emitter instance had disappeared. Reviewing https://docs.cloudfoundry.org/concepts/diego/diego-components.html bosh vms of diego deployment, did not list a route_emitter.

Hi, all, Quick reminder of the CAB call next Wednesday, April 13th @ 8a PDT. All info in

Would solution 2 allow/work with a system domain? Solution #2 means api.domain is now taken so there could be no other app deployed to api.domain. Application developers may not be happy with

Thank you very much George & others who have helped me. Really appreciate it! Ricky Yunata Please consider the environment before printing this email

Are you tired of cherry-picking rootfs CVE commits? Do you integrate against Diego? Are you looking to shorten your rootfs patch to prod timelines? Well do we have some good news for you! As of

CF 230 Developer get error above for an existing application. I check another application, same error. I deploy a new application successfully, same error. bosh vms look fine. bosh cck looks fine. cf

Thanks for the responses Mike. See inline: To be clear, I think we're happy to test third-party agent in our CI Adding thirdparty agents to the CI pipeline will help. But, if there is ever a

Just chiming in real quick: the specific line of code that displayed that the panic is showing comes from

Yes like James said, assuming a Consistent/Service Scheduler is running in alongside our High Availability Scheduler, you could run databases like PostreSQL and Redis. They would use network attached

Yeah. I can try. Before that can I know cause of failure for this one. Bcz it is the current deployment we are having. We want to know what exactly went wrong with it. Just curious in debugging it.

Hi Barath, That release is over a year old. Is there any chance you can upgrade to a newer release? Jim -- Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963

Hi Jim Its version 206 Bharath

nic, if you look at this section of the doc [1] it discusses "Reattachable Volumes" which are similar to EBS volumes attaching to EC2 instances without allowing multiple instances to be bound to the

Hi Bharath, This looks like it might be older code. What version of Cloud Foundry are you running? Thanks, Jim -- Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963

Responses inline ... To be clear, I think we're happy to test third-party agent in our CI pipelines to ensure they'll continue to work. I think this addresses your "breaking change" point in a very

What's even weirder is the GET request to /login seems to do the right thing, but POST to /oauth/token gets translated to a request for uaa.cisco.com. The error is coming back from the gorouter, so

Hi, Can you please share your deployment manifest. There is something strange going on because for some reason UAA requests are being routed to *uaa.cisco.com <http://uaa.cisco.com/> instead of

The main concerns I have is: * Maintaining Compatibility: If a buildpack were to make a breaking change it may be complex to know that a vendor must upgrade its integration before the user can