By popular demand, we now have a way to make config *not* be inherited!
https://github.com/apache/incubator-brooklyn/pull/483
This fixes an "on-fire" which can occur with one of the website
tutorials; now we write:
public static final ConfigKey<QuorumCheck> UP_QUORUM_CHECK =
ConfigKeys.builder(QuorumCheck.class,
"enricher.service_state.children_and_members.quorum.up")
.defaultValue(QuorumCheck.QuorumChecks.atLeastOneUnlessEmpty())
* .inheritance(ConfigInheritance.NONE)*
.build();
It's useful anywhere you want to block a config key on an entity from
being applied to the entities descendants -- paths and software-process
versions being another example. (For SoftwareProcess, /cc @sjcorbett
@andreaturli. There we probably want to define the key on the class to
overwrite the common one and be non-inheritable, since other places we
apply the standard version to a cluster.) All I've done here is apply
it to QuorumChecks to fix the tutorial problem.
The default behaviour for keys is unchanged, so no one should be
affected. but several people have noted that the need for inheritance
becomes much weaker with the rise of yaml and specs. if we want to
modify/inspect/log this behaviour we can do so fairly easily in
EntityConfigMap. We could for instance add a legacy warning everywhere
that we rely on implicit config inheritance (I don't think there are
that many places) and then explicitly mark those which do require it as
"always".
You'll also note that the ConfigInheritance model supplies a method so
there is the possibiliity if we need to that custom patterns of
inheritance could be defined. I'm thinking particularly when we make
relationships a first-class concept. This isn't to encourage such
changes at this time -- the constructor is private -- but rather to make
it easy to track where inheritance checks are made.
Best
Alex
