Mailing List Archive: Linux-HA: HA-WG-Technical

RA spec: Ability to depreciate parameters

Index | Next | Previous | View Threaded

lmb at suse

Jun 25, 2011, 7:15 AM

Post #1 of 8 (356 views)
Permalink

RA spec: Ability to depreciate parameters

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 [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical

tserong at novell

Jun 27, 2011, 1:41 AM

Post #2 of 8 (346 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On 26/06/11 00:15, Lars Marowsky-Bree wrote:
> 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.

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>

Regards,

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

lmb at suse

Jun 27, 2011, 8:25 AM

Post #3 of 8 (342 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On 2011-06-27T18:41:10, Tim Serong <tserong [at] novell> wrote:

> I think if enough parameters change due to significant implementation
> changes, it makes sense to just obsolete the entire RA.

Yes, that's what I'm thinking.

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

Well, yes. However, the "netmask" case is also an extremely trivial one;
there's no harm in basically eternally carrying the code that accepts
the old name (unless someone wanted to reuse it with a different
meaning).

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

A depreciated-by date probably would be helpful, to allow users some
head notice that something will change in the future. (Similar to what
sysfs does.)

Your point is valid; my approach was a "pull" design, where basically a
new parameter describes what it replaces; but you're right, we seem to
need a "push" method, where an old parameter's definition is retained to
describe by what it was replaced. (In your case, by nothing, since the
parameter is going away completely.)

The same seems true for entire agents. It seems we need to equip the
"old" RA/parameter with a depreciated-by/replaced-by tag, and have the
replacement (if any) describe what it replaces. Otherwise, we could
never get rid of an entirely obsolete/unmaintained RA.

Your example of the CTDB parameters seem to imply that the actual setup
changes; would that not trigger a RA replacement, where the new RA
simply would no longer advertise the new parameters? (Though at the
same time, it may want to advertise that they've gone away, and what
changes their values imply for the system configuration, I guess. Unless
we simply want to go with the easy route and make that a prose release
notes text.)

(As a potential tangent, I wonder if there's anything we can do to
prevent users from installing updates that would break their clusters. I
wonder if we can inject "live" dependencies into the packaging system
that a particular RA version is actually being used, and refuse the
upgrade to a package version that no longer provides that at all until
the dependency is removed. Hrm. Excellent idea. But unrelated. ;-)

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 [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical

tserong at novell

Jun 28, 2011, 6:46 AM

Post #4 of 8 (342 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On 28/06/11 01:25, Lars Marowsky-Bree wrote:
> Your example of the CTDB parameters seem to imply that the actual setup
> changes; would that not trigger a RA replacement, where the new RA
> simply would no longer advertise the new parameters? (Though at the
> same time, it may want to advertise that they've gone away, and what
> changes their values imply for the system configuration, I guess. Unless
> we simply want to go with the easy route and make that a prose release
> notes text.)

In the case of the CTDB RA, it's ultimately "doing less" than it was
when originally implemented, so in that specific case the RA doesn't
actually need to be replaced, but the cluster setup does change. The
user would need to add Samba resource to replace stuff the CTDB RA used
to do automagically, i.e. we go from a single cloned CTDB resource to
(probably) a clone-of-group where the group contains a CTDB, Samba and
(maybe) Winbind resource.

In this case, I think prose release notes text is best - it's basically
a non-automatable change - in addition to RA config, there's samba
config to tweak, probably other CTDB/samba-specific things, which goes a
fair way out of scope of what a generic RA upgrade/obsoletion mechanism
can or should be expected to understand.

(Or, if it *is* somehow automatable it's not a change you'd want to make
without yelling at the admin "Hey! We're automating something! You
need to verify this and make sure you're happy!")

Anyway, I'm probably getting too far into CTDB RA specifics...

>
> (As a potential tangent, I wonder if there's anything we can do to
> prevent users from installing updates that would break their clusters. I
> wonder if we can inject "live" dependencies into the packaging system
> that a particular RA version is actually being used, and refuse the
> upgrade to a package version that no longer provides that at all until
> the dependency is removed. Hrm. Excellent idea. But unrelated. ;-)

You can do weird stuff with %pre etc. in RPM files, e.g.:

%pre
if crm configure show 2>/dev/null | grep -q ocf:heartbeat:Yuck; then
echo "You're using a crusty old RA, please stop"
exit 1
# RPM fails to install at this point
fi

I assume the same is true for other packaging mechanisms, but while I
think preventing upgrade breakages is a good idea, I suspect it's
fraught with peril (how do you know a given resource is being used if
the cluster's not running? grep /var/lib/heartbeat/crm/cib.xml?)

Regards,

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

lmb at suse

Jun 28, 2011, 6:49 AM

Post #5 of 8 (343 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On 2011-06-28T23:46:50, Tim Serong <tserong [at] novell> wrote:

> In the case of the CTDB RA, it's ultimately "doing less" than it was
> when originally implemented, so in that specific case the RA doesn't
> actually need to be replaced, but the cluster setup does change.

Sticking with the example here, that _is_ a new RA, effectively: it does
something different than the previous one and isn't a drop-in
replacement. That's a new version by any name, if you ask me.

So yes, this is obsoleting the CTDB v1 RA and replacing it with v2,
which needs to be configured quite differently. (And v2 would, in its
metadata or prose, probably hint at commonly requiring dependencies to
some other resources.)

> Anyway, I'm probably getting too far into CTDB RA specifics...

True, but a specific example is a good base to discuss semantics.

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 [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical

tserong at novell

Jun 28, 2011, 7:14 AM

Post #6 of 8 (335 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On 28/06/11 23:49, Lars Marowsky-Bree wrote:
> On 2011-06-28T23:46:50, Tim Serong<tserong [at] novell> wrote:
>
>> In the case of the CTDB RA, it's ultimately "doing less" than it was
>> when originally implemented, so in that specific case the RA doesn't
>> actually need to be replaced, but the cluster setup does change.
>
> Sticking with the example here, that _is_ a new RA, effectively: it does
> something different than the previous one and isn't a drop-in
> replacement. That's a new version by any name, if you ask me.

Well, when you put it like that...

> So yes, this is obsoleting the CTDB v1 RA and replacing it with v2,
> which needs to be configured quite differently. (And v2 would, in its
> metadata or prose, probably hint at commonly requiring dependencies to
> some other resources.)
>
>> Anyway, I'm probably getting too far into CTDB RA specifics...
>
> True, but a specific example is a good base to discuss semantics.

Continuing with the specifics then :) right now we have a CTDB RA with a
few parameters marked deprecated in their prose descriptions. If you
set these parameters, it operates in "CTDB RA v1 mode", which is as it
was originally implemented. If you don't set them it operates in "CTDB
RA v2 mode". By supporting both, at least for a few release cycles[1],
we don't suddenly break a cluster during an upgrade of resource-agents,
and eventually arrive at a point where everyone is necessarily using it
in "v2 mode"[2].

But now I wonder, does a new version/implementation of an RA imply the
addition of a new name is best practice (think: IPaddr vs. IPaddr2)? Or
is evolving the implementation even if that (eventually) requires the
admin make config changes preferred?

(My preference is obviously the latter, given that I wrote the CTDB RA
and am using it as an example here...)

Regards,

Tim

[1] For some metric of release cycle.
[2] Which frankly is how I should have implemented it in the first
place. Ain't hindsight grand?
--
Tim Serong <tserong [at] novell>
Senior Clustering Engineer, OPS Engineering, Novell Inc.
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical

lmb at suse

Jun 28, 2011, 9:14 AM

Post #7 of 8 (336 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On 2011-06-29T00:14:26, Tim Serong <tserong [at] novell> wrote:

> Continuing with the specifics then :) right now we have a CTDB RA
> with a few parameters marked deprecated in their prose descriptions.
> If you set these parameters, it operates in "CTDB RA v1 mode", which
> is as it was originally implemented. If you don't set them it
> operates in "CTDB RA v2 mode". By supporting both, at least for a
> few release cycles[1], we don't suddenly break a cluster during an
> upgrade of resource-agents, and eventually arrive at a point where
> everyone is necessarily using it in "v2 mode"[2].

Right. I could imagine this as a a "v1 wrapper" that actually contained
the weird things it did on top, and calling "v2" for the common bits.

While, at the same time, having "v2" advertise that it obsoletes "v1".
Quite similar to how we envision the RHT/heartbeat RAs will eventually
merge into a common implementation.

> But now I wonder, does a new version/implementation of an RA imply
> the addition of a new name is best practice (think: IPaddr vs.
> IPaddr2)? Or is evolving the implementation even if that
> (eventually) requires the admin make config changes preferred?

I think depreciating the old version/interface is the preferred route,
in particular in this specific example of CTDB requiring a completely
different configuration of the whole system.

But since the configuration of the system always depends on the RA
parameters and vice versa, there's probably some margin where the RA
simply evolves. Consider renaming a parameter, or making it unnecessary
(but completely harmless); in that case, obsoleting the whole RA would
be overkill.

Now, you're raising an excellent point; how to version RAs. Clearly,
different versions must have different file names, otherwise they
couldn't co-exist.

However, this is actually something that the "old" spec addresses: the
"name" and (optional) "version" attribute to the "resource-agent" element.

Simply put, we can have several agent advertise the same "type" (name)
in different versions. The LRM doesn't parse that information so far,
but it could; so theoretically, this is feasible.

The old prose spec did apply this to providers (expecting symlinks
here), but I think we don't really want to go down that path.

Best,
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 [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical

andrew at beekhof

Jun 30, 2011, 12:13 AM

Post #8 of 8 (328 views)
Permalink

Re: RA spec: Ability to depreciate parameters [In reply to]

On Sun, Jun 26, 2011 at 12:15 AM, Lars Marowsky-Bree <lmb [at] suse> wrote:
> 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?

Agreed.

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

You mean ${RA} -> ${RA}2 ?
Not sure I like the version in the RA name, but I can't think of
anything better at the moment :-/
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads