On Wed, May 16, 2012 at 1:57 PM, Bryan J Smith <b.j.smith(a)ieee.org> wrote:
On Wed, May 16, 2012 at 2:32 PM, Kaleb S. KEITHLEY
<kkeithle(a)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