[openfabrics-ewg] RHEL4 and RHEL5 support requirements

[Doug Ledford]

This was brought up at the recent meeting in Tampa between myself and
Hal, and we thought it deserved specific mention on the mailing list.
However, the idea that anyone expects what this email mentions as being
impossible is hearsay to me, so if the shoe doesn't fit, don't throw it
at me.

There is a question as to what Red Hat will support in our upcoming
releases regarding fabric management.  Specifically, will we support
OpenSM, vendor specific switch management solutions, or a mixture of
both?

The answer to that is that Red Hat will support customers that have
fabric management related problems only so long as they are running
OpenSM exclusively to maintain their switch fabric.  If the customer is
running an embedded fabric management application in their switch, then
the customer will need to contact the switch vendor for problems related
to fabric management.

Some people may find that a bit restrictive, so I wanted to elaborate
just a minute on why that is.  To be blunt, we have access to OpenSM
source code, can fix bugs, and can troubleshoot issues.  We have no
access to vendor proprietary software built into their switches.
Period.  We have no ability to fix issues, and no ability to diagnose
issues.  Period.  Offering support for something you can do nothing
about is not a way to please the customer.  The answer "sorry, I don't
have access to the switch manufacturer's source code" when answering a
problem from a customer that expects to receive their dollar's worth on
paid support for their problem is not acceptable.

Really, when you think about it, this should be no surprise to anyone.
Never has Red Hat offered support for the custom switch software in
fiber channel switches, nor have we ever offered support for the Cisco
IOS embedded in their various hardware.  This is no different, with the
one exception that OpenSM exists on InfiniBand where as nothing of the
sort exists to manage the fabric itself under the various big iron gig-e
switches or fiber channel switches.  In those cases, customers already
know and expect that if their Cisco switch develops a problem related to
management of the gig-e network backbone, they call Cisco, not Red Hat.

So, the only gray area that leaves is what is Red Hat's plan when
running both OpenSM and a vendor embedded fabric management solution on
a fabric at the same time?  If the customer can replicate the problem
with the switch management turned off and only using OpenSM, then we
will investigate and support the issue.  Much like we can't support
users that load binary only video driver modules into their kernel, we
also can't diagnose or support interoperability issues between OpenSM
and switch management software we have no visibility into.

I hope this isn't a surprise to many people, it really shouldn't be.
However, it does underscore the need to either A) formalize the more
advanced options of fabric management so that embedded fabric controller
and OpenSM can interoperate reliably or B) move what is currently
various proprietary features from multiple switch vendors into OpenSM so
that the switch vendors can offload support issues to distributors (as
that seems to be their desire) or C) switch vendors will need to
understand and plan for the fact that the support offload mentioned in B
is impossible given the current environment and should expect to keep
that responsibility on themselves.  Any of the above is acceptable to
me, it is only the impossible option D) switch vendors keep their
advanced, proprietary features both non-standardized and to themselves
while expecting Red Hat or Novell to provide end user support when that
embedded software results in fabric problems that I know we can't do.

But, to repeat from my opening, the idea that anyone wants the
impossible option D above is hearsay to me, so if that isn't your
particular case, please just ignore my email ;-)

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20061119/079649b3/attachment.sig>