On 3 Jun 2014, at 22:01, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> One obvious question with this scheme is: what happens when Y is
added,
> after the fact? The answer to this question depends on X. X must, in
> the same transaction, detect the addition of Y and decide what to do.
> Several actions are possible, depending on how X works and how its
> dependency on Y works. Options include automatically removing and
> rebuilding services with the new dependency, retroactively modifying X
> in some way so as to update it without stopping it, or simply ignoring
> the addition of Y, using a "reload-required" or similar state to
> indicate to the user that the running system is inconsistent with the
> stored model.
>
> I know we don't really have any APIs to directly facilitate these
> concepts, but this is a part of what the management SPI redesign is all
> about. In the new model, one will be able to express optional
> dependencies at a resource level rather than a service level.
Jeff Mesnil -- I'm curious how useful the internal notification stuff
you've added in the existing code will be for this use case. Prior to
that there was nothing at all that X could count on to become aware of
the later addition Y.
Notifications would work a the resource level.
Notifications for added/removed resources are emitted[1] at the end of the step that
adds/removes a resource in the MODEL stage.
So a resource X could register a notification listener on the resource Y's path
address.
When the Y resource is added, the listener will be notified and X would be notified of the
addition of Y and act accordingly.
If I understand the example correctly, when a resource X is added, it could check whether
the resource Y is already there and use it if that’s the case.
Otherwise, it would register a notification listener and postpone this execution until the
resource Y is added (with no guarantee it ever will).
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-266_WFLY-3159_notificatio...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/