Hi all,
in a similar vain, we sometimes have the need to obsolete parameters.
Let's see if some of the brain-storming here resonates with some ;-)
One could argue whether we really do, though; if the external interface
is significantly different so that it must be configured differently,
and not just mere additions of options, perhaps the best way would be to
handle it as a case of RA obsoletion?
(i.e., a new version obsoleting an old one etc. The old one could act as
a translating wrapper to the new back-end code in the meantime.)
I've spend a few hours thinking about this, and I actually think there's
merit in the previous thought. I'd like to read your thoughts on this;
even then though, the following might provide clues how to translate the
parameters from the old to the new version.
Yet another thought though is if we want to handle this via the UI; or
should we call some special "translate" function of the RA, supply it
with the old environment, and have it spit out its best guess at how to
translate it to the new version?
Another alternative would be to consider that what it actually does is
translate one XML blurb to another; is XSLT a good choice for this ...?
That said, we'd essentially need the ability for some parameter to
declare that it is the preferred form of an older one; quite similar to
the RA obsoletion, in any case.
As such, I'd probably embed it inside the definition of a given
parameter:
> <parameter name="cidr_netmask">
> <longdesc lang="en">
> The netmask for the interface in CIDR format. (ie, 24), or in
> dotted quad notation 255.255.255.0).
>
> If unspecified, the script will also try to determine this from the
> routing table.
> </longdesc>
> <shortdesc lang="en">Netmask</shortdesc>
> <content type="string" default=""/>
>
<obsoletes name="netmask" (class/provider/agent=...)>
<longdesc lang="en">
This parameter replaces the previous syntax with a more clear
definition, bla bla bla.
</longdesc>
</obsoletes>
> </parameter>
The optional class/provider/agent bits would be useful to indicate when
we're doing cross-RA-parameter obsoletion (probably to augment an RA
obsoletion); they'd default to the values of the current RA, obviously.
Now, this can get somewhat complex, as depreciations builds up over time;
the parameters get more and more complex. Going back to the "handle all
real parameter obsoletion as a case of RA obsoletion", it would allow
for a somewhat tidier version of this, since then the "and when doing
this obsoletion, these old parameters translate to these new ones" would
be easier to group inside that particular "obsoletes" block.
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
in a similar vain, we sometimes have the need to obsolete parameters.
Let's see if some of the brain-storming here resonates with some ;-)
One could argue whether we really do, though; if the external interface
is significantly different so that it must be configured differently,
and not just mere additions of options, perhaps the best way would be to
handle it as a case of RA obsoletion?
(i.e., a new version obsoleting an old one etc. The old one could act as
a translating wrapper to the new back-end code in the meantime.)
I've spend a few hours thinking about this, and I actually think there's
merit in the previous thought. I'd like to read your thoughts on this;
even then though, the following might provide clues how to translate the
parameters from the old to the new version.
Yet another thought though is if we want to handle this via the UI; or
should we call some special "translate" function of the RA, supply it
with the old environment, and have it spit out its best guess at how to
translate it to the new version?
Another alternative would be to consider that what it actually does is
translate one XML blurb to another; is XSLT a good choice for this ...?
That said, we'd essentially need the ability for some parameter to
declare that it is the preferred form of an older one; quite similar to
the RA obsoletion, in any case.
As such, I'd probably embed it inside the definition of a given
parameter:
> <parameter name="cidr_netmask">
> <longdesc lang="en">
> The netmask for the interface in CIDR format. (ie, 24), or in
> dotted quad notation 255.255.255.0).
>
> If unspecified, the script will also try to determine this from the
> routing table.
> </longdesc>
> <shortdesc lang="en">Netmask</shortdesc>
> <content type="string" default=""/>
>
<obsoletes name="netmask" (class/provider/agent=...)>
<longdesc lang="en">
This parameter replaces the previous syntax with a more clear
definition, bla bla bla.
</longdesc>
</obsoletes>
> </parameter>
The optional class/provider/agent bits would be useful to indicate when
we're doing cross-RA-parameter obsoletion (probably to augment an RA
obsoletion); they'd default to the values of the current RA, obviously.
Now, this can get somewhat complex, as depreciations builds up over time;
the parameters get more and more complex. Going back to the "handle all
real parameter obsoletion as a case of RA obsoletion", it would allow
for a somewhat tidier version of this, since then the "and when doing
this obsoletion, these old parameters translate to these new ones" would
be easier to group inside that particular "obsoletes" block.
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