brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <>
Subject [GitHub] brooklyn-server issue #281: Prevent VanillaSoftwareProcess commands from bei...
Date Thu, 15 Sep 2016 11:31:16 GMT
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.

View raw message