[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

----- 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.


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.


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!


David D. Egts, RHCA, RHCSS #805007796228001
Principal Architect, Red Hat, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]