[OCF]Updates Resource Agent API

[Ragnar Kjørstad]

On Mon, Aug 04, 2003 at 01:16:28PM +0200, Lars Marowsky-Bree wrote:
> On 2003-08-01T20:27:33,
>    Ragnar Kjørstad <linux-ha@ragnark.vestdata.no> said:
> 
> > 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.

Still changed. 
I agree though, that it would be much worse to excange exit-codes for
ok- and failure-states, than two different failure-states.

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

I don't think that would be completely right either.
150-199 is reserved for the application; meaning that apache's
init-script could very well return 150 in some cases and other apache
utilities could interpret that to mean something interesting.

Note, I have never seen init-scripts use application-specific
exit-codes, but I think this is the way it was intended to be used by
LSB. 

Based on the fact that we are an LSB-extention, I think using one of the
LSB reserved codes would be more right. Especially since what we're
fixing is something that should ideally be put back into LSB later.

Now; I agree that just taking one of the LSB-codes without asking could
potentially be really bad; so my assumption is that we can get some kind
of ACK from LSB that this is ok. This shouldn't delay the
release-process though - I think it would be acceptable to use exit-code
5 it the draft, and then expect feedback from LSB and others before it
is made a standard.


> > In general, I think this is a difficult question, and it's just a matter
> > of finding the least painful solution. 
> 
> 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, I agree that this use of exit-code 1 is fine. 

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

I suppose by the same argument that I say we could use 5 and then expect
feedback on the draft, we could also stick with 2 and expect the same
thing. If someone from the LSB-group came out and said that changing the
meaning of this exit-code sounds ok, and maybe they should do the same
thing in LSB-1.4, I would have no objections.

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

Here we go again :-)
I must admit the thought crossed my mind too, but I think introducing a
new action just for a single exit-code problem is too much.

For a temporary solution there is the possibility of using exit-code 4,
indicating unknown status. OK, so it's not the right code either, but it
would be indicating an error without giving false information about what
the error actually is. Giving too little information is better than
giving false information. 


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

Good. I'd be curious to what they think.


I regret now that I wrote a long and complicated comment to them about
the all the problems with the exit-codes. It would have been better to
just stress this single point and maybe they would have bothered to fix
it. Well; to late now.


Let me just stress that even if I've made some comments about some stuff
that I think is not 100% perfect yet, I don't think that's any excuse to
delay the process. The issues are minor, and could be fixed after the
draft, or in a second draft, if we should decide to write one. So, the
focus now should be what do we need to do to put it out there?

If I remember correctly there were two formalities:
1. The standard needed to be reformated into Docbook. 
2. The steering-commity (or whatever the name was) needed to accept
   it.
Or were those only for final standards?


-- 
Ragnar Kjørstad