I have a few customers that grab that instance index to aid in monitoring
toggle quoted messageShow quoted text
and logging and to self identify in certain situations. Is there an issue
with continuing to expose the instance index?
I don't know anything about v2 vs v3 apis. Would VCAP_APPLICATION continue
to work for apps pushed using the v2 api and only have this new value if
pushed using the v3 api?
On Mon, May 2, 2016 at 2:49 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).
The PHP build pack does this too.
As long as that info is exposed somewhere, it would be OK.
On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.
That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.
On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:
We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.
Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.