The apiserver, listener, shredder, analyzer all produce standard Go metrics which really don't tell you much as to the "health" of hm9000 other than the processes are up. The metrics that are

Hi Simon, We use OpenStack Swift with Keystone v3 and a non-default domain. I'd just like to confirm you're planning to support that configuration too? Regards, Dies Koper Fujitsu Sent: Wednesday,

The CF CLI team just cut 6.18.1. Binaries and link to release notes are available at: https://github.com/cloudfoundry/cli#downloads I have met some of you at the CF Summit in Santa Clara this week.

Maybe you should contact the pivotal support. https://support.pivotal.io/ wrote:

We're currently in the middle of the CF summit and during our presentation about the 5 years of Cloud Foundry in Rakuten we shared how we (ab)use the stack mechanism to provide application placement

Hi I am deploying Cloudfoundry on vSphere, I am getting some issues configuring PCF autoscalling using DEA. Has anybody encountered this issue ever ? If so can anybody please share ?

Ah, gotcha. +1 to that.

Agree on all counts. We've already suggested vendoring the gems inside the buildpack to ensure they're there on the staging container. I'm now suggesting that the bin scripts just can't find the

It's not an issue of pointing to the gems. The build pack runs (staging) in it's own container. The container is completely isolated from the DEA or Diego Cell where it's running. You can't access

Thanks DHR Team. Yes your correct like the required gem is not available in staging container stack. but these stacks are pre packaged in cf release. Not sure how we can do this Gem.path update for

Thanks a lot DHR team.. Let us try out this approach . Regards Lingesh M

So I think your problem is that your gems are on the DEA at staging time but aren't being found by the Ruby layer, right? If so the normal approach is to point to them via an env Var (eg BUNDLE_PATH,

You could change the config/repository.yml to point to a DNS name on your network. Then build out one or more local repositories on your network using the Java-buildpack-dependency-builder:

Hi Cloudfoundry , In java-buildpack ,*https://download.run.pivotal.io <https://download.run.pivotal.io> *URL is used for default_repository_root for all binaries , but this URL may not be accessible

not an issue .Thanks Dan !!!

You can take a look at https://github.com/pivotal-cf/pcfdev. Thanks wrote:

OK, my fault. I misunderstood what you're trying to do here. I was thinking that your application needed the gems, but it's your build pack that needs them. You originally said... because of few

Hi all, sorry in advance of the maybe naif question. I was wondering if I could find somewhere an all-In-One Virtual Machine with the last version of CF like openshift origin. thank you in advance

yes Dan, we have used below commands to package the buildpack . bundle install bundle exec rake package version=custom-java-buildpack after that we will take the zip and create a offline buildpack

yes, there has been a typo. Thank you for pointing out ! The correct CVE number is : *CVE-2016-3084* Thanks, Sree Tummidi Sr. Product Manager Identity - Pivotal Cloud