From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lon Hohberger <lhh@redhat.com>
Date: Fri, 27 Apr 2007 13:51:55 -0400
Subject: [Cluster-devel] [RFC][PATCH] Unique resource name handling for
	rgmanager.
In-Reply-To: <1177689436.4027.49.camel@localhost>
References: <1177689436.4027.49.camel@localhost>
Message-ID: <20070427175154.GJ20650@redhat.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

So far, it's pretty good - the only thing I worry about is
group-reordering.  For example, if we do:

  <resources>
    <clusterfs name="foo" .../>
  </resources>
  <service name="1">
    <clusterfs ref="foo"/>
  </service>
  <service name="2">
    <clusterfs ref="foo"/> <!-- ref = 2 -->
  </service>

...and we delete service 1 and add service 3 below service 2, we'll end
up with a different reference number for service 2:

  <service name="2">
    <clusterfs ref="foo"/> <!-- ref = 1 now -->
  </service>
  <service name="3">
    <clusterfs ref="foo"/>
  </service>

If we were using the ref number to track instances of the clusterfs
resource on disk, then the ref number '1' would disappear out from under
service:2 when we delete service:1.

The patch looks right - except the way we decide 'refno'.  That scares
me :)

To expand on what you started, we can add an easy way to fix the
reordering problem by adding a 'refno' attribute in cluster.conf for
ref= tags.

That is, the reorder case above can be eliminated if we simply require a
specific index attribute when doing ref=.  For example:

  <service name="2">
    <clusterfs ref="foo" refno="2" />
  </service>
  <service name="3">
    <clusterfs ref="foo" refno="3" />
  </service>

Of course, this complicates cluster.conf parsing from rgmanager's
perspective, because now it has to keep track of indices (what if
someone forgot to add a refno?) - while expensive, this can't be
terribly difficult to do.

As an alternative, in order to avoid configuration changes as well as
adding new configuration options, we could very easily calculate hash or
CRC values based on configuration parameters and parent node attributes
(with some sort of conflict resolution if there's overlap, I guess) -
this would get us a position independent per-type identifier.  That is:

   service:2[6fc1]      (crc-16)
   service:2[fe13c0d3]  (crc-32)

-- 
Lon Hohberger - Software Engineer - Red Hat, Inc.