Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@ahgittin @grkvlt @sjcorbett @neykov This all sounds scarily complicated to
describe to users, with the actual behaviour of inheritance for a given
parent/child entity pair being unclear to the user until they dig into that
entity's definition.
---
I worry about the pattern of using the `pre.install.command` on the parent
entity. Whether that works depends on the child entity. If the child entity has
its own value for `pre.install.command` then the parent's value would have been
ignored (including in Brooklyn 0.9.0).
I can see that your suggestion of "conflict-resolution-strategy" being
supplied by the caller would "fix" that, but I think it would be extremely hard
to use.
---
Maybe I'm missing something in your proposal, but I think there is a
fundamental problem that makes it hard to use: the inheritance mode /
conflict-resolution mode is being defined in the config key declaration; but
the user of the blueprint is only thinking about supplying the value in the
`brooklyn.config` seciton.
---
To make this feasible to use/understand in YAML blueprints, I wonder if we
really need the feature discussed in the email thread "[PROPOSAL] separate
shell.env per command".
That proposal could be extended to support something like that below (but
with more sensible key/values for "inherited_by_children",
"conflict_resolution", etc)?
```
- type: org.apache.brooklyn.entity.stock.BasicApplication
brooklyn.config:
pre.install:
command: |
sudo yum install -y my-favourite-monitoring
inherited_by_children: true
conflict_resolution: prefix
```
---
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.
---
