Hi,
as part of revising the OCF RA spec, one of the major feature blocks we
need to consider is the ability to depreciate agents (or parameters, see
yet another mail).
To recap, obsoleting works from the superseding agent to the old one;
since the old one is perhaps not maintained, we can't insert the magic
cookie into its metadata.
In the most basic form, an agent would include something similar like:
<obsoletes class="ocf" provider="heartbeat" type="drbd">
<longdesc lang="en">Notes on this particular conversion, what to pay
attention to on parameters etc, and why to do it</longdesc>
</obsoletes>
I imagine that this would cause a small "attention" icon to pop up in
whatever UI the user prefers, and when the user decides to act upon it,
would display the old & new configurations along side each other, along
with the descriptive text; the UI would then enact a replace operation
on the configuration.
(Whether that triggers a restart or merely a reprobe first is an
implementation detail that doesn't belong here.)
What happens when several agents obsolete the same is UI defined; the
user would get to pick one.
Is this sufficient? Do we need an "urgency" flag, or an expiration date
by when the old agent is no longer maintained at all?
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
as part of revising the OCF RA spec, one of the major feature blocks we
need to consider is the ability to depreciate agents (or parameters, see
yet another mail).
To recap, obsoleting works from the superseding agent to the old one;
since the old one is perhaps not maintained, we can't insert the magic
cookie into its metadata.
In the most basic form, an agent would include something similar like:
<obsoletes class="ocf" provider="heartbeat" type="drbd">
<longdesc lang="en">Notes on this particular conversion, what to pay
attention to on parameters etc, and why to do it</longdesc>
</obsoletes>
I imagine that this would cause a small "attention" icon to pop up in
whatever UI the user prefers, and when the user decides to act upon it,
would display the old & new configurations along side each other, along
with the descriptive text; the UI would then enact a replace operation
on the configuration.
(Whether that triggers a restart or merely a reprobe first is an
implementation detail that doesn't belong here.)
What happens when several agents obsolete the same is UI defined; the
user would get to pick one.
Is this sufficient? Do we need an "urgency" flag, or an expiration date
by when the old agent is no longer maintained at all?
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