brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: Externalised configuration in brooklyn.properties
Date Wed, 04 Nov 2015 17:40:26 GMT
Good ideas Richard. This workaround feels good enough to me for the short
term.

I agree the ideal would be to tie in to the dsl resolver - which actually
should be pretty easy to disentangle (see mail thread w Martin from a month
ago) - when props are accessed. That might be worth a few hours' spike.

Best
Alex
On 4 Nov 2015 07:59, "Richard Downer" <richard@apache.org> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message