On Jan 27, 2006, at 3:23 PM, Alan Robertson wrote:
Andrew Beekhof wrote:
On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote:
Andrew Beekhof wrote:
On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote:
Andrew Beekhof wrote:
CTS testers please note this commit.
In order to run the same tests as you used to, you need to
specify:
enable_config_writes off
in ha.cf
Why is this an ha.cf option. It's clearly a CIB option - so I
would
think it belongs in the CIB. It makes no sense there... We
discussed
some things, but I don't remember this one.
Four reasons:
- the CIB is intended to be policy free (and at the moment is
IIRC)
BUT this is a CIB policy - hence it must be enforced and carried
out by
the CIB.
- correct interpretation of options in the CIB requires linking
against the PE
(or worse, duplicating slabs of its code)
I don't follow this at all. It's the CIB that writes the CIB,
isn't it?
But it doesn't know what its writing. Same way the LRM doesn't know
what its starting.
But, the LRM does have to make special cases which make it somewhat
conceptually impure.
Remember all options can be time, host and phase of the moon
dependent.
In order to understand what the option is actually set to, it
needs to
be able to evaluate all those expressions and rule sets - a fair
chunk
of the PE.
Plus its a waste to do this every time the CIB is updated.
This sure looks like a combination of the false dichotomy and straw
man logical fallacies.
But, perhaps I'm missing something - because you are in fact the
expert on the CIB.
So, why wouldn't calling get_xml_attr_nested() and friends return
the data you want?
you would know if you paid attention for even half a second:
Remember all options can be time, host and phase of the moon
dependent.
If you say because the XML section you'd choose to put it inside of
has complicated semantics, then don't do that. If you added a
<cibopts/> section, that would certainly solve any potential
problem of complexity - and it would be readily extensible to new
things as they come up.
The environment variables can't create a complicated policy
do or do not write to disk... gee thats complicated
- so saying you _have_ to have a complicated policy
if its a cluster option then it has the same properties as all the
others including resource stickiness which you seemed to be rather
fond of being able to set differently depending on the time.
now that you move it into the CIB doesn't obviously follow. If you
didn't need it before, you don't need it now.
we did need it was before... it was broken and I just didnt know it yet.
There may be in fact, really convincing arguments you haven't
presented so far. But, you're going to have to do something better
than wave your hands and say "trust me I'm the expert here".
i didnt do that. i tried to explain it and you threatened to back
out the changes.
And, since the lack of these options appears to affect STONITH
behavior in an undocumented way, there's also a lot more here than
you've talked about. I'd be very interested to hear more on that
subject as well.
ooo here's a node we dont know about... what should we do?
we should know what we dont know and shoot the thing so that we do know.
if we dont write to disk... then we have no record of any other nodes
do we (unless the admin included them in the on-disk version) so
there is no-one to shoot .
you know about this so please stop acting so surprised
it would be helpful if you paid attention the first few times we have
these sorts of conversations.
you're clearly in one of those moods again and now I am too.
see you monday, i'm going skiing.
--
Andrew Beekhof
"I like your old stuff better than your new stuff" - Regurgitator
_______________________________________________________
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/
