Keep or remove GlusterFS from EPEL-6?

[Greg Swift]

On Wed, May 16, 2012 at 1:57 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> 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).

So as a RHEL, Gluster, and EPEL customer/user I have to say that I see
the benefit of it being in EPEL.  There is even a benefit to Red Hat
(first hit is free kinda thing) with Gluster staying in EPEL.  But
isn't there a technical solution to this. Is this what yum priorities
is all about?  Why doesn't the epel-release package require
yum-{,plugin}-priorities and set the priority of all EPEL repositories
lower than the standard one.  In theory the policy itself implements
this, but it doesn't negate the usefulness of backing up the policy
with config.

It also can provide a benefit for groups that may mirror some EPEL
packages to a local repository.   If the internal system ends up with
the local repository and EPEL attached (for various reasons I'm not
going to delve into) then the internal one would win because its
unlikely that anyone would set the priority lower than the EPEL by
default (although not beyond realm of possibility, but you can't save
everyone).

-greg