Andrew Beekhof wrote:
On May 20, 2006, at 3:29 PM, Andrew Beekhof wrote:
On May 20, 2006, at 3:01 PM, Lars Marowsky-Bree wrote:
On 2006-05-20T14:49:43, Andrew Beekhof <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Besides, you still have to look in two places,
no i dont
Enlighten me. We must be misunderstanding eachother. Time for a step
back ;-)
So, my proposal 1 was that in 20:20 hindsight, we'd not have polluted
the regular instance_attributes namespace, but create a special
meta_attributes element (and thus namespace) within. And also provide
them to the RAs in a different namespace, not the reskeys.
well i dont think the lrm would support a whole new namespace, so i
was settling for a sub-namespace.
eg. OCF_RESKEY_crm-meta-
otherwise though i think we're talking about the same thing
You say this is easily implemented, and that you'd simply handle both.
So everyone could continue to set things like they do now.
My proposal 2 was that we just prefix all of them with crm_, and to have
an option to turn of the "compatibility" aliases at the admins
discretion.
i think you mean turn off... because we'd have to default to on for
backwards compatibility
You say this is more work for you than proposal 1. And here's where I
don't follow. To you, I'd think they are both the same. If you have to
look for two names or in two places, how is that a difference?
Prop 1: I set up a "meta" hashtable and populate it with
meta_attributes (and for backwards compatibility copy in any unset
attributes from the regular hashtable).
From then on i just look up the name at the meta hashtable.
"and add the crm-meta- prefix at the end"
i think thats the bit we diverged on (because i didnt say it).
so the admin would still configure <nvpair name=X value=Y/>
end the code would still look for X
the only change is that when we're creating the list of parameters to
pass to the lrm, we prefix them with "crm-meta-"... so X comes out as
crm-meta-X (and if you configured it in the old way, as X too for
backwards compatibility)
Are you implying that the only part affected is the LRM?
There are a couple of things that surprise me about this.
If you leave the name spaces mingled in the GUI (and the CIB,
presumably), then the name space clashes will still happen.
If you put conversion logic in place that automatically converts from
the old form to the new form, then the current names are still reserved
- it's just not as obvious.
If you wrote an external conversion script that you could run on a
one-shot basis, then that would be helpful - but wouldn't be the right
thing to do until a cluster was completely converted over to the new
names (and you'd hope you don't have to fail over in this interval).
"What you're going to do, do quickly" (Jn 13:27). Because the longer
this drags on, the worse the problem will be.
This is _exactly_ the kind of thing you'd like to have settled by the
time of a major release - so that the legacy problems will be minimal.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
