brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <>
Subject [GitHub] brooklyn-server issue #279: Allow to reference resol...
Date Fri, 09 Sep 2016 08:06:39 GMT
Github user ahgittin commented on the issue:
    I think this resolves and stores config too early.  We need to ensure the raw unresolved
values are given to the `JcloudsSshMachineLocation` (and a few other places).  See
    Can you check whether `ExternalConfigYamlTest` passes?  They are integration tests (probably
shouldn't be!) but I think would illustrate why we can't just resolve everything.
    The use case you introduce @grkvlt is useful.  I think we should handle this either by
ensuring we resolve each access eg in `buildTemplate` or by maintaining two maps in the code
path, `newItemConfigResolved` and `newItemConfigRaw` (instead of `setup`).
    Also agree we want a test for this and please undo the huge mad import order change (under
what ordering is the new one more sensible??).
    Note that the semantics flip once a location (or any adjunct or entity) is managed, `BrooklynObject.config().get()`
returns resolved values.  A more elegant but much bigger fix might be to create the `JcloudsSshMachineLocation`
early, pass it unresolved config, and then for it to call its own config at which point resolving
on access would be a sensible default.  This makes it more like entities (which tend to create
the thing they represent, as opposed to the parent creating the thing first which is what
`JcloudsLocation` is doing).

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message