Mailing List Archive

RA-API DTD versioning
Hi,

with two incompatible versions of RA-API-1, I think it's time to move to a two-level versioning pattern, like "RA-API-1.1". Besides that I think it's time to change the current version to "2.0" or so. From then on, compatible changes would increment the fractional part of the version, while incompatible changes would increment the integer part.

A bit more concrete:
I guess "parameter" allows multiple descriptions to support Internationalization (i18n) of descriptions:
<!ELEMENT parameter (longdesc+,shortdesc+,content)>

However the "resource-agent" does not allow multiple descriptions:
<!ELEMENT resource-agent (version,longdesc,shortdesc,parameters?,actions) >

(Some comments on I18n in the DTD would be fine.)

Now how would one actually select a language? The RA will always return the same metadata.

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.

For "type (string|integer|boolean|time)" I feel the DTD should have some comments on how "boolean" and "time" will be actually presented. The assumption for typed data is that the framework will actually check the types (i.e. trying to set a "boolean" parameter to "7" should be rejected, just as trying to set an "integer" parameter to "true" should be rejected). I think the documentation does not say a lot on that issue.

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.

Regards,
Ulrich


_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Re: RA-API DTD versioning [ In reply to ]
On 2011-07-07 08:54, Ulrich Windl wrote:
> Hi,
>
> with two incompatible versions of RA-API-1, I think it's time to move to a two-level versioning pattern, like "RA-API-1.1". Besides that I think it's time to change the current version to "2.0" or so.

A discussion about a new RA spec is ongoing on this list, including but
not limited to resource agent metadata. Your input about versioning is
appreciated.

Cheers,
Florian
Re: RA-API DTD versioning [ In reply to ]
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.

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

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


Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Re: RA-API DTD versioning [ In reply to ]
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]+.*"/>

Regards,

Tim
--
Tim Serong <tserong@novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Re: RA-API DTD versioning [ In reply to ]
Hi Tim,

On Thu, Jul 07, 2011 at 10:51:12PM +1000, Tim Serong wrote:
> 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.)

I guess you mean as a hint to the user interface?

> - file, directory (again strings, but this affords autocompletion and
> verification of existence).

Eek, /me doesn't want to do any more autocompletion.

> - 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]+.*"/>

Perhaps useful, but also looks like an overkill to me.

Cheers,

Dejan

> Regards,
>
> Tim
> --
> Tim Serong <tserong@novell.com>
> Senior Clustering Engineer, OPS Engineering, Novell Inc.
> _______________________________________________
> 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
Re: RA-API DTD versioning [ In reply to ]
On 07/07/11 23:59, Dejan Muhamedagic wrote:
> Hi Tim,
>
> On Thu, Jul 07, 2011 at 10:51:12PM +1000, Tim Serong wrote:
>> 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.)
>
> I guess you mean as a hint to the user interface?

Exactly.

>> - file, directory (again strings, but this affords autocompletion and
>> verification of existence).
>
> Eek, /me doesn't want to do any more autocompletion.

Sorry :)

>> - 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]+.*"/>
>
> Perhaps useful, but also looks like an overkill to me.

Yeah, maybe. Just floating the idea.

Cheers,

Tim
--
Tim Serong <tserong@novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Re: RA-API DTD versioning [ In reply to ]
On 2011-07-07T22:51:12, Tim Serong <tserong@novell.com> wrote:

> - password (generically a string, but may be expected to be presented
> differently, hidden, etc.)

That makes sense.

> - file, directory (again strings, but this affords autocompletion and
> verification of existence).

I think we will need this, yes, since it'll make the UIs much more
powerful.

I look forward to you coding web-based remote completion in hawk. ;-)

> - list (space separated string, e.g.: hosts for STONITH devices)
> - enum (run "/usr/lib/heartbeat/pengine metadata" for examples)

The later would be a radio/checkbox/SELECT statement, right? Basically,
we're building a simplified FORMS element ... Just without the
javascript triggers. ;-)

Though ... did anyone notice that JS would be awesome for validation?
And how we could use all the usual rendering widgets if it was direct
HTML? ;-)


Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
Re: RA-API DTD versioning [ In reply to ]
On 09/07/11 07:46, Lars Marowsky-Bree wrote:
> On 2011-07-07T22:51:12, Tim Serong<tserong@novell.com> wrote:
>
>> - password (generically a string, but may be expected to be presented
>> differently, hidden, etc.)
>
> That makes sense.
>
>> - file, directory (again strings, but this affords autocompletion and
>> verification of existence).
>
> I think we will need this, yes, since it'll make the UIs much more
> powerful.
>
> I look forward to you coding web-based remote completion in hawk. ;-)

I know :)

>> - list (space separated string, e.g.: hosts for STONITH devices)
>> - enum (run "/usr/lib/heartbeat/pengine metadata" for examples)
>
> The later would be a radio/checkbox/SELECT statement, right?

Correct. Well, boolean would be a checkbox, but enum could be either
radio or select - UI author's choice (or by some heuristic, e.g.: 2
element selects are just dumb, IMO, but that's veering OT - I wouldn't
enforce a control type in the RA metadata, just the data semantics).

> Basically,
> we're building a simplified FORMS element ... Just without the
> javascript triggers. ;-)

Pretty much.

> Though ... did anyone notice that JS would be awesome for validation?
> And how we could use all the usual rendering widgets if it was direct
> HTML? ;-)

*gah*

This metadata does need to be usable by the shell, not sure Dejan would
be too happy if he had to embed a JavaScript interpreter or JIT :)

Regards,

Tim
--
Tim Serong <tserong@novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical