[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    [Linux-ha-dev] Some thoughts about complex resources
From:       Lars Marowsky-Bree <lmb () suse ! de>
Date:       2004-11-10 10:37:38
Message-ID: 20041110103738.GX10311 () marowsky-bree ! de
[Download RAW message or body]

Good morning,

let me start with that I quite like the complex resources in general.
I'd hoped that this might be a place to put in plugins, and it in fact
turned out to be mostly true ;-)

The one thing I'm not entirely happy about is how they are currently
configured. Maybe it is in fact the best way of doing things, but then
maybe I need more thinking...

To quote from the group1.xml, which is probably the simplest testcase:

  <resources>
    <resource_group id="rsc1" priority="1.0">
      <resource id="child_rsc1" class="heartbeat" type="apache" priority="1.0"/>
      <resource id="child_rsc2" class="heartbeat" type="apache" priority="1.0"/>
      <resource id="child_rsc3" class="heartbeat" type="apache" priority="1.0"/>
    </resource_group>
  </resources>

I can see the reasoning here; at the same time, I'd have liked it if the
configuration didn't change the way or nesting level of how resources
are configured, so that the GUI which configures the resources doesn't
have to know.

My proposal would have looked something like this:

    <resource id="child_rsc1" class="heartbeat" type="apache" priority="1.0"/>
    <resource id="child_rsc2" class="heartbeat" type="apache" priority="1.0"/>
    <resource id="child_rsc3" class="heartbeat" type="apache" priority="1.0"/>
    <resource_group id="rsc1" priority="1.0">
      <resource id="child_rsc1"/>
      <resource id="child_rsc2"/>
      <resource id="child_rsc3"/>
    </resource_group>

ie, the complex object only references the pre-defined basic objects.

(Whether or not it 'claims' them completely so that some kinds of
dependencies may still be allowed directly to the resources or not may
be configurable or at least a per-complex type thing.)

I think this makes configuration more consistent and somewhat easier
readable.

Comments?

Now, incarnations and how they are configured. Neither approach
mentioned above is really elegant for them, is it? Neither explicitly
embedding them or referencing them. I had thought that they'd be
"regular" resources which "just" happened to have a couple of extra
magic parameters (max_incarnations, max_active_incarnations etc), but I
can see how that wouldn't work too well, or would it?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
[prev in list] [next in list] [prev in thread] [next in thread]