[hab-director] per-service environment variables

[bookshelfdave]

Services can provide environment variables in the form of a TOML table which follows the following format:

[services.<origin>.<name>.<group>.<organization>.env]
ENV1="some value"
ENV2="some other value" 

Note: Environment variables MUST be specified as valid TOML strings.

For example:

# Specify custom JAVA_HOME and CLASSPATH environment variables
[services.core.java_app.somegroup.someorg]
start = "--permanent-peer"
[services.core.java_app.somegroup.someorg.env]
JAVA_HOME="/some/path/"
CLASSPATH="/some/classpath/foo.jar"

[services.core.rngd.foo.someorg]
start = "--permanent-peer --foo=bar"
JAVA_HOME="/a/different/path/"
# we don't specify CLASSPATH here, so it won't be set for core/rngd

Note: We current don't support "global" environment variables that are shared between services. This is definitely doable, but not in this PR.

for you @smith 🍰

[thesentinels]

@metadave, thanks for your PR! By analyzing the annotation information on this pull request, we identified @adamhjk, @davidwrede, @leonhartX and @fnichol to be potential reviewers

[reset]

This funciton never returns an Err case so just using Option is fine here

[bookshelfdave]

right, I gave it the same return type as the new function I added for consistency.

On Jul 18, 2016, at 1:33 PM, Jamie Winsor [email protected] wrote:

In components/director/src/config.rs:

@@ -98,23 +99,61 @@ impl Config {
fn lookup_service_param(toml: &toml::Value,
service_name: &str,
param_name: &str)

•                        -> Option<String> {
  

•                        -> Result<Option<String>> {
  

  This funciton never returns an Err case so just using Option is fine here

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bookshelfdave]

ok, lookup_service_param() has been updated to only accept string types, which makes the Result<Option<String>> the correct return type.

[reset]

Perfect!

[reset]

@metadave one minor comment but everything else looks like a great addition. Thanks for updating the docs!

[smith]

Shouldn't this be under a .env key?

[bookshelfdave]

fixed!

[bookshelfdave]

er, will push in a different PR

[smith]

I think this is probably a good addition, but we still have some work to do with handling environment variables.

This solution only works for the director, at runtime, with totally static data. If I need to set, say something like SSL_CERT_DIR=$(hab pkg path core/cacerts)/ssl/certs, I can't do it in the config here without hard-coding a specific version/release of cacerts.

The situations I can think of that we should be able to handle are:

• Specifying env vars at build time that will be loaded with hab pkg exec and hab sup start
• Specifying env vars that can be templated at run time in a hook.

You can do both of these pretty easily right now if you specify a run hook, but it might be nicer to have something available that you can use if you're just doing pkg_svc_run.

These are just considerations for building the features out. Your PR is fine and we can flesh out the other pieces later. Thanks!