Dependent resources

Heiko W.Rupp hrupp at redhat.com
Mon Oct 24 16:09:21 UTC 2011


Hi,

I was recently in a call with a not to be named customer and I want to share some outcome of the
call, as this opens an interesting perspective on future architectures of RHQ. 
We have been thinking about "Relation ship service in the past" (see e.g. http://rhq-project.org/display/RHQ/Design-Relationship+Service),
but not in this extend.

The customer has a strong demand to be able to start and stop apps with their dependencies. The following graphic illustrates this:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dep_tree.png
Type: image/png
Size: 36602 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20111024/f5efb421/attachment-0001.png 
-------------- next part --------------


Before the Application (s) on AS can start, the compute grid must be started,
as well as the DB and the load balancer. Also in compute grid and the AS
also depend on some MQ broker. For app3 to start, the grid + MQ needs to
be present and for app4, only MQ.
Also for stopping the order needs to be reversed (with checks about what may
still be needed, but this is not the subject of this email).
Veritas cluster manager is able to produce such a graph as displayed above
and also to hande this dependencies.

RHQ actually already provides the biggest part of this puzzle: triggering start +
stop operations on the managed resources.

We got the idea that they could actually implement the triggering logic by implementing
a server plugin, that reads an external file that hosts the dependency graph and then
triggers the start and stop operations in turn.

As server plugins have "controls", there are even "buttons" in the UI to trigger those start
and stop "meta-operations".
But: 
- it is not intuitive to start app4 to go to Admin->ServerPlugins->....
- ops people (for the apps) may not even have access to the Admin section of RHQ

So we would need a way to associate such an operation of a server plugin to an 
actual resource, so that the operator would go to App4, operations tab and issue a 
"start with dependencies" operation, that goes to the server plugin, which then does
the work of scheduling all the needed start operations on plugin level (in turn and with
waiting for results).

There are now several options on how to represent the metadata for this
- server plugin could indicate which operations it would offer for what resource types
- agent plugins would get a new <server-operation> section that contains the name of the
  server plugin + metadata about parameters etc.

In any case the name of the resource where the server-operation is triggered from needs to 
be passed to the server plugin, so that it can go to the right entry in the table and do its work.


-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Geschaeftsf?hrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera



More information about the rhq-devel mailing list