[OCF]Updates Resource Agent API

[Ragnar Kjørstad]

> The following changes were made:
> - Decided to drop dependencies from the model for now, though they can
>   still be had as vendor specific extensions, of course.

Personally I think we should get back to solving dependencies as soon as
we have version 1 of the spec out.

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

Enforcing uniqueness may be usefull, but this change only solves part of
the problem. Problem is that it only handles cases were a single field
is unique by itself - not cases were two or more fields in combination
must be unique. 

An example of the later would be resource-types that bind to ports. We
might want to specify that the port-number should be unique to help the
user detect conflicting resources. However, in this case only the
port-number together with the ip-address needs to be unique.

Such properties could be detected by a more complicated
"uniqueness-specification", but that would have to wait for version 2.
Still - if that is the direction of choice, it's probably not a good
idea to include a simpler, but incompatible unique-flag now.


Personally I don't know which solution I prefer - or if it needs to be
included at all. After all, even a more complicated
"uniqueness-specification" would probably not be able to detect
conflicts (such as using the same port-number) across different 
resource-types, so a third option is to just acknowledge that the
problem is not easily solvable, and simply not try.

That said, I see that your solution will solve many common cases, so I
will not object to including it as it is.


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

What exactly do you mean is stupid about the LSB exit-codes?

I agree that the the presence of lock- or pid- files is really
irrelevant to the caller of the script; it is sufficient to know that
the program was supposed to be running and isn't.

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. 

Is that what you refered to by stupidity?

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

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.
Scripts will not be able to test that the software is installed properly
_before_ looking at the action-paramter. Another problem is if you run
"satus" (misspelling of status), the exit-code would be 2 - and the
caller would think the program died.

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

Let me just add one more thing: This problem has nothing to do with
clusters. So ideally it should be solved in LSB. 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.

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



-- 
Ragnar Kjørstad