On 2012-08-16T17:54:06, "EXTERNAL Konold Martin (erfrakon, RtP2/TEF72)"
<[email protected]> wrote:
Hi Martin,
> From my experience with SLES11 SP2 (with all current updates) I conclude that
> actually nobody is seriously running SP2 without local bugfixes.
That isn't quite true.
> E.g. Even the most simple examples from the official SuSE documentation don't
> work as expected.
Which ones?
> A trivial example is ocf:heartbeat:exportfs as distributed by SuSE with SP2
> causes unlimited growth of .rmtab files (goes fast in the gigabytes for
> serious NFS servers). I could work around this issue using some shell
> scripting.
This is an annoying bug, yes. It's an upstream bug that's been fixed
now. I'll check if the maintenance update is already released.
> There are other issues which are more than annoying and actually make the
> SLES SP2 HA Extension unusable for production systems. E.g. clvmd cannot be
> made less verbose from the cluster configuration. (No daemon_options="-d0"
> does not help!)
It shouldn't log that much even at the regular loglevel. It's reasonably
quiet (except on fail-/switch-overs, of course). What do you find
excessive?
> Not funny is also the fact that the official SLES 11 SP2 kernels crash
> seriously (when a node rejoins the cluster) when using STCP as
> recommended in the SLES HA documentation and offered via the wizards.
> It took me a while to find out what was going on.
We've not observed this. Have you reported a bug?
> When setting up a system with many (rather simple) resources funny things
> happen due to race conditions all over the place. (can be worked around
> mostly using arbitrary start-delay options.
I've not encountered this either. Sorry for asking this, but: did you
report a bug?
> Oh, did I mention that situations which are actually forbidden by constraints
> (e.g. using a score of INFINITY) actually do happen... Depending on the
> environment this can lead to not so funny effects.
That would be a serious bug in the policy engine (and not just limited
to SLE HA 11 SP2).
> E.g. I defined the following constraints:
>
> colocation c17 inf: p_lsb_ccslogserver p_fs_daten
> order o34 inf: p_fs_daten p_lsb_ccslogserver:start
>
> I can proof from the logs that ccslogserver (an application) got migrated
> from node A to node B while p_fs_daten (a filesystem on top of drbd) was
> definitely still running on node A
I'd be very, very interested in seeing these logs. The rules you
specified above should not allow for that, and I can't immediately
imagine other rules that still might allow for it.
> Reporting bugs is not possible without a direct support contract. (You must
> enter into a support contract with SuSE before you can even report a bug or
> provide a patch ....)
Strangely enough, enterprise distributions target paying customers. This
is not, I believe, a SUSE-specific constraint.
You can always file a bug against the upstream projects in the
respective communities; these will then possibly tell you to upgrade to
latest upstream first and reproduce. Eventually, these bugs will trickle
back into the enterprise distributions as well. That may just take a
while.
But yes, SLE HA (and RHEL clustering too) sort-of target customers who
have support contracts, either will SUSE/RHT or a strong consulting
partner (who preferably is a high-grade technology partner with the
distributor).
I admit I don't find this particular complaint convincing.
Regards,
Lars
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
