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? 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 - so saying
you _have_ to have a complicated policy 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.
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".
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.
------------------------------------------------
For those who aren't familiar with the English terms for these logical
fallacies, I offer these definitions:
The false dichotomy fallacy involves enumerating a small number of
possible options, and eliminating all but one of these options through a
logical arguments, then stating that the only possible solution then is
the one remaining option. This is a logical fallacy when the enumerated
set is incomplete. In computer science, it is usually impossible to
enumerate all possible solutions, therefore it often occurs.
The straw man fallacy is closely related. It involves setting up a weak
argument for a particular proposition and then proceeding to demolish
the weak argument, then claiming (falsely) that the proposition must
therefore be false. This weak argument is referred to as a "straw man"
argument, since anyone can defeat a man made of straw.
--
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/
