[OCF]Updates Resource Agent API, Paths

Lars Marowsky-Bree ocf@lists.community.tummy.com
Mon, 4 Aug 2003 13:05:37 +0200


--Rgf3q3z9SdmXC6oT
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2003-08-01T21:14:20,
   Ragnar Kj=F8rstad <linux-ha@ragnark.vestdata.no> said:

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

Right, those are filenames under there.

> 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.

Does. You could have a RA which acts differently if called by multiple
names.

> 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.

OK, needs updating.

> 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 that the RM _can_ go search for them there. Just in the case of a
resource type being offered by multiple registries, we do not mandate
how the RM should decide which one to use (probably by asking the
user...).

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

We do want them to be read. See above.

> 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),

/usr/ocf/resource.d/nfs-utils/nfs

ie, the directory name is typically the name of the provider / package,
as explained. Maybe that is indeed a good example to put into the
document.


Sincerely,
    Lars Marowsky-Br=E9e <lmb@suse.de>

--=20
SuSE Labs - Research & Development, SuSE Linux AG
 =20
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur

--Rgf3q3z9SdmXC6oT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/Lj39udf3XQV4S2cRAjf+AJ4kjD+y1cNqxRjjrdx8RcpaT3XdJwCfZCc/
DWg5N+5pjcdE1kQb3C2QjfM=
=98PJ
-----END PGP SIGNATURE-----

--Rgf3q3z9SdmXC6oT--