brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Externalised configuration in
Date Wed, 04 Nov 2015 15:59:14 GMT

Alasdair Hodge recently contributed support for "externalised
configuration", where a blueprint can indicate that a value is to be
loaded from an external store rather than being coded directly. This
is particularly useful to prevent plain-text passwords being placed in
blueprints, but it has many uses.

It's not valid outside of blueprints however. I would like to be able
to use it on configuration stored in I've been
investigating options for doing this and I would like to share what I
have discovered and see what the consensus is for how to implement

*Where to implement it* is loaded by the BrooklynProperties class
(surprisingly). On first inspection this would be a good place to
resolve the configuration; however resolving the configuration
requires a reference to a management context, which this class doesn't

In fact resolving the configuration at this stage is actually
impossible, because the configuration resolvers are configured in! Therefore you must have loaded, and configured a management context, before you
can resolve the configuration.

My next attempt was to implement it in the constructor of
AbstractManagementContext - at the end of the constructor (crucially,
after has been loaded, and the external config
supplier registry has been set), the configMap is transformed and all
config resolved. This does appear to be usable.

*How to refer to external config*

In the YAML blueprints this is relatively easy, as there is already a
framework for parsing the YAML and a DSL that can be extended to add
the new configuration lookup. For there is no such
thing - every property value is a string literal.

Ideally we'd use the same DSL as the YAML parser, but this could be a
complex solution, since the DSL parser is embedded into the deployment
plan parser. We could write a new parser, but that seems to be

For the moment I have taken a very simple approach - if the property
value matches *in its entirety*
"$brooklyn:external:supplierName:keyName" then an external config key
will be made.

This seems to be working. It's familiar to the DSL user, but it's also
different enough that it could cause confusion. It's also not really
flexible enough - it can replace the *whole* value with something
looked up from storage, but it's not possible to mix plain text with
multiple lookups, as could be done in YAML.

What do people think?


View raw message