Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@aledsage good observations
firstly yes this is complicated and we should avoid people needing to know
about it in most cases -- eg use the policy approach, and/or come up with new
bash entities which allow setting environment variables per command (although
that wouldn't help in this instance) and/or putting arbitrary numbers of
commands in an effector (i've been thinking of doing this in a map, using initd
sequencing convention or precondition/postcondition markers).
very elegant idea to allow config keys to define their own strategy, also
it allows us to do resolution/merges for lists if we ever needed that. i think
my refactor allows this (whereas previously it was not allowed). but i think
it just moves the complexity, and in any case it wouldn't solve the problem
that this PR has broken users' blueprints.
but i think we should continue to have default/standard/simple inheritance
modes -- no major change there -- it's just that the current semantics of
`NONE` are wrong for most cases this PR set it (`NOT_REINHERITED` vs
`NEVER_INHERITED`). i think the new `StandardInheritanceModes` are pretty
clear to a first approximation, and it's only if you are at a weird edge case
(which we'd try to avoid) that you'd need to dig deeper, and if you do dig
deeper the separation of inheritance attributes i think would be clearer now.
(though it's still so fresh it could probably be improved.)
---
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.
---
