Github user aledsage commented on the issue:
    @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
          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 or file a JIRA ticket
with INFRA.

Reply via email to