FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 05-17-2012, 02:38 PM
Kaleb Keithley
 
Default Keep or remove GlusterFS from EPEL-6?

From: "David Egts" <degts@redhat.com>
>
> 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,

I don't see that as an issue. We're selling RHS/RHSSA to people to build
server appliances.

Customers will have many different clients and they are free to get
bits to use from a variety of sources: 1) Fedora YUM repos, including
possibly EPEL, 2) gluster.org download site, 3) build from source.

> and we don't want the native clients to consume a Red Hat Storage
> entitlement to get the bits from that channel, correct?

I don't know, per se, how Red Hat Storage entitlements work, nor am I
sure it's important for the sake of this discussion wrt where they
get the bits for their clients.

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

AFAIK we will never put GlusterFS — client or server — into mainline
RHEL. It will only be available as RHS/RHSSA with it's associated
Red Hat Storage channel.

But again, don't confuse Red Hat with gluster.org. There will be bits for
both server-side and client-side—available from a variety of sources, not
limited to the Fedora YUM repos and gluster.org download site.

--

Kaleb

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 03:23 PM
Mike Snitzer
 
Default Keep or remove GlusterFS from EPEL-6?

On Thu, May 17 2012 at 10:38am -0400,
Kaleb Keithley <kkeithle@redhat.com> wrote:

> From: "David Egts" <degts@redhat.com>
> > 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.
>
> AFAIK we will never put GlusterFS — client or server — into mainline
> RHEL. It will only be available as RHS/RHSSA with it's associated
> Red Hat Storage channel.

That seems amazingly odd. Why wouldn't we want RHEL to have the gluster
client?

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 03:47 PM
Bryan J Smith
 
Default Keep or remove GlusterFS from EPEL-6?

Kaleb S Keithley wrote:
> I don't see that as an issue. We're selling RHS/RHSSA to people to build
> server appliances.

That's just one certified/partner initiative as I understand it. It's
storage software. I'm not going to say anything else here on that
matter.

But if we're discussing how to proactively handle things in EPEL, I
would not (as the Fedora Project, other viewpoints may vary) try to
state what Red Hat may or may not do, especially looking to the
future.

David Egts wrote:
> 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/html-single/User_Guide/index.html#id3900239
> 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.

Kaleb S Keithley wrote:
> Customers will have many different clients and they are free to get
> bits to use from a variety of sources: 1) Fedora YUM repos, including
> possibly EPEL, 2) gluster.org download site, 3) build from source.

I have David's view here. However ...

> I don't know, per se, how Red Hat Storage entitlements work, nor am I
> sure it's important for the sake of this discussion wrt where they
> get the bits for their clients.

I agree that is more a discussion for Red Hat, when it comes to client
and related support entitlements.

However, the greater issue for the Fedora Project's EPEL SIG, which
does affect Red Hat customers (which I've tried to maintain in all of
my responses is) ...

"How do ensure Red Hat customers with entitlements are not using or
relying on EPEL components?"

Remember ...
community =
{ Fedora = { EPEL, Fedora, etc..}, community EL Rebuilds, 3rd
party repos, etc... }

EPEL is not the end-all, be-all. As much as we want everything to
solve the issues for everyone, that's not going to happen. I can only
offer how EPEL _has_ been sold inside of major enterprises and Red Hat
accounts, to make it on the list of approved software for release
deployment. In virtually all cases, there are still other release
procedures, and it is not directly tapped and installed. But
continued consideration of EPEL is going to related to reducing load
on the enterprise release teams.

I can completely understand some Red Hat customers are going to want
the more leading-edge releases of some Red Hat entitlement products.
I see many are still wrestling with renaming packages. Then there are
issues of dependencies not in RHEL, but in an add-on entitlement,
having packages that are different versions than in Fedora and,
subsequently, EPEL. There are a lot of issues.

At some point, maybe package renaming is not enough. Which brings me to ...

Mike Snitzer wrote:
> That seems amazingly odd. Why wouldn't we want RHEL to have the gluster client?

At many points in the RHEL product, Red Hat has taken a package or
support in an add-on entitlement, and moved it into base RHEL. But
even when Red Hat does that, it's not guaranteed not to (in fact, it's
very likely) conflict with a newer, more leading edge version in
Fedora and, subsequently, EPEL.

So maybe what we're talking here is not really EPEL at all, but
something that is designed to preserve versions in RHEL by not
introducing newer ones in EPEL, or different package names in EPEL or
RHEL. I've said it privately, but I'll now say it publicly ...

Maybe we're talking about something that offers "Emerging Technologies
for Enterprise Linux" (ETEL) in the greater Fedora Project. Maybe
we're talking about sticking to what EPEL was designed to be, but
building out something like an "ETEL."

I think that work far better in the interests of everyone ...

Red Hat customers with production deployments (EPEL), Red Hat
customers who are early adopters of new technologies or new revisions
(more ETEL, where FastTrack and other options aren't the avenue), as
well as "EL Rebuilds" (who can rebuild production Red Hat add-on
software, but also redirect users to ETEL for more leading-edge), and
other community efforts, as well as Fedora itself. ETEL would have
different guidelines than EPEL, including maintainers possibly needing
to drop packages due to rebasing in RHEL or infeasibility of RHEL
support due to newer dependencies in newer, leading edge releases
(that RHEL doesn't have).

Just an idea. I think we're missing the greater point here that we're
talking EPEL specifically, not community, not greater Fedora Project,
which has the ability and will (or should) to change to accommodate as
many people as possible with its guidelines and, in this case, a
plausible, new option.


--
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
 
Old 05-17-2012, 04:28 PM
Kevin Fenzi
 
Default Keep or remove GlusterFS from EPEL-6?

On Thu, 17 May 2012 11:38:35 +0100
Karanbir Singh <mail-lists@karan.org> wrote:

> Addressing this from the CentOS point of view, in that lots of CentOS
> users consume EPEL as well : We would be happy to bridge that gap and
> host stuff like glusterfs directly in CentOS-Extras, which is setup
> and enabled by default on all CentOS installs.
>
> However, I am slightly concerned about this move. Glusterfs is a
> single example : there are a lot of things that are shipped by Red
> Hat under various variants and layered products that overlap with
> content hosted in EPEL - including stuff like puppet, mongodb, lots
> of python-* and ruby-* etc; so rather than single out glusterfs and
> drop it, please clarify the policy.

I agree. This is not just about glusterfs.

> My, as an outsider understanding, has been that components unsuiteable
> for EPEL include exclusively content hosted at ftp.r.c under the OS/
> dir
> - I suspect this is the impression carried forward by many ( if not
> most ) people.

Yeah, and at launch time of EPEL6 thats pretty much what it was, since
there were not really any other additional channels available then.

Things have changed over time however.

kevin


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 04:39 PM
Kevin Fenzi
 
Default Keep or remove GlusterFS from EPEL-6?

On Thu, 17 May 2012 11:47:29 -0400
Bryan J Smith <b.j.smith@ieee.org> wrote:

...snip...

> However, the greater issue for the Fedora Project's EPEL SIG, which
> does affect Red Hat customers (which I've tried to maintain in all of
> my responses is) ...
>
> "How do ensure Red Hat customers with entitlements are not using or
> relying on EPEL components?"

Indeed. This is a situation we sure want to avoid.

...snip...

> At some point, maybe package renaming is not enough. Which brings me
> to ...

Yeah, package renaming is going to add to confusion a lot of times, not
help it. ;(

...snip...

> Maybe we're talking about something that offers "Emerging Technologies
> for Enterprise Linux" (ETEL) in the greater Fedora Project. Maybe
> we're talking about sticking to what EPEL was designed to be, but
> building out something like an "ETEL."
>
> I think that work far better in the interests of everyone ...

There has been discussion of this kind of thing in the past. Issues
have been:

* What can be in this repo? We would need very clear guidelines.
Would it be for shipping foobar2.0 when RHEL ships 1.0?
Would it be ok to ship foobar 1.0 when RHEL ships 2.0?

* Resources. Would there be enough interest in such a repo to justify
the rel-eng, mirroring, etc resources it would take up?

> Red Hat customers with production deployments (EPEL), Red Hat
> customers who are early adopters of new technologies or new revisions
> (more ETEL, where FastTrack and other options aren't the avenue), as
> well as "EL Rebuilds" (who can rebuild production Red Hat add-on
> software, but also redirect users to ETEL for more leading-edge), and
> other community efforts, as well as Fedora itself. ETEL would have
> different guidelines than EPEL, including maintainers possibly needing
> to drop packages due to rebasing in RHEL or infeasibility of RHEL
> support due to newer dependencies in newer, leading edge releases
> (that RHEL doesn't have).

Right.

> Just an idea. I think we're missing the greater point here that we're
> talking EPEL specifically, not community, not greater Fedora Project,
> which has the ability and will (or should) to change to accommodate as
> many people as possible with its guidelines and, in this case, a
> plausible, new option.

yeah.

I think we need more data to really move forward much more here, and
Smooge is looking at gathering the src.rpm data from 6/* repos, so we
can know at least whats affected here. (glusterfs is far from the only
thing)

Once we have that data, we can look at alternatives, discuss and see if
we can reach a consensus on how to move forward.

One curious thing to me is that since we messed up dropping things when
the new channels appeared, how much pain has the overlap caused anyone?
Does anyone know of folks who had the EPEL gluster installed rather
than the RHS version or the like? I'm curous that we haven't heard much
about this for many months...

Anyhow, I think we can look at data and come up with a plan, weather
that plan is another repo with new rules, removing things, deciding on
a channel by channel basis what we overlap with, etc.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 07:28 PM
Kaleb Keithley
 
Default Keep or remove GlusterFS from EPEL-6?

From: "Mike Snitzer" <snitzer@redhat.com>
>
>> From: "David Egts" <degts@redhat.com>
>> > 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.
>>
>> AFAIK we will never put GlusterFS — client or server — into mainline
>> RHEL. It will only be available as RHS/RHSSA with it's associated
>> Red Hat Storage channel.
>
>That seems amazingly odd. Why wouldn't we want RHEL to have the gluster
>client?

Fair point. At the present time we don't have a client-side-only RPM,
so what I really meant is that based on the way it's packaged today, we
wouldn't put it into RHEL.

--

Kaleb

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-21-2012, 08:33 PM
Dennis Gilmore
 
Default Keep or remove GlusterFS from EPEL-6?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 May 2012 14:32:23 +0200
Niels de Vos <devos@fedoraproject.org> 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?

So i think here its up to the gluster team what they want to do. For
instance Satellite has pulled in a bunch of EPEL packages and ship them
in satellite. things like cobbler, koan, perl modules and various other
bits and pieces. they pull them in with the intention of them remaining
in EPEL. I believe some of the other layered products do this also, I
think that something that ships in a layered product should be shipable
in EPEL but if the layered product asks us to remove it we should do
so. most/all layered products are only available with additional
subscriptions. which limits the availablity and AFAIK CentOS Scientific
Linux etc dont ship all layered products.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk+6pogACgkQkSxm47BaWfd9nACeKByMR80SBj W6x71jZoXgEZXC
qT0AoKpnIA/k6cFz19B8KqPlavb+umEU
=BIv5
-----END PGP SIGNATURE-----

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-23-2012, 03:15 PM
Niels de Vos
 
Default Keep or remove GlusterFS from EPEL-6?

On Mon, May 21, 2012 at 10:33 PM, Dennis Gilmore <dennis@ausil.us> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 16 May 2012 14:32:23 +0200
> Niels de Vos <devos@fedoraproject.org> 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?
>
> So i think here its up to the gluster team what they want to do. *For
> instance Satellite has pulled in a bunch of EPEL packages and ship them
> in satellite. things like cobbler, koan, perl modules and various other
> bits and pieces. they pull them in with the intention of them remaining
> in EPEL. I believe some of the other layered products do this also, *I
> think that something that ships in a layered product should be shipable
> in EPEL but if the layered product asks us to remove it we should do
> so. most/all layered products are only available with additional
> subscriptions. which limits the availablity and AFAIK CentOS Scientific
> Linux etc dont ship all layered products.

My main concern is that different versions of GlusterFS (3.2.x vs
3.3.x) are not compatible. It will not be possible to use the EPEL
3.2.x version to mount a volume with the native GlusterFS protocol
from the Red Hat Storage 2.0 (RHS) appliance which is based on
GlusterFS 3.3.x. The previous release called Red Hat Storage Software
Appliance 3.2 (RHSSA) uses GlusterFS 3.2...

One release or the other would have problems :-/

Niels


> Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iEYEARECAAYFAk+6pogACgkQkSxm47BaWfd9nACeKByMR80SBj W6x71jZoXgEZXC
> qT0AoKpnIA/k6cFz19B8KqPlavb+umEU
> =BIv5
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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
 
Old 05-23-2012, 07:53 PM
Bryan J Smith
 
Default Keep or remove GlusterFS from EPEL-6?

Niels de Vos wrote:
> My main concern is that different versions of GlusterFS (3.2.x vs
> 3.3.x) are not compatible. It will not be possible to use the EPEL
> 3.2.x version to mount a volume with the native GlusterFS protocol
> from the Red Hat Storage 2.0 (RHS) appliance which is based on
> GlusterFS 3.3.x. The previous release called Red Hat Storage Software
> Appliance 3.2 (RHSSA) uses GlusterFS 3.2...
> One release or the other would have problems :-/

I instantly thought of that when this first came up, as RHS 2.0 was
clearly on my mind. But then going to the other way, what happens
when RHS 2.0 is "2-3 years old," and people want Gluster 3.4, 4.0,
etc...? The fact that the RHS* product lines exist changes
everything, regardless of what was done before.

Again, thinking of RHS 2.0 was my #1 reason for posting from the
get-go, as much as I was also, and quite selfishly, thinking of the
enterprises I work with.

Is EPEL really where layered products go?
Where does the bit-for-bit compatibility start and end in "EL Rebuilds"?
What about leading edge v. trailing edge for both?

And my greater thought ...

Shouldn't it be the trailing-edge OS where things become more and more
commodity (with more users, so fewer $$$ per users to develop,
backport, etc...)? And the layered products be where the sustaining
costs -- backporting, certification, support, etc... -- end up being
more focused on (with less users, so more $$$ per user to develop,
backport, etc...)? At the same time, there will still be some Red Hat
customers that feel layered products are "too slow moving," and they
will want more leading edge (without certification, support, etc...).

Again, just "my greater thought." I'm not trying to state policy.
There's just a lot of things people don't always consider, but the
Fedora leadership ends up having to make hard answers on (often
upsetting some).


Dennis Gilmore wrote:
> AFAIK CentOS Scientific Linux etc dont ship all layered products.

Even ignoring the fact that Advanced Platform entitlements became
layered with EL6, I've noted several, layered products in CentOS
Extras over the years. I've noted a lot of assumptions in this thread
that aren't always the case. Again, nothing to do with policy either
way, just history and reality.

Again, I don't know and cannot speak about the policies of such
efforts, but if layered products are in EPEL, it does reduce any
consideration for EPEL with Red Hat customers who do pay for layered
products, as they will conflict.

I don't envy those who have to make the difficult decisions in the
Fedora Project on this matter. They will never please everyone.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-23-2012, 08:42 PM
Stephen John Smoogen
 
Default Keep or remove GlusterFS from EPEL-6?

On 23 May 2012 13:53, Bryan J Smith <b.j.smith@ieee.org> wrote:

> Again, I don't know and cannot speak about the policies of such
> efforts, but if layered products are in EPEL, it does reduce any
> consideration for EPEL with Red Hat customers who do pay for layered
> products, as they will conflict.
>
> I don't envy those who have to make the difficult decisions in the
> Fedora Project on this matter. *They will never please everyone.

I think that for customers using layered products it would be smarter
to avoid outside repositories anyway. If a customer is using layered
items onto the OS they are going to need to make sure they have only
Red Hat supported software installed. Even if we were to somehow
remove all the conflicts we can't remove secondary problems where
software if it finds libXYZ installed will manually load that even if
it is not included with RHEL. [Various gnome apps do this so I expect
other software will also end up with such "plugin" architectures.]

--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." *—James Stewart as Elwood P. Dowd

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

Thread Tools




All times are GMT. The time now is 10:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org