[OCF]Updates Resource Agent API

[Lars Marowsky-Bree]

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

Hi all,

after the good progress we have made on the RA API at OLS, I've checked
in the new versions to CVS.

You can see them at http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/

The following changes were made:
- Numerous rephrasings.

- License changed to FDL instead of OPL, as it had been repeatedly
  suggested.
 =20
- Decided to drop dependencies from the model for now, though they can
  still be had as vendor specific extensions, of course.

- The "monitor" action was dropped in favour of the "status" action from
  LSB.

  We also added a OCF_CHECK_LEVEL to specify the level of the check
  expected.
 =20
- It was decided to keep the OCF_RESKEY_ prefix for instance parameters.

Some changes I made to resolve conflicts which came up with those new
changes:

- Adapted the RA API metadata / DTD to reflect the changes above.

- I've taken the freedom to rename OCF_MONITOR_QOS_LEVEL to just
  OCF_STATUS_LEVEL. If anyone objects, I'll happily change it back ;-)
 =20
  I've also updated the metadata to support specifying multiple check
  levels with different timeouts in the metadata.
 =20
- The change we did with regard to the resource instance naming was
  inconsistent with the old meta-data. I've made it more consistent, and
  allowed the RA to suggest that some instance parameters must be unique
  within the resource type.

  I think this is a good idea, but we can also drop it.
 =20
- While we are passing in the resource name, I've added an environment
  variable to pass in the resource type, too. This may be useful for RAs
  which support multiple ones, and at least can't hurt.

- I've briefly messed with the 'status' exit status codes. Turns out
  status was different from the others anyway, but the set of exit codes
  for 'status' was really stupid. I've changed the meaning of 1 & 2. It
  is still LSB compliant, in that they signify errors, but slightly more
  useful ones.

  Please comment on this one.
 =20
- It also turns out that the status operation had no way of signalling
  that a service is cleanly stopped. I've added a note saying that we
  expect the exit code 3 to be returned in this case.

  (This is important, to differentiate at startup between an active, but
  broken resource instance from a not-running one. heartbeat and
  FailSafe do such verifications)

Still open:

- As the resource type is embedded in the resource metadata, should we
  stop mapping the resource type to the filename 1:1 and instead have
  the RM discover the installed resource types?
 =20
Please comment.


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

--p7S+EREVcBHk3zUG
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/KCcxudf3XQV4S2cRAvYgAJ9lxKEK8mE2NESHHskmSJfX+C7+KgCfYWFK
NijFgiqZ3rPufM07TrYHcU8=
=b1+M
-----END PGP SIGNATURE-----

--p7S+EREVcBHk3zUG--