Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/279
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 https://github.com/apache/brooklyn-server/pull/194.
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 [email protected] or file a JIRA ticket
with INFRA.
---
