On Jan 23, 2006, at 2:38 PM, Lars Marowsky-Bree wrote:
On 2006-01-21T18:47:48, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
Not really.
If you cast your mind back, the original purpose for managed/
unmanaged was so that we could depend on things that were outside the
CRM's control. So that resources could "sit on top" of an unmanaged
resource and would be stopped/relocated if the unmanaged one is.
So monitoring is actually essential.
No, it is not.
"unmanaged" means "unmanaged by us".
clearly
That _includes_ not monitoring it,
No it doesn't.
Oxford dictionary:
unmanaged (adjective)
1. not controlled or regulated
Observing the state of a resource constitutes neither control nor
regulation of that resource.
because unmanaged resources may be active w/o a RA,
no they cant. all resources need an RA. period.
even the stonithd resources have an RA - its just not a shell script.
or we don't have
sufficient information to monitor it in our CIB.
"unmanaged" means that someone else will tell us that we a) should
resume managing it, or b) that we'll learn from some outside source
that
the resource has come or gone.
(This is a useful property for resources which we learn about via a
CIMON one day.)
If people really don't want monitoring for a while, the action can
always be deleted (though an enabled/disabled flag would be nice
too). Just make sure the "stop_orphan_actions" option is enabled in
the CIB.
So, if that option is set, resources which are unmanaged will stop
being
monitored? OK. That answers that ;-)
Is the corollary - that we start monitoring unmanaged resources if the
flag is not set - true too? That would be wrong.
Whether an unmanaged resource is monitored or not is has no effect on
what the CRM does to it - since that is always nothing. So its free
to be unavailable/broken as much as it likes.
Monitoring a resource which we don't plan to do anything about
spams the
logfiles...
The CRM logs it once. The LRM may log it more depending on the log
level.
As I said above, the difference is how the resources that depend on
the unmanaged resource are treated. They are neither unmanaged nor
in maintenance mode and there are still ordering and locational
constraints that need to be satisfied.
Sure.
But, a resource which is monitored may appear to be _down_, as in
"stopped". So, what will you do when that monitor comes back with
such a
result?
I've already answered that multiple times.
The _idea_ of maintenance mode is that we ignore the resource, pretend
it's healthy, until the admin tells us something different. Period.
Now, I'd argue the "maintenance mode" is even more like "not
monitoring
it at all, but restarting it in case of node failures". That I'd
concede. But most certainly it implies "don't monitor".
The problem is that we have been using unmanaged mode for a situation
its not 100% suited too.
What we really need is a way to shutdown a resource "until further
notice"... it is still "managed" but the PE should arrange for it and
everyone that requires it to be stopped (in the right order) and
shouldn't restart them.
This is the absolutely wrong answer to maintenance mode.
Say you've set up the cluster and said resourceB needs resourceA to run.
If resourceA is unavailable (regardless if the CRM knows its
unavailable or not) then its very likely resourceB is going to fail
too. Otherwise why say resourceB needs resourceA to run?
So now we have a resource that is NOT in maintenance mode AND has
failed.
Is it not better to have the root cause obvious and stop resourceB
before it fails?
Or better yet, to stop resourceB first so resourceA can be stopped
cleanly in the first place?
--
Andrew Beekhof
"If it weren't for my horse, I wouldn't have spent that year in
college" - Unknown, courtesy of Lewis Black
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
