[
https://issues.apache.org/jira/browse/WHIRR-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204947#comment-13204947
]
David Alves edited comment on WHIRR-347 at 2/9/12 10:13 PM:
------------------------------------------------------------
bq. Command-line options override those in the properties file (see statement
in http://whirr.apache.org/docs/0.7.0/configuration-guide.html), so your
precedence order needs changing I think.
I did not change this, I just mentioned that order because the code suggests it
(args are parsed and then the props file is added), if it was in reverse order
it still is with this patch.
bq. In whirr-cli-defaults.properties could we have
whirr.provider=${env:WHIRR_PROVIDER} rather than
whirr.provider=${sys:WHIRR_PROVIDER} and avoid passing them as system
properties from the script?
I avoided using env variables on purpose. My though was that i an env variable
is set it is still used, if not then the rc files are used. Just using the rc
files thus avoids setting unnecessary env variables. I can change that but the
overriding mechanism (env overrides rc) will then cease to work, which might
not be a bad thing, what do you think?
wrt to documentation, you mean add something to the site? will do!
wrt to testing I thought about it but was unsure exactly what to test since all
that's happening is that whirr reads a file that sets some variables if they
are not present in env. Moreover unit tests already failed a lot until i got it
right which gave me some confidence. any test suggestions?
was (Author: dr-alves):
??Command-line options override those in the properties file (see statement
in http://whirr.apache.org/docs/0.7.0/configuration-guide.html), so your
precedence order needs changing I think.??
I did not change this, I just mentioned that order because the code suggests it
(args are parsed and then the props file is added), if it was in reverse order
it still is with this patch.
??In whirr-cli-defaults.properties could we have
whirr.provider=${env:WHIRR_PROVIDER} rather than
whirr.provider=${sys:WHIRR_PROVIDER} and avoid passing them as system
properties from the script???
I avoided using env variables on purpose. My though was that i an env variable
is set it is still used, if not then the rc files are used. Just using the rc
files thus avoids setting unnecessary env variables. I can change that but the
overriding mechanism (env overrides rc) will then cease to work, which might
not be a bad thing, what do you think?
wrt to documentation, you mean add something to the site? will do!
wrt to testing I thought about it but was unsure exactly what to test since all
that's happening is that whirr reads a file that sets some variables if they
are not present in env. Moreover unit tests already failed a lot until i got it
right which gave me some confidence. any test suggestions?
> Support provider-independent environment variables for cloud credentials
> ------------------------------------------------------------------------
>
> Key: WHIRR-347
> URL: https://issues.apache.org/jira/browse/WHIRR-347
> Project: Whirr
> Issue Type: Improvement
> Reporter: Tom White
> Assignee: David Alves
> Fix For: 0.8.0
>
> Attachments: WHIRR-347.patch, WHIRR-347.patch
>
>
> Adrian suggested that we support WHIRR_PROVIDER, WHIRR_IDENTITY,
> WHIRR_CREDENTIAL environment variables. This would allow users to set them
> for any cloud they are using.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
