I haven't yet looked at the DSL resolver, but I have identified a possible issue with this approach.
The external config supplier spec dictates that the config supplier is checked every time the configuration is referenced. However, the approach I have used will resolve the configuration exactly once, during management context initialisation. Are there any other places where I could "hook in" to do this? I'm looking at parts related to Entity, but that has its own problems: unless done in exactly the right place, it still wouldn't match the behaviour that configuration needs to be resolved when the blueprint is instantiated. It could end up in the opposite extreme e.g. configuration is resolved every time the entity does getConfig(), which breaks our guarantee that entity configuration doesn't change during runtime except in special conditions. Thanks Richard. On 4 November 2015 at 17:40, Alex Heneveld <[email protected]> wrote: > 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. >>
