VCAP_APPLICATION in the V3 Cloud Foundry API


Nicholas Calugar
 

Hi CF-Dev,

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:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

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.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


john mcteague <john.mcteague@...>
 

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>
wrote:

Hi CF-Dev,

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:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

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.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Daniel Mikusa
 

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..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

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>
wrote:

Hi CF-Dev,

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:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

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.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Mike Youngstrom
 

I have a few customers that grab that instance index to aid in monitoring
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?

Mike

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..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

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>
wrote:

Hi CF-Dev,

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:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

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.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Sabha
 

Agree with Dan.

Currently most APM vendors use the VCAP_APPLICATION env variable for
mapping and keeping track of a specific instance using the instance guid,
instance index, app guid fields. Changing it would affect the buildpacks
and extensions.

Sample for AppD APM:
default_node_name: $(ruby -e "require 'json' ; a =
JSON.parse(ENV['VCAP_APPLICATION']);

puts \"#{a['application_name']}:#{a['instance_index']}\"")
Some of these complex expressions might become simpler, as long as the
values still come through with different names.

So, as long as the current set of values continue to exist and either in
flat or easy to grab from ENV, I am okay with that.

thanks,
Sabha

On Mon, May 2, 2016 at 2:19 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I have a few customers that grab that instance index to aid in monitoring
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?

Mike

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..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

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>
wrote:

Hi CF-Dev,

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:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

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.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick
--
Sabha Parameswaran
Platform Engineering, Cloud Foundry
Pivotal, Inc.
m: +1 (415) 244-5554


Nicholas Calugar
 

Thanks for all your input. Upon seeing how the buildpacks use VCAP_APPLICATION, I’m thinking we want to leave it as is and potentially add a few new top level environment variables.

CF_APP_GUID

CF_APP_NAME

CF_PROCESS_GUID

CF_PROCESS_TYPE

With the already present

CF_INSTANCE_INDEX, we could encourage buildpacks to build the identifier using all ENV variables:

CF_APP_NAME:CF_PROCESS_TYPE:CF_INSTANCE_INDEX

Nicholas Calugar

Cloud Foundry API Product Manager

Pivotal Software, Inc.

On Mon, May 02, 2016 at 2:36 PM Sabha Parameswaran

<
mailto:Sabha Parameswaran <sabhap(a)pivotal.io>
wrote:
Agree with Dan.

Currently most APM vendors use the VCAP_APPLICATION env variable for mapping and keeping track of a specific instance using the instance guid, instance index, app guid fields. Changing it would affect the buildpacks and extensions.

Sample for AppD APM:

default_node_name:

$(ruby -e "require 'json' ; a = JSON.parse(ENV['VCAP_APPLICATION']);

puts \"#{a['application_name']}

:#{a[

'

instance_index

'

]}\

"

"

)

Some of these complex expressions might become simpler, as long as the values still come through with different names. 

So, as long as the current set of values continue to exist and either in flat or easy to grab from ENV, I am okay with that.

thanks,

Sabha

On Mon, May 2, 2016 at 2:19 PM, Mike Youngstrom

<
mailto:youngm(a)gmail.com
wrote:

I have a few customers that grab that instance index to aid in monitoring 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?

Mike

On Mon, May 2, 2016 at 2:49 PM, Daniel Mikusa

<
mailto: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..).  

Ex:  
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague

<
mailto:john.mcteague(a)gmail.com
wrote:

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

<
mailto:ncalugar(a)pivotal.io
wrote:

Hi CF-Dev,

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:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

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.

"CF_APPLICATION_PROCESS": {

  "space": {

    "guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",

    "name": "ncalugar-a1"

  },

  "application": {

    "guid": "<v3-app-guid>",

    "name": "nickdora"

    "version": "<app-version-guid>"

  },

  "process": {

    "guid": "<v3-proc-guid>",

    "type": "web",

    "ports": [8080,8081]

  },

  "route_mappings": [

    {

      "guid": "<v3-route-mapping-guid>",

      "uri": "
http://nickdora.a1-app.cf-app.com
",

      "port": 8080

    },

    {

      "guid": "<v3-route-mapping-guid>",

      "uri": "
http://nickdora.a1-app.cf-app.com/admin
",

      "port":"8081"

    }

  ],

  "limits": {

    "fds": 16384,

    "mem": 1024,

    "disk": 4096

  }

}

Thanks,

Nick

--

Sabha Parameswaran

Platform Engineering, Cloud Foundry

Pivotal, Inc.

m: 
tel:%2B1%20%28415%29%20244-5554