Hi.
Note the following section, which is taken from a blueprint I have been
developing and is repeated there several times. Some parts have been
anonymised, but the idea should be clear:
shell.env:
HOST_NAME: $brooklyn:attributeWhenReady("host.name")
HOST_ADDRESS: $brooklyn:attributeWhenReady("host.address")
HOST_SUBNET_ADDRESS:
$brooklyn:attributeWhenReady("host.subnet.address")
XXX_FRAMEWORK_VERSION: $brooklyn:config("xxx.framework.version")
XXX_FRAMEWORK_BASEURL: $brooklyn:config("xxx.framework.baseUrl")
XXX_FRAMEWORK_URL: $brooklyn:config("xxx.framework.url")
XXX_FRAMEWORK_CONFIG: $brooklyn:config("xxx.framework.config")
XXX_CLUSTER_NAME: $brooklyn:config("xxx.cluster.name")
XXX_NODE_COUNT: $brooklyn:config("xxx.node.count")
YYY_BROKER_COUNT: $brooklyn:config("yyy.broker.count")
YYY_FRAMEWORK_VERSION: $brooklyn:config("yyy.framework.version")
ZZZ_FRAMEWORK_VERSION: $brooklyn:config("zzz.framework.version")
These are then used in the install.command and launch.command configuration
to generate shell commands to set up the software.
As you can see, a lot of these are simply straight transforms of the config
key name or sensor name from lower case with dots to upper case with
underscores, then populated with the config value or sensor value. Would it
make sense to have a config option (or even default behaviour) to do this
automatically for _all_ configuration and sensors on the SoftwareProcess
and derived entities?
Since there can be config keys and sensors with the same name, perhaps we
can namespace them with a prefix, such as CONFIG_XXX_NODE_COUNT and
ATTR_XXX_NODE_COUNT for example?
The other issue would be Map content, and perhaps List as well. in those
cases, something like CONFIG_KEY_NAME_ENTRY_ONE, CONFIG_KEY_NAME_ENTRY_TWO
for a Map with keys entry.one and entry.two, and CONFIG_KEY_NAME_0,
CONFIG_KEY_NAME_1 for a List with two entries.
One problem I can see is that it makes the environment we pass to shell and
SSH commands potentially quite large, and also we may pass in config keys
with potentially sensitive information such as passwords that could then be
viewed by any admin user inspecting running process environments. There
could perhaps be a default blacklist of key name fragments that will be
used to filter the list, as well as a configurable list of exclusion
wildcards?
Do people think this would be a useful addition to Brooklyn? I have started
on an implementation, but would like some feedback before I move forward.
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
