Hihi.

In our environment we provide two different CF installations, each of them resides in a different VLAN. Apps in each environment are interested in different services, Graphite, statsd, sentry etc. These services all have legs in the two different CF VLANs. Hence the config needed for the same app in two different environments are different. Eg. "log-sink-502net.tools.pe.domain.com:12201" vs "log-sink-503net.tools.pe.domain.com:12201" for GELF for instance.

user provided services can be a bit tricky to parse, and not always appropriate

{
"user-provided": [
{
"name": "GELF-Input",
"label": "user-provided",
"tags": [

],
"credentials": {
"url": "log-sink-503net.tools.pe.domain.com:12201"
},

Therefore I would like to propose to add functionality to expose certain ENV variables trough the manifest.
Similar to the feature that is pending where operators of CF can specify extra headers to add for RTR logs this would be useful in a curated environment where certain assumptions have been made in collaboration with different teams. Eg. "If you use GELF, please use the GELF_URI env variable to get the correct URI instead of specifying in config files".

This simplifies operations for us[1] as the contract is clear and developers[2] doesnt need to know about the pesky network/environment details.

I was thinking something along the lines off:
properties.dea_next.extra_env:
GELF_URI: host-appropriate-for-the-env:port
STATSD_URI: host-appropriate-for-the-env:port
WHO_YOU_GONNA_CALL: GHOST-BUSTERS!

That would then for apps be acceccible by simply

ENV['GELF_URI']

Ive had a quick lookover dea_next and it seems like a rather simple feature to implement. I would be happy to send a PR if you think this would be a good idea.

[1] If I've had a penny for everytime we need to change something, people miss their emails, tcpdump shows that some apps are still using the old service, and vast amounts of time goes into hunting the correct people down to make sure we are not pulling the rug under them.

[2] If I've had a penny for everytime ive had to explain why in the world we have different endpoints for same service. And we dont really want to run a split horizon DNS server :)

simon,

are you aware of the environment variable groups feature [1]? does that
capability address this need to consistently expose env variables to all
apps across the system?

[1]
http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#evgroups

On Wed, Aug 26, 2015 at 7:25 AM, Simon Johansson <simon(a)simonjohansson.com>
wrote:

Hihi.

In our environment we provide two different CF installations, each of them
resides in a different VLAN. Apps in each environment are interested in
different services, Graphite, statsd, sentry etc. These services all have
legs in the two different CF VLANs. Hence the config needed for the same
app in two different environments are different. Eg. "
log-sink-502net.tools.pe.domain.com:12201" vs "
log-sink-503net.tools.pe.domain.com:12201" for GELF for instance.

user provided services can be a bit tricky to parse, and not always
appropriate

{
"user-provided": [
{
"name": "GELF-Input",
"label": "user-provided",
"tags": [

],
"credentials": {
"url": "log-sink-503net.tools.pe.domain.com:12201"
},

Therefore I would like to propose to add functionality to expose certain
ENV variables trough the manifest.
Similar to the feature that is pending where operators of CF can specify
extra headers to add for RTR logs this would be useful in a curated
environment where certain assumptions have been made in collaboration with
different teams. Eg. "If you use GELF, please use the GELF_URI env variable
to get the correct URI instead of specifying in config files".

This simplifies operations for us[1] as the contract is clear and
developers[2] doesnt need to know about the pesky network/environment
details.

I was thinking something along the lines off:
properties.dea_next.extra_env:
GELF_URI: host-appropriate-for-the-env:port
STATSD_URI: host-appropriate-for-the-env:port
WHO_YOU_GONNA_CALL: GHOST-BUSTERS!

That would then for apps be acceccible by simply

ENV['GELF_URI']

Ive had a quick lookover dea_next and it seems like a rather simple
feature to implement. I would be happy to send a PR if you think this would
be a good idea.

[1] If I've had a penny for everytime we need to change something, people
miss their emails, tcpdump shows that some apps are still using the old
service, and vast amounts of time goes into hunting the correct people down
to make sure we are not pulling the rug under them.

[2] If I've had a penny for everytime ive had to explain why in the world
we have different endpoints for same service. And we dont really want to
run a split horizon DNS server :)

--
Thank you,

James Bayer

Why, yes, yes it does.

Somehow missed this feature. Thanks!

//Simon