[OCF]Updates Resource Agent API, Paths

[Ragnar Kjørstad]

On Fri, Aug 01, 2003 at 04:48:32PM +0200, Lars Marowsky-Bree wrote:
> On 2003-08-01T09:35:40,
>    James Bottomley <James.Bottomley@steeleye.com> said:
> 
> > I agree it could be viewed as redundant, but from the first draft of the
> > SPEC it provides clear instructions to the implementor, so I vote for
> > keeping it for that reason.
> 
> OK, I'm convinced. I've dropped the TODO.
> 
> The draft looks reasonably well now.
> 
> Any other comments, wording, phrasing etc?

In section 3.2, there is an example directory-structure.

Example directory structure:
        FailSafe -> FailSafe-1.1.0/
        FailSafe-1.0.4/
        FailSafe-1.1.0/
        heartbeat -> heartbeat-1.1.2/
        heartbeat-1.1.2/
        heartbeat-1.1.2/IPAddr
        heartbeat-1.1.2/IP -> IPAddr


(Actually IPAddr and IP are not directories, right?)

If the name of the resource-type is included in the metadata, and the
name must be the same as the script-name, it doesn't make much sense to
have symbolic link from IP to IPAddr.

Another comment is that for readers of the spec not familiar with
heartbeat it may not be obvious that "IPAddr" is in fact a
resource-script - not a directory.

Last, as long as the standard doesn't dictate where an RM should search
for RA's (what subdirectories), I have a problem with seeing the value
of dictating that RA's should be located in that directory at all!

So, please remind me; why should we mandate that heartbeat put's 
its private RAs in /usr/ocf/resource.d/ when nobody else is 
supposed to read them?


Now, what _would_ be really useful, is mandate where ha-enabled software
should put their own RAs. E.g. what if the maintainer of nfs-utils
wanted to include the OCF-compliant script - where is he supposed to put
it? One possiblity would be directly in /usr/ocf/resource.d/, without
the subdirectories, another would be a general subdirectory that doesn't
belong to any specific RM (/usr/ocf/resource.d/general), and a third
possibility would be to say that /etc/init.d/ is the proper place. At
least the last alternative would be very controversial, so maybe the
location of the script should be unspecified for this version of the
API.



-- 
Ragnar Kjørstad