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-23-2012, 08:54 PM
Bryan J Smith
 
Default Keep or remove GlusterFS from EPEL-6?

Stephen John Smoogen wrote:
> I think that for customers using layered products it would be smarter
> to avoid outside repositories anyway.

That would then remove the value of an option from the Fedora
community like EPEL. That's why I asked prior what the purpose of
EPEL is, regardless of any prior assumptions or statements. If it is
going to deliver layered products, I will have to advise enterprises
of those details.

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

So that now brings up another question ...

If they only have the base entitlement product installed, this is not the case?
I.e., if they have no layered products, they can use EPEL. But if
they do, they can't?

And if we have difficulty with that question, is it really Extra
Package for Enterprise Linux (EPEL) any more?

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

Ideally layered products should push any libraries, those shared
between or utilized between layers, into the base OS for support.
That way there is no question what should and should not conflict with
a Fedora SIG like EPEL, assuming the guidelines are to avoid such.

I stress "ideally" because we all know how long any product release
considerations, let alone changes, take to verify countless items and
make those types of decisions.

> [Various gnome apps do this so I expect other software will also end up
> with such "plugin" architectures.]

Indeed. But then we run into the related issues where Fedora is more
leading edge, and EPEL uses something more leading edge. But there
are still some customers who want those additional plug-ins for the
trailing edge versions in RHEL or its layered products, but those
plug-ins do not ship with them.

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

On 23 May 2012 14:54, Bryan J Smith <b.j.smith@ieee.org> wrote:
> Stephen John Smoogen wrote:
>> I think that for customers using layered products it would be smarter
>> to avoid outside repositories anyway.
>
> That would then remove the value of an option from the Fedora
> community like EPEL. ¬*That's why I asked prior what the purpose of
> EPEL is, regardless of any prior assumptions or statements. ¬*If it is
> going to deliver layered products, I will have to advise enterprises
> of those details.

Well here is the issue. We have been delivering layered products for a
long time (probably since the beginning) mainly because various groups
did not want to do an Emerging Technologies for Enterprise Linux.

>> 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.
>
> So that now brings up another question ...
>
> If they only have the base entitlement product installed, this is not the case?
> I.e., if they have no layered products, they can use EPEL. ¬*But if
> they do, they can't?
>
> And if we have difficulty with that question, is it really Extra
> Package for Enterprise Linux (EPEL) any more?

Hey they can use whatever they want. It is up to entities I have no
say or control in whether it will be supported by either consultants
or Red Hat support.

The issue is that if EPEL pulls out core packages every time Red Hat
decides to offer a sub-channel of supported, then there is no need for
EPEL since it will get gutted regularly. At this point we are looking
at 1/3->1/2 of EPEL having to be removed because packages require or
buildrequire items that are included in layered products that would no
longer be available to build against. Which leads me to my first
statement, that the usability of EPEL to a layered user is much less
than a base OS user.

>> 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.
>
> Ideally layered products should push any libraries, those shared
> between or utilized between layers, into the base OS for support.
> That way there is no question what should and should not conflict with
> a Fedora SIG like EPEL, assuming the guidelines are to avoid such.
>
> I stress "ideally" because we all know how long any product release
> considerations, let alone changes, take to verify countless items and
> make those types of decisions.
>
>> [Various gnome apps do this so I expect other software will also end up
>> with such "plugin" architectures.]
>
> Indeed. ¬*But then we run into the related issues where Fedora is more
> leading edge, and EPEL uses something more leading edge. ¬*But there
> are still some customers who want those additional plug-ins for the
> trailing edge versions in RHEL or its layered products, but those
> plug-ins do not ship with them.
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list



--
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
 
Old 05-23-2012, 09:50 PM
Bryan J Smith
 
Default Keep or remove GlusterFS from EPEL-6?

Stephen John Smoogen wrote:
> Well here is the issue. We have been delivering layered products for a
> long time (probably since the beginning) mainly because various groups
> did not want to do an Emerging Technologies for Enterprise Linux.

I thought layered products were based on sustaining engineering and
related support costs?

Or by "we" you mean Fedora EPEL pulls in Enterprise Linux source code
and rebuilds, instead of pulling from more leading-edge Fedora
versions?

And if it is the latter, is that always true? How often do we go
leading edge Fedora version in EPEL, when a Red Hat layered product is
an older version?

> Hey they can use whatever they want. *It is up to entities I have no
> say or control in whether it will be supported by either consultants
> or Red Hat support.

Enterprises who are customers of Red Hat run with all sorts of
software, including IHV, ISV, and even custom or custom-rolled. The
value of Extra Packages of Enterprise Linux (EPEL) is that they sport
the Fedora guidelines and related advantages. It also leads a number
of Red Hat customers to the Fedora project as maintainers too.

Red Hat, IHVs, ISVs and the like are not going to be able to provide
and support everything. It's better if customers and users have a
concentrated point for shared maintainership than for each to do their
own. Again, I will not interpret what EPEL is, but if it is
conflicting with what Red Hat ships, then it loses value for them.

I have a further example and point on this, but I'll leave it for your
last statement.

> The issue is that if EPEL pulls out core packages every time Red Hat
> decides to offer a sub-channel of supported, then there is no need for
> EPEL since it will get gutted regularly. At this point we are looking
> at 1/3->1/2 of EPEL having to be removed because packages require or
> buildrequire items that are included in layered products that would no
> longer be available to build against.

But it's more than that, as you and others have identified. What
versions will go in?

Does EPEL match Red Hat Enterprise Linux layered products?
Or does EPEL stay more leading edge with Fedora as possible?

Or does EPEL just avoid both, and ship what only complements and does
not conflict with what is in Red Hat Enterprise Linux layered
products, as the latter can can be built from source RPMs by
downstream?
And how does Fedora solve more leading edge desires in that case?

Again, what is Extra Packages for Enterprise Linux? I guess that's
what I'm asking.

> Which leads me to my first statement, that the usability of EPEL to a layered
> user is much less than a base OS user.

I really should step back and point out a bigger detail ... and I hope
you'll see my greater point.

We're not talking a few systems or a single site SMB installation.
We're not talking about enterprises directly subscribing their systems
to the EPEL repo.

Imagine a real-world enterprise with 5,000 systems. They have a RHN
Satellite server or some other provisioning, deployment, management,
etc... solution. They have various fractions of those systems using
various, layered entitlements, in the 100s here for something, 10s for
another, and probably the 1s for a select few (Directory, Satellite,
etc... come to mind).

How do I advise a customer regarding EPEL in this situation?

Now factor in the the community advocates in the commercial entity.
They have been recommending they turn one of their useful, management
packages into a Fedora project with a maintainer, telling management
it will be built for RHEL in EPEL and they can deploy it to any and
all systems. They want to share it with other enterprises, via the
Fedora Project, so everyone can benefit.

That's my world. I'm not trying to tell anyone what to do. But
that's just my world. It exists. It's real.

So I just need to know what EPEL is.

-- Bryan

P.S. I've probably said everything at this point. I will let others
debate and decide. I just wanted all considerations interjected, and
I waited until I didn't see those considerations and details
interjected by others.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-24-2012, 06:40 AM
"Karsten 'quaid' Wade"
 
Default Keep or remove GlusterFS from EPEL-6?

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

On 05/23/2012 02:18 PM, Stephen John Smoogen wrote:

> The issue is that if EPEL pulls out core packages every time Red
> Hat decides to offer a sub-channel of supported, then there is no
> need for EPEL since it will get gutted regularly. At this point we
> are looking at 1/3->1/2 of EPEL having to be removed because
> packages require or buildrequire items that are included in
> layered products that would no longer be available to build
> against. Which leads me to my first statement, that the usability
> of EPEL to a layered user is much less than a base OS user.

Sorry if I've missed this answered elsewhere, but why don't the RHEL
layered products use e.g. Puppet from EPEL instead of bundling it?

- - Karsten
- --
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
Red Hat Open Source and Standards (OSAS)
http://TheOpenSourceWay.org
@quaid (identi.ca/twitter/IRC) | gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPvdf42ZIOBq0ODEERApOHAJ9PZqOMHRmJKUB9yqZx9r QTLlw03ACg2ocu
RCRk6DDwTxxwyJ7wE13xNMI=
=OMes
-----END PGP SIGNATURE-----

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-24-2012, 06:54 AM
Mark Chappell
 
Default Keep or remove GlusterFS from EPEL-6?

On 23 May 2012 23:18, Stephen John Smoogen <smooge@gmail.com> wrote:
> The issue is that if EPEL pulls out core packages every time Red Hat
> decides to offer a sub-channel of supported, then there is no need for
> EPEL since it will get gutted regularly.

>From what I recall, we had basically decided to ship rebuilds of the
Red Hat RPMs where EPEL would end up gutted due to RPMs getting pulled
out of the middle of dependency trees where Red Hat were shipping in a
side repository that wouldn't be available to all: for example the
Perl dependency trees that had one or two low level perl libraries
that only appeared in the desktop/client offerings.

I do not think that we should be shipping things like the gluster
core, but, I think ripping out the dependencies as well is simply
going to result in EPEL becoming worthless as Red Hat slowly offers
more Add-On channels and pulls in library based dependencies from the
bottom of EPEL offered dependency trees. Maybe we need to speak to
someone from product management about how Red Hat could make more of
these dependencies available in something like the optional channels,
with minimal support, so that paying customers get the Red Hat RPMs
and the support, and those that don't pay for the additional
entitlements just have access to the libraries.

As someone working heavily with RHEL and Satellite, while we do import
the entirety of EPEL into Satellite we only move the RPMs into a used
channel that we specifically want to use. It's a little extra work
but does also mean that we control our own bake off period. Essential
with 1000s of servers.


Mark

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-24-2012, 06:57 AM
Mark Chappell
 
Default Keep or remove GlusterFS from EPEL-6?

On 24 May 2012 08:40, Karsten 'quaid' Wade <kwade@redhat.com> wrote:
> Sorry if I've missed this answered elsewhere, but why don't the RHEL
> layered products use e.g. Puppet from EPEL instead of bundling it?

Because then Red Hat would end up trying to support packages that it
didn't build or control the release cycles for, which would make QA a
nightmare and bring many extra headaches for the Support teams.


Mark

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-24-2012, 07:00 AM
Alan Pevec
 
Default Keep or remove GlusterFS from EPEL-6?

On Thu, May 24, 2012 at 8:57 AM, Mark Chappell <tremble@tremble.org.uk> wrote:
> On 24 May 2012 08:40, Karsten 'quaid' Wade <kwade@redhat.com> wrote:
>> Sorry if I've missed this answered elsewhere, but why don't the RHEL
>> layered products use e.g. Puppet from EPEL instead of bundling it?
>
> Because then Red Hat would end up trying to support packages that it
> didn't build or control the release cycles for, which would make QA a
> nightmare and bring many extra headaches for the Support teams.

And it's clearly documented in EPEL FAQ
http://fedoraproject.org/wiki/EPEL/FAQ#Is_EPEL_commercially_supported_by_Red_Hat.3F

Cheers,
Alan

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

On Wed, 23 May 2012 17:50:00 -0400
Bryan J Smith <b.j.smith@ieee.org> wrote:

Hey Bryan, I wanted to answer some of your points, but this week has
been very hectic. ;(

...snip...

> Enterprises who are customers of Red Hat run with all sorts of
> software, including IHV, ISV, and even custom or custom-rolled. The
> value of Extra Packages of Enterprise Linux (EPEL) is that they sport
> the Fedora guidelines and related advantages. It also leads a number
> of Red Hat customers to the Fedora project as maintainers too.

Absolutely. Also, it allows folks to share support costs with other
interested parties.

...snip...

> But it's more than that, as you and others have identified. What
> versions will go in?
>
> Does EPEL match Red Hat Enterprise Linux layered products?

Well, that would depend on how the overlap is handled no?

> Or does EPEL stay more leading edge with Fedora as possible?

No. We have always agreed that EPEL was for enterprise use and rapid
incompatible upgrades don't work with that. Fedora also has the
advantge of releases every 6 months, so they can ask people to revisit
incompatible upgrades when they make that jump. RHEL upgrades much less
frequently, so we can't even use that very often to jump to a new
incompatible version.

> Or does EPEL just avoid both, and ship what only complements and does
> not conflict with what is in Red Hat Enterprise Linux layered
> products, as the latter can can be built from source RPMs by
> downstream?

I think the thing people are finding difficult about this is "all
layered products", when many of them seem very niche/special purpose or
not very well known.

> And how does Fedora solve more leading edge desires in that case?

Well, Fedora doesn't need to worry about RHEL, but in general
incompatible upgrades happen at release boundries, which is every 6
months. So, a new thing comes up, you have to wait at most 6 months
(but less if you use rawhide or a branched version of the next
release).

> Again, what is Extra Packages for Enterprise Linux? I guess that's
> what I'm asking.

"Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, Red Hat Enterprise Linux (RHEL),CentOS and Scientific Linux (SL)."
?

...snip...

> Imagine a real-world enterprise with 5,000 systems. They have a RHN
> Satellite server or some other provisioning, deployment, management,
> etc... solution. They have various fractions of those systems using
> various, layered entitlements, in the 100s here for something, 10s for
> another, and probably the 1s for a select few (Directory, Satellite,
> etc... come to mind).
>
> How do I advise a customer regarding EPEL in this situation?

I would say:

On machines you need packages from EPEL:

* If they are general purpose machines that need a number of epel
packages and don't have layered products just enable the epel
repo/channel/whatever.

* If they are specialized machines that do have layered
products/channels, don't enable EPEL. If you need EPEL packages,
include them specifically with 'includepkgs' (or whatever method).

Perhaps it would help to know cases where machines have specific
layered products enabled, but need a bunch of epel packages?
I mean if you have a cloud node, what EPEL packages would be needed
there? Wouldn't you just enable EPEL on the virtual machines _running_
on the cloud ?

> Now factor in the the community advocates in the commercial entity.
> They have been recommending they turn one of their useful, management
> packages into a Fedora project with a maintainer, telling management
> it will be built for RHEL in EPEL and they can deploy it to any and
> all systems. They want to share it with other enterprises, via the
> Fedora Project, so everyone can benefit.
>
> That's my world. I'm not trying to tell anyone what to do. But
> that's just my world. It exists. It's real.

I don't doubt it. Imput from your world is valuable to the
discussion.

kevin
_______________________________________________
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 07:37 AM.

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