tserong at novell
Jun 27, 2011, 1:41 AM
Post #2 of 8
On 26/06/11 00:15, Lars Marowsky-Bree wrote:
Re: RA spec: Ability to depreciate parameters
[In reply to]
> 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 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.
>> <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.
> 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.
I think if enough parameters change due to significant implementation
changes, it makes sense to just obsolete the entire RA.
I can imagine cases where a parameter or two are obsoleted by new
parameters with perhaps more flexible definitions, or maybe where a
couple of parameters are conflated(?) into one, or vice versa, which I
think matches what you've got above with the netmask example.
But we also need the ability to simply deprecate a parameter, without
there being any new parameter to replace it, e.g.: the CTDB RA has a
smb_private_dir parameter, which flat out should not be used at all if
you have CTDB > 1.0.50. Likewise, in future we'll deprecate
ctdb_manages_samba and ctdb_manages_winbind, and they won't be replaced
with some new parameter, they'll just be gone. Maybe in this case we
should have something like:
<parameter name="smb_private_dir" deprecated="1">...</parameter>
Or if we care about exposing *when* something was deprecated(?):
<parameter ... deprecated="2011-06-27">...</parameter>
Tim Serong <tserong [at] novell>
Senior Clustering Engineer, OPS Engineering, Novell Inc.
ha-wg-technical mailing list
ha-wg-technical [at] lists