On 2006-05-20T15:29:12, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
> >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-
Makes sense. (Except that "-" doesn't work well in variable names.) My
proposal was that I'd have moved them into a different namespace, but of
course, that's a bitch 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
Yup, there was a "f" missing, not a "f" instead of a "n" ;-)
> >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.
OK so far.
> Prop 2: every time i need to look up X i need to look for crm-meta-X
> and if thats not set, then fall back to X.
You could, simply like you do with Prop 1, translate the "X" to
"crm_meta_X", and then only go looking for that. (Unless, of course,
said translation is turned off.)
It's going to show up in the same environment and name-space everywhere
else (except for the prefix), so why keep them separate here?
> >In either case, everyone else can pretend you never made the change
> >until they want to switch over to the new scheme.
> in (my implementation of) prop 1, there'd be no switch... they'd just
> start using meta_attributes sets.
You'd still need to turn off populating from the regular instance
parameters though, in case these have been used by the RA in question.
So, this alone isn't sufficient and the option still needed.
> but arent we talking about options that are for the PE not the RA?
>
> clone instance, notify, colocated... those things arent RA parameters
> so why would they need to change/be added in the RA's metadata?
Because the RA's metadata is the place where the RA tells us about the
defaults it prefers, and the same would then apply to these options.
That makes sense to me at least.
> "short and to the point because its saturday" yes, but not "terse".
What does Saturday have to do with it? Weekends are just semantics ;-)
Sincerely,
Lars Marowsky-Brée
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
