Merge lp://qastaging/~mew/juju-deployer/option-from-file into lp://qastaging/~gandelman-a/juju-deployer/trunk

Matthew, this generally works good. Just wondering if the read()s should also strip() trailing newlines to keep them from showing up as part of the config value in the environment?

Good point. It's probably better to filter the text so that all of the anti-json characters are escaped. I'll look into doing that.

Sorry, I should have thought about that a bit more thoroughly. Escaping isn't the problem, is it?

The intention of include-file and include-base64 is to provide a way to pull in values that may be built externally or have complex internal structure that would be difficult to maintain inside a JSON (or YAML) file.

In the example I mentioned above, "vhost_https_template" option from the apache2 charm is a jinja2 templated httpd.conf-style configuration hunk. It's usually hand-maintained. I could also imagine something like a crontab file being included this way, and I believe cron is particular about having a trailing newline.

Sorry for the delay. I had meant to test to use case I had in mind but haven't gotten to it yet. Looking at it again, I think this is generally okay.

I was thinking of a case where i'd like to store a passwd outside of the charm in a file, eg:

service1: {
 options: {
   user: adam
   passwd: include-file:///home/adam/.services/passwd
 }
}

and have the charm do something like:

service-manager user-create username=$(config-get username) password=$(config-get passwd)

OR

user = subprocess.check_output(['config-get', 'user'])
passwd = subprocess.check_output(['config-get', 'passwd'])
utils.manager(username=user, passwd=passwd)

I think this would be okay in both cases. The bash case would strip out newlines, anyway and the python case should probably cleaning up stdout anyway. I'll give this branch just another test one more time otherwise LGTM.