Hi Lars,
On Wed, Sep 05, 2012 at 11:41:17AM +0200, Lars Marowsky-Bree wrote:
> On 2012-09-04T19:20:23, Alan Robertson <[email protected]> wrote:
>
> > I will likely write a monitor-only resource agent for web servers. What
> > would you think about calling it from the other web resource agents?
>
> Sharing code - in this case, the monitor-via-network of the http agents
> - seems to make sense, yes.
>
> > This resource agent will not look at any config files, and will require
> > everything explicitly in parameters, and will not know how to start or
> > stop anything. This would be for my new monitoring project, of course
> > ;-). But it could then be called by all the HTTP resource agents - or
> > used directly - for example by the Assimilation project.
> >
> > This would be a slight but useful bending of OCF resource agent APIs.
>
> I am not sure I'd go by making this OCF RA.
>
> We've - for other reasons, like monitoring the services within a VM -
> started to look at wrapping up the icinga/nagios probes so that they can
> be configured and called by the cluster. My current thinking is that
> they might be best handled via a new resource agent class.
>
> (Pseudo-configuration:
>
> primitive vm1 ocf:heartbeat:VirtualDomain
> primitive vm1-httpd icinga:httpd \
> params ip="192.168.2.1" port="80"
> group vm1-service vm1 vm1-httpd
>
> With some special code in the PE to make it understand that it can't
> just restart vm1-httpd, but would need to tackle the whole group
> atomically, etc.)
How about a new element. Something like
primitive vm1 ocf:heartbeat:VirtualDomain
require vm1 web-test dns-test
primitive web-test monocf:heartbeat:http-mon \
params ip="192.168.2.1" port="80"
primitive dns-test monocf:heartbeat:named ...
The "require" would imply that the resource vm1 requires
monitors of web-test and dns-test to succeed, in addition to its
monitor (if defined). Monitor ops of web-test and dns-test will
run only on the node where vm1 is started. They could in also
get the environment (parameters) of vm1.
monocf may be just like ocf, sans start and stop operations.
That would make all ocf RA elligible for this use.
We could derive more classes from monocf, i.e. wrappers for
various monitor solutions.
I suppose that this would be relatively straightforward to
implement.
Thanks,
Dejan
> I'm curious, have you looked into re-using those probes already? I admit
> we're still at the evaluation stage so we might have missed problems
> with the approach.
>
>
> Regards,
> Lars
>
> --
> Architect Storage/HA
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer,
> HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
