[gluster-internal] Keep or remove GlusterFS from EPEL-6?

[Bryan J Smith]

Kaleb S Keithley wrote:
> I don't see that as an issue. We're selling RHS/RHSSA to people to build
> server appliances.

That's just one certified/partner initiative as I understand it.  It's
storage software.  I'm not going to say anything else here on that
matter.

But if we're discussing how to proactively handle things in EPEL, I
would not (as the Fedora Project, other viewpoints may vary) try to
state what Red Hat may or may not do, especially looking to the
future.

David Egts wrote:
> Somewhat related...
> How do we plan to have a customer use GlusterFS as a native mount from
> a RHEL system?  We don't want them to inadvertently use our .com bits for the
> server and the EPEL bits for the native client, and we don't want the native clients
> to consume a Red Hat Storage entitlement to get the bits from that channel,
> correct?  Do we plan to put the .com GlusterFS native client bits in the mainline
> RHEL channel?  Right now, the RHSSA docs say that you're supposed to go to
> gluster.com to get them.
> http://docs.redhat.com/docs/en-US/Red_Hat_Storage_Software_Appliance/3.2/html-single/User_Guide/index.html#id3900239
> That doesn't sound right to me from a supportability standpoint.  GSS doesn't want
> to tell people to use community bits and instead be able to yum install them from a
> cryptographically signed and authenticated redhat.com source.

Kaleb S Keithley wrote:
> Customers will have many different clients and they are free to get
> bits to use from a variety of sources: 1) Fedora YUM repos, including
> possibly EPEL, 2) gluster.org download site, 3) build from source.

I have David's view here.  However ...

> I don't know, per se, how Red Hat Storage entitlements work, nor am I
> sure it's important for the sake of this discussion wrt where they
> get the bits for their clients.

I agree that is more a discussion for Red Hat, when it comes to client
and related support entitlements.

However, the greater issue for the Fedora Project's EPEL SIG, which
does affect Red Hat customers (which I've tried to maintain in all of
my responses is) ...

"How do ensure Red Hat customers with entitlements are not using or
relying on EPEL components?"

Remember ...
  community =
    { Fedora = { EPEL, Fedora, etc..}, community EL Rebuilds, 3rd
party repos, etc... }

EPEL is not the end-all, be-all.  As much as we want everything to
solve the issues for everyone, that's not going to happen.  I can only
offer how EPEL _has_ been sold inside of major enterprises and Red Hat
accounts, to make it on the list of approved software for release
deployment.  In virtually all cases, there are still other release
procedures, and it is not directly tapped and installed.  But
continued consideration of EPEL is going to related to reducing load
on the enterprise release teams.

I can completely understand some Red Hat customers are going to want
the more leading-edge releases of some Red Hat entitlement products.
I see many are still wrestling with renaming packages.  Then there are
issues of dependencies not in RHEL, but in an add-on entitlement,
having packages that are different versions than in Fedora and,
subsequently, EPEL.  There are a lot of issues.

At some point, maybe package renaming is not enough.  Which brings me to ...

Mike Snitzer wrote:
> That seems amazingly odd.  Why wouldn't we want RHEL to have the gluster client?

At many points in the RHEL product, Red Hat has taken a package or
support in an add-on entitlement, and moved it into base RHEL.  But
even when Red Hat does that, it's not guaranteed not to (in fact, it's
very likely) conflict with a newer, more leading edge version in
Fedora and, subsequently, EPEL.

So maybe what we're talking here is not really EPEL at all, but
something that is designed to preserve versions in RHEL by not
introducing newer ones in EPEL, or different package names in EPEL or
RHEL.  I've said it privately, but I'll now say it publicly ...

Maybe we're talking about something that offers "Emerging Technologies
for Enterprise Linux" (ETEL) in the greater Fedora Project.  Maybe
we're talking about sticking to what EPEL was designed to be, but
building out something like an "ETEL."

I think that work far better in the interests of everyone ...

Red Hat customers with production deployments (EPEL), Red Hat
customers who are early adopters of new technologies or new revisions
(more ETEL, where FastTrack and other options aren't the avenue), as
well as "EL Rebuilds" (who can rebuild production Red Hat add-on
software, but also redirect users to ETEL for more leading-edge), and
other community efforts, as well as Fedora itself.  ETEL would have
different guidelines than EPEL, including maintainers possibly needing
to drop packages due to rebasing in RHEL or infeasibility of RHEL
support due to newer dependencies in newer, leading edge releases
(that RHEL doesn't have).

Just an idea.  I think we're missing the greater point here that we're
talking EPEL specifically, not community, not greater Fedora Project,
which has the ability and will (or should) to change to accommodate as
many people as possible with its guidelines and, in this case, a
plausible, new option.


--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith