[OCF]Updates Resource Agent API

[Lars Marowsky-Bree]

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

On 2003-08-01T20:27:33,
   Ragnar Kj=F8rstad <linux-ha@ragnark.vestdata.no> said:

> I also agree that there should be an error-code for invalid arguments,
> and probably that the exit-codes should be common with the other
> actions.=20
>=20
> Is that what you refered to by stupidity?

Yes, exactly that ;-)

> Not so sure I agree with the proposed solution though - I think changing
> the meaning of exit-codes is most unfortunate.

They aren't exactly changed. They still imply errors.

> One alternative would be to leave exit-codes 1 and 2 as they were, and
> add a new one (5) for invalid arguments. Still, this is far for perfect.

That's not possible, we can't add exit status codes there, we'd need to
use 150-199.

> In general, I think this is a difficult question, and it's just a matter
> of finding the least painful solution.=20

Yes. I still like my approach the best. At least "1" is still the proper
code - it's used as the generic error code for status, and we are really
just interpreting 'pid file exists' as "something still remains which
shouldn't be there", that's quite in line with best current practices.

Yes, redefining "2" as 'invalid or excessive arguments' is probably not
quite acceptable.

> Let me just add one more thing: This problem has nothing to do with
> clusters. So ideally it should be solved in LSB.

True. But what do we do in the meantime?

We _could_ in the meantime use a 'monitor' action which was exactly like
the status action _except that it had sane exit status codes just like
any other action_. That would probably be the cleanest approach...

> Do any of you have contacts in the LSB working-group that we could use
> to find out what their prefered solution would be? Basicly I don't
> care what it is, if only the problem can be fixed in a way that would
> enable compability with LSB.

I'll put our LSB representative into the loop and ask him.

> > - 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.
> The way I read the spec exit code 3 means that the service was cleanly
> stopped. Don't mind the clarification though.

Yes. It's probably just a clarification.


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

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

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

iD8DBQE/LkCMudf3XQV4S2cRAkeMAJ9gmrI9ip+sVadgnvnktyDsq7Mg8ACffUeT
69Mx5t8MiqhSrlJYKbbF1Xg=
=hUYm
-----END PGP SIGNATURE-----

--VACxsDaSTfeluoxK--