Keep or remove GlusterFS from EPEL-6?
 

Hello,

in #gluster on Freenode, we discussed a little if GlusterFS is allowed
in EPEL-6. EPEL-5 is not affected as Red Hat does not provide packages
for GlusterFS on RHEL-5.


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


The question I have now:
Is it needed to block the glusterfs package from EPEL-6? Even if most
RHEL users will not have access to EUS channel(s) that contain the
glusterfs packages?


Thanks,
Niels

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

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. EPEL-5 is not affected as Red Hat does not provide packages for GlusterFS on RHEL-5.
>
> 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).
>
> The question I have now:
> Is it needed to block the glusterfs package from EPEL-6? Even if most RHEL users will not have access to EUS channel(s) that contain the glusterfs packages?
>

My understanding is that glusterfs does not (and preferably for me at least) should not be removed:

http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_know_which_packages_are_part_of_RHEL .3F

states what packages should be considered as a conflict, .. I thought some where was page that
exactly dealt with the extra RHEL streams however the Guidelines link you posted suggest I may be wrong though
given the binary derivatives don't genrally distribute these extra streams its a bit of a tall order.

See:


> Thanks,
> Niels
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

On 05/16/2012 02:42 PM, Steve Traylen wrote:


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. EPEL-5 is not affected as Red Hat does not provide packages for GlusterFS on RHEL-5.

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

The question I have now:
Is it needed to block the glusterfs package from EPEL-6? Even if most RHEL users will not have access to EUS channel(s) that contain the glusterfs packages?



My understanding is that glusterfs does not (and preferably for me at least) should not be removed:

http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_know_which_packages_are_part_of_RHEL .3F

states what packages should be considered as a conflict, .. I thought some where was page that
exactly dealt with the extra RHEL streams however the Guidelines link you posted suggest I may be wrong though
given the binary derivatives don't genrally distribute these extra streams its a bit of a tall order.

See:



Not sure if it helps, but the packages are here:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHS/2.0/SRPMS/

They are not under the "os" directory where most packages live:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/

It may not be a problem for binary derivatives of RHEL if they don't
provide glusterfs packages. But this may be a problem for people who use
the Red Hat Storage bits.


Cheers,
Niels

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

On Wed, May 16, 2012 at 3:09 PM, Niels de Vos <devos@fedoraproject.org> wrote:
> But this may be a problem for people who use the Red Hat Storage bits.

Why do they need to have EPEL repo enabled? Doesn't that make them unsupported?

Cheers,
Alan

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

Niels de Vos wrote:
> They are not under the "os" directory where most packages live:
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/
> It may not be a problem for binary derivatives of RHEL if they don't provide glusterfs packages.
> But this may be a problem for people who use the Red Hat Storage bits.

Far be it from me to interpret policy, so I'll just point how this
comment nails the reality, and let others with the project decide.

I.e., ask yourself ...
Is the Fedora Project's EPEL just for community "EL Rebuilds" and derivatives?
Or is EPEL for all, including the customers of the Fedora Project's
sponsor, Red Hat?

Alan Pevec wrote:
> Why do they need to have EPEL repo enabled? Doesn't that make them unsupported?

Again, here's the reality, and I'll let others with the project decide ...

Yes, major Red Hat accounts tap EPEL, often bringing in the the EPEL
YUM repository into their RHN Satellite Server. It saves them having
to build all sorts of upstream community solutions. And yes, of
course, these components in EPEL are _unsupported_. But they remove
not just a lot of the overhead of customers building-their-own, but
the policies and other advantages of the Fedora Project itself can be
leveraged.

Leaving them in EPEL means that Red Hat customers now must clone and
segment out the conflicting bits. Although many accounts end up
cloning channels into "internal releases" so the test EPEL components,
it's still going to add to their workload.

And with that all said, as I understand it, one of the reason for the
EPEL guidelines were so Red Hat customers would not have conflicting
components in EPEL that are also available from RHN. Two, conflicting
sets of packages on the same server, that is really, really
_unsupported_, and causes headaches for Red Hat services and support.
I.e., sometimes it takes a bit before this "root cause" is discovered
(first hand experience speaking here). ;)

Which brings me to the final point, which is non-technical ...

Marginalizing Red Hat customers, ones who fund a lot of what Red Hat
does upstream (and downstream as well), is not probably the best move
for the longevity of the Fedora Project, or "EL Rebuilds" who rely on
Red Hat's continued funding. This should be obvious to many here, but
I understand there might be some community members here who may not
see this immediately (hence why I'm pointing it out).

Again, far be it from me to interpret policy, but to me, if it is in a
RHN channel, it makes more sense for downstream "EL Rebuilds" to fetch
the source, rebuild, and include it in their redistributions. Any
time one goes down the route of asking, "well, is this really OS?"
ignores the fact that it is available from RHN, and will affect
customers of Red Hat. Red Hat is more than an open source OS, and
even more than just platform components.

Otherwise it is going to get really ugly for Red Hat customers, and
EPEL will lose its value with them. That's really a case no one
should want to see, as it will affect everyone, not just Red Hat and
its customers. Of course, I could be biased. ;)


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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

On Wed, May 16, 2012 at 3:27 PM, Alan Pevec <apevec@gmail.com> wrote:
> On Wed, May 16, 2012 at 3:09 PM, Niels de Vos <devos@fedoraproject.org> wrote:
>> But this may be a problem for people who use the Red Hat Storage bits.
>
> Why do they need to have EPEL repo enabled? Doesn't that make them unsupported?

No. Red Hat does not support software coming from EPEL, but users are
free to install additional software on their RHEL-systems. EPEL is
just one well known source for Open Source Software from the Fedora
Project. EPEL in this sense is not different from any other non Red
Hat delivered software.

Cheers,
Niels

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

On Wed, 16 May 2012 15:09:10 +0200
Niels de Vos <devos@fedoraproject.org> wrote:

> Not sure if it helps, but the packages are here:
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHS/2.0/SRPMS/
>
> They are not under the "os" directory where most packages live:
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/
>
> It may not be a problem for binary derivatives of RHEL if they don't
> provide glusterfs packages. But this may be a problem for people who
> use the Red Hat Storage bits.

My understanding from long ago when we last discussed this was:

EPEL will not ship anything that's available in src.rpm format under
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server

Now, some of the newer channels like RHS were not there when we
launched EPEL6, so if lots of people think we should revisit this, we
could.

Some data:

EPEL6 currently builds against the following RHEL channels:
http://koji.fedoraproject.org/koji/taginfo?tagID=140

Server, Server-ha, Server-optional, Server-lb.

In the past some teams have asked us specifically to include their
packages even though they are in another channel (I think spacewalk
folks asked for this) as they used EPEL as an early testing branch.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

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

--

Kaleb

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

On Wed, May 16, 2012 at 2:32 PM, Kaleb S. KEITHLEY <kkeithle@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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Keep or remove GlusterFS from EPEL-6?
 

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list