From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] skipping unused services, cman_tool join -A
Date: Thu, 28 Jan 2010 10:30:18 -0600 [thread overview]
Message-ID: <20100128163018.GA19413@redhat.com> (raw)
In-Reply-To: <4B6154AA.10806@redhat.com>
On Thu, Jan 28, 2010 at 09:11:06AM +0000, Christine Caulfield wrote:
> So, let me get this straight. For a cman upgrade you want to load the
> same services as before. But for a new full-featured RHEL6 cluster suite
> you think we should load fewer services, thus removing features ?
Exactly, removing unnecessary features is one of the nicest features we
can add IMO!
> To me it seems like a pointless bit of added complication, for us and
> users. If the service is still to be shipped then what do we gain by
> simply making it more difficult to use? So far Perry's argument is that
> we don't *ship* things we can't support, thus preventing people from
> using them at all unless they compile it themselves. But this is
> different in that we have to ship the openais modules anyway, so
> disabling them is merely being wilfully obscure. It's a bit like
> shipping a command-line tool that was in RHEL5, but on RHEL6 insists on
> having the first parameter "PLEASE" before it will do anything.
>
> I'm not really passionately in favour of either way, I just don't see
> any benefit to us, or (more importantly) to customers, from changing it.
We were trying to stick to technical issues and leave all the "support"
issues to higher-ups, but support is clearly part of it. This came up
because we do not want to support these other services in any official
way, I've been told. So, the step of not loading these services is a
first, small, necessary step toward not supporting them. Next, others can
sort out whether a product should leave out the services, or include with
caveats, or something else...
I'm not passionately in favor of either way either, I was just trying to
help sort our the technical steps involved in unsupporting them.
Dave
next prev parent reply other threads:[~2010-01-28 16:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-25 19:27 [Cluster-devel] skipping unused services, cman_tool join -A David Teigland
2009-09-25 19:31 ` David Teigland
2009-10-02 14:55 ` David Teigland
2010-01-27 20:49 ` David Teigland
2010-01-27 20:51 ` Steven Dake
2010-01-27 21:38 ` David Teigland
2010-01-28 1:04 ` Steven Dake
2010-01-28 9:11 ` Christine Caulfield
2010-01-28 16:30 ` David Teigland [this message]
2010-01-27 21:32 ` Ryan O'Hara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100128163018.GA19413@redhat.com \
--to=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).