Mailing List Archive

Antw: Re: RA-API DTD versioning
>>> Lars Marowsky-Bree <lmb@suse.de> schrieb am 07.07.2011 um 12:49 in Nachricht
<20110707104911.GK8084@suse.de>:
> On 2011-07-07T08:54:05, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>
> > However the "resource-agent" does not allow multiple descriptions:
> > <!ELEMENT resource-agent (version,longdesc,shortdesc,parameters?,actions) >
>
> Good spotting, it should.
>
> > Now how would one actually select a language? The RA will always return the
> same metadata.
>
> Return descriptions in all languages. The RA is not supposed to select
> that; the UI parsing the metadata will.
>
> > A personal thing I don't like is that "shortdesc" comes after "longdesc".
> Usually a heading comes before the body text, and I feel like that for
> shortdesc and longdesc.
>
> The ordering actually shouldn't matter; the format ought to allow both
> and multiple of them. That's a bit simpler to describe with a schema
> than a DTD.

With the DTD the ordering seems to matter. I'm no specialist on that, but for SGML something like "+(a,b,c)" exists to allow a, b, and c in any order (I think).

>
> > For "type (string|integer|boolean|time)" I feel the DTD should have
> > some comments on how "boolean" and "time" will be actually presented.
>
> Yes. We're working on including more types, and being more clear about
> what they mean. Besides the obvious, are there other types you think
> would be wortwhile?

Assuming "time" actually means "duration", I had to use a "user_id" in my RA. So maybe "uid" and "gid" could be valid types. Would be more specific that "string", possibly allowing IDs per name or numeric ID. In some cases "floats" or "fractionals" could make sense (e.g. when the RA is not written as a shell script).

>
> > There should be a comment in the DTD on:
> > <!ATTLIST action
> > name
> (start|stop|recover|monitor|restart|migrate_to|migrate_from|promote
> > |demote|notify|status|reload|meta-data|usage|methods|validate-all) #REQUIRED
> >
> > stating which methods are actually required.
>
> That does not belong in the syntax definition; none of them are _needed_
> to be described. (Only then should that be stated.) The schema is a
> syntax description for the metadata, not a full semantic definition; nor
> a full description of how RAs behave.

I wondered whether you outl put the OPTIONAL and REQUIRED in the DTD, but had no idea (other than adding comments).

Regards,
Ulrich


_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Antw: Re: RA-API DTD versioning [ In reply to ]
>>> Tim Serong <tserong@novell.com> schrieb am 07.07.2011 um 14:51 in Nachricht
<4E15ABC0.6020404@novell.com>:
> On 07/07/11 20:49, Lars Marowsky-Bree wrote:
> >> For "type (string|integer|boolean|time)" I feel the DTD should have
> >> some comments on how "boolean" and "time" will be actually presented.
> >
> > Yes. We're working on including more types, and being more clear about
> > what they mean. Besides the obvious, are there other types you think
> > would be wortwhile?
>
> I've got a few :) Off the top of my head:
>
> - id (string, but /[A-Za-z0-9_-]+/ (?) only)
> - password (generically a string, but may be expected to be presented
> differently, hidden, etc.)
> - file, directory (again strings, but this affords autocompletion and
> verification of existence).
> - list (space separated string, e.g.: hosts for STONITH devices)
> - enum (run "/usr/lib/heartbeat/pengine metadata" for examples)
>
> I'd also like to consider adding some sort of validation regex, e.g.:
>
> <content type="string" valid_regex="[A-Za-z]+.*"/>

Hi!

"file" and "password" could be strings, but may be valid types, assuming there will be some checks for those. I think a framework should have check functions for all these types to be used for "validate-all".

The problem with enum is that you should provide a list of allowed values. Maybe keep the "string" and add a new element for "parameter" named "value-list" with a sequence of allowed "value"s. One attribute of those "value" elements could be "default" (you guessed what it means).

I have no use for it currently, but maybe a "binary" data type could be useful. We could state that it's represented as BASE64 (today's standard). So if you must provide a PGP key or X.509 certificate, you could go that way.

The thing with REs (regular expressions) is that there are many implementations (just consider sed, grep, egrep, and perl). The RE should be verifyable in any programming language, making things a bit hard. I actually used such a thing in a Perl RA I wrote for HP-UX ServiceGuard, but Perl is it's own standard.

Regards,
Ulrich


_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Antw: Re: RA-API DTD versioning [ In reply to ]
>>>>>>> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> schrieb am 08.07.2011
[...]
>
> >
> > > For "type (string|integer|boolean|time)" I feel the DTD should have
> > > some comments on how "boolean" and "time" will be actually presented.
> >
> > Yes. We're working on including more types, and being more clear about
> > what they mean. Besides the obvious, are there other types you think
> > would be wortwhile?
>
> Assuming "time" actually means "duration", I had to use a "user_id" in my
> RA. So maybe "uid" and "gid" could be valid types. Would be more specific
> that "string", possibly allowing IDs per name or numeric ID. In some cases

...more specific THAN ... (I wanted to type)

> "floats" or "fractionals" could make sense (e.g. when the RA is not written
> as a shell script).
>
[...]
>
> I wondered whether you outl put the OPTIONAL and REQUIRED in the DTD, but
> had no idea (other than adding comments).

(I'll have to work with a system that continuously steals the windows focus, and sometimes returns it) So actually there are many words missing in above, and I cannot remeber what I wanted to write, sorry! I was whether you could rewrite the DTD so that optional and required actions could be specified. More or less...

>
> Regards,
> Ulrich
>
>
> _______________________________________________
> ha-wg-technical mailing list
> ha-wg-technical@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
>




_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical