On May 20, 2006, at 12:26 PM, Lars Marowsky-Bree wrote:
properties take precedence over instance_parameters which take
precedence over a parent's properties and instance_parameters
Ok.
Second, I don't think these _should_ be instance parameters. These are
options which don't make _sense_ to be affectable by rules and stuff, I
think. (This would be a dividing line.)
my preference would be to make them all instance parameters
I'm just frightened by giving them so much rope, but I guess that makes
sense and would at least be consistent...
the only reason many are able to be set as properties is that we had
no easy way to set parameters (we do now though)
No, the _real_ reason (before the code came ;-) was that instance
parameters were meant to be exclusively meaningful to the RA, not to us
(and we'd rely on the attributes).
Then we wanted to make some of the attributes subject to the rules and
also make them available to the RA and configurable via the GUI (3 good
reasons), but that's where we went wrong and threw them into the same
name-space as the "regular" instance parameters.
If we'd been smart, we'd have changed "instance_attributes" to not only
contain (rule*, attributes), but (rule*, attributes?, meta_attributes?)
and also put these not into the OCF_RESKEY_... space in the environment
but, say, CRM_PARMS_... or something and avoided this whole mess ;-)
20:20 hindsight is always different.
well would could still do something like this. sounds pretty sensible and for backwards compatibility we can populate missing meta_attributes from the instance_attributes.
actually this makes a lot of sense to me
So, given that we made that choice, putting them all into the instance
parameters list is probably the sanest we can do.
We really, really need to fix that with the crm_ prefix to these.
We're already in deep shit because we've quite a number of reserved
words, but we mustn't add more. (This doesn't apply so much to this
change, just to the future...)
nod, we need to look into this and figure out how to sanely support
both the old and new names.
Well, the new names is easy. Even having them both as aliases is easy
enough. (And something we should do, I think.)
The real issue comes up when the RA indeed _does_ want to use one of our
"reserved" keys.
I assume that we should have a configuration option to turn off the old
aliases, which the admin should turn on after they have sanitized the
instance attributes accordingly. It's simply not something we can figure
out entirely automatically.
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"
_______________________________________________________
