On May 20, 2006, at 6:51 PM, Alan Robertson wrote:
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:
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?
no, i'm implying that a couple of RAs might be the only ones affected... for example ones that look for "ordered" (which in the new setup would additionally be available as crm-meta-ordered)
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.
lets pretend the admin wanted to pass "ordered" to his RA
in that case:
instance_attributes->ordered = some_value
and if they configured the group to start in parallel, then they'd configure:
meta_attributes->ordered = false
then the resource parameters would be
ordered=some_value crm-meta-ordered=false
no clash at all. and when they go through the LRM they both get OCF_RESKEY_ prefixes.
if the admin hadn't specified
instance_attributes->ordered = some_value
then the resource parameters would be
ordered=false crm-meta-ordered=false
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.
i believe this makes them unreserved (where previously they were reserved)
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.
--
"Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________________
