Keep or remove GlusterFS from EPEL-6?

[Bryan J Smith]

On Wed, May 16, 2012 at 2:32 PM, Kaleb S. KEITHLEY <kkeithle at redhat.com> wrote:
> Three points:
> 1. RHS is intended to be deployed on special purpose "appliances."

Don't confuse supported with certified.  They are two different terms.
 Red Hat supports many configurations.  Red Hat IHV/ISV partners
certifies a subset of those supported configurations.

I deal with this daily (sometimes hourly) myself.  ;)

> In the storage world people don't use their storage appliances as general
> purpose machines; they're dedicated storage machines.
> Only those who have an RHS entitlement would/should be allowed to subscribe
> to the Red Hat Storage channel, and I believe it would be highly unusual for such a
> customer to also subscribe their RHS appliance to other repos, including
> the Fedora EPEL repo.

I'll point out at least one major oversight in this assumption:  Monitoring
I can also think of about a half-dozen other reasons customers might
tap EPEL here.

> Enterprises aren't going to jeopardize their valuable data by using
> unsupported configurations.

Enterprises approve and release community software all-the-time, not
just IHV and ISV software, on their Red Hat systems.  They like EPEL
as it provides many advantages over their own maintaining of upstream
software.

Also remember several enterprises employ maintainers are contributors
to Fedora and EPEL.  Continued interest to contribute to EPEL is very
likely also dependent on working with Red Hat released and supported
releases.

> 2. I'm pretty sure it's the case that you can only get RHS updates, e.g.
> glusterfs, and nothing else, from the Red Hat Storage channel.

As with Clustering, Directory Services, etc...  Child channels are
additional entitlement offerings from Red Hat that are supported,
certified with IHVs/ISVs in select configurations, etc...

Many "EL Rebuilds" can and have taken the liberty to download the
source, build, repackage and redistribute those additional
entitlements as well.  There's nothing stopping them from continuing
in this role, as Storage now moves from a non-productized software to
one that is an additional Red Hat entitlement.

> Any regular RHEL or CentOS users who discover this channel, and who ought to
> have access to the EPEL repo, only stands to encounter potential
> confusion for glusterfs.

Maybe I read that incorrectly, but I think that is exactly 180 degrees
from the guidelines.  ;)

> 3. Niels mentioned it, but I think it merits repeating: GlusterFS has
> been shipping EPEL6 RPMs since at least 2010, including GlusterFS-3.2.1
> in June 2011. (FYI, RHS started shipping in November 2011 after the
> acquisition in October 2011.) It ought to be grandfathered regardless of
> any other consideration.

This isn't the first time this has happened.  Red Hat has taken a
codebase that it contributes to, even sponsors and/or purchases and
ends up productizing it per customer requirements for support and/or
certification.  It won't be the last either.  It's a delicate balance
that I continually appreciate and thank the EPEL maintainers for.

So the answer shouldn't be to look to the Fedora Project, but to look
to the "EL Rebuild" projects to accommodate this change, like they
currently do for Clustering, Directory Services, etc...  Many claim to
strive for bit-for-bit compatibility with Red Hat product offerings,
so this is their area.

> We (as in Red Hat, Fedora Project, and Gluster.org) have been providing
> glusterfs RPMs for EPEL6 (and EPEL5) for a long time, and if we stop,
> we're taking something away from the community.

It's still in Fedora.  It can still be in "EL Rebuild" repositories as
well.  Nothing is being taken away from the community.  The guidelines
seem to address this very well.

>From my view, the guidelines were written to avoid this very detail.
Again, it's happened before.  And it will happen again.  They do a
great job of addressing it, to avoid marginalizing Red Hat customers,
at least that has been my experience (first hand, at customer sites
with EPEL deployed).


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