brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Externalised configuration in brooklyn.properties
Date Wed, 04 Nov 2015 15:59:14 GMT
All,

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 brooklyn.properties. 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
this.

*Where to implement it*

brooklyn.properties 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
have.

In fact resolving the configuration at this stage is actually
impossible, because the configuration resolvers are configured in
brooklyn.properties! Therefore you must have loaded
brooklyn.properties, 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 brooklyn.properties 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 brooklyn.properties 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
over-complicated.

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?

Thanks
Richard.

Mime
View raw message