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