----- Original Message -----
(Sorry for the fubar subject in the previous post.)
On May 16, 2012, at 2:32 PM, Niels de Vos wrote:
> Hello,
>
> in #gluster on Freenode, we discussed a little if GlusterFS is
> allowed in EPEL-6.
>
> The policy that may forbid GlusterFS in EPEL-6:
>
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy
> mentions "packages from EPEL should never replace packages from the
> target base distribution - including those on the base distribution
> as well as layered products".
>
> The Red Hat Storage product that includes GlusterFS is like an
> appliance. Customers who buy a subscription get access to a DVD
> download of RHEL-6.2.z (Extended Update Support, EUS) with the
> packages from an additional RHN-ChildChannel. It is not
> possible/intended/supported to use this RHN-ChildChannel without
> installing your system from the "Red Hat Storage" DVD. Therefore
> this
> RHN-ChildChannel is a little different from other layered products.
>
> The first time a Red Hat product that includes GlusterFS was
> released
> in November 2011. EPEL-6 already contained the GlusterFS packages.
> The EPEL-policy was not harmed, but now GlusterFS is made available
> by Red Hat, and it is possible to have two sources for GlusterFS
> (one
> being EPEL-6, the other through the Red Hat Storage ChildChannel).
Three points:
1. RHS is intended to be deployed on special purpose "appliances." 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. Enterprises aren't going to jeopardize their
valuable data by using unsupported configurations.
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. 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.
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.
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.
You'd probably want to make sure the RPM names don't collide.
I do know that we do have some (not all) .org variants of other Red Hat products in EPEL.
Like 389 is the .org variant of Red Hat Directory Server and it's in EPEL.
http://directory.fedoraproject.org/wiki/Download
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/...
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. That's one of the key
values of the Subscription. Also note that
http://download.gluster.com/pub/gluster/glusterfs/3.2/LATEST/ includes bits for Ubuntu,
CentOS, Fedora, etc. Do we support them too? Again, that's another area where we
could get into trouble with customers where support couple be implied since our docs point
to that content.
Thanks for soliciting feedback Kaleb!
Dave
--
David D. Egts, RHCA, RHCSS #805007796228001
Principal Architect, Red Hat, Inc.