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" <[email protected]> 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. >
