Feature suggestion: specify environment variables that all containers should have from manifest.

Simon Johansson <simon@...>


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:
GELF_URI: host-appropriate-for-the-env:port
STATSD_URI: host-appropriate-for-the-env:port

That would then for apps be acceccible by simply


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

Join {cf-dev@lists.cloudfoundry.org to automatically receive all group messages.