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-16-2012, 09:06 PM
Stephen John Smoogen
 
Default Keep or remove GlusterFS from EPEL-6?

On 16 May 2012 07:53, Bryan J Smith <b.j.smith@ieee.org> wrote:
> 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).


1) We decided about a year ago that if its not a SRPM in the RHEL OS
directory we would not count it as something we could not build
against. This was because we would have needed to remove puppet and
several other tools that various RHEL layered products included at old
releases that we had gone past in version by the time the product was
released.

2) Using any add on repository comes at a price. EPEL can do as much
as it can to lower that price, but at a certain point there are going
to be issues. In such cases I would say that a user has to realize
that certain packages are going to need manual intervention one way or
another. Or they can come up with a way to manage this better. EPEL is
a volunteer effort done in spare time of both Red Hat and non-Red Hat
employees. Our price for using our product is that people step up to
fix things when they are broken.



--
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-17-2012, 12:07 AM
Bryan J Smith
 
Default Keep or remove GlusterFS from EPEL-6?

Kevin Fenzi wrote:
> 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.

Stephen John Smoogen wrote:
> 1) We decided about a year ago that if its not a SRPM in the RHEL OS
> directory we would not count it as something we could not build
> against.

Wait. These two seem to be in conflict, at least to me. Kevin says
one policy (with the possibility of revisiting), then Stephen says
something else was decided last year.

Stephen John Smoogen wrote:
> This was because we would have needed to remove puppet and
> several other tools that various RHEL layered products included at old
> releases that we had gone past in version by the time the product was
> released.

I think Spacewalk/Satellite's inclusion of select packages is a
general issue, at least as long as the Oracle DB is the backend (seems
to be changing with PostgreSQL). But those are just a few support
packages.

Now we're talking an entire entitlement offering.

Stephen John Smoogen wrote:
> 2) Using any add on repository comes at a price. EPEL can do as much
> as it can to lower that price, but at a certain point there are going
> to be issues.

Of course. My only point, based on 100% account experience, is that
we're talking about conflicting with an entire entitlement offering.
All other arguments aside (and can be discussed off-list), this means
that Red Hat customers will have to start to consider not using EPEL
as a result.

That's all I was pointing out. To me, the policy, as Kevin stated it
exists today, makes sense. To do otherwise would be for EPEL to start
marginalizing Red Hat customers. This works in no one's best
interest.

Stephen John Smoogen wrote:
> EPEL is a volunteer effort done in spare time of both Red Hat and non-Red Hat
> employees. Our price for using our product is that people step up to
> fix things when they are broken.

As are all Fedora Project efforts. As I said, I'm continually
thankful for the continued efforts of such maintainers. But I'm also
concerned with what I'm seeing here. I.e., I'd have to start advising
against EPEL for Red Hat customers as a result.

Greg Swift wrote:
> 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.

Whoa!
Are you suggesting EPEL be an "evaluation" for Red Hat add-on entitlements?

If so, what is the purpose of Red Hat evaluations of add-on
entitlements for Red Hat customers?
And for those who are not using Red Hat products, for those using "EL
Rebuilds" for that matter?

Is the purpose of EPEL to be the location where both Red Hat customers
and users of "EL Rebuilds" can go to have an unified, free binary (as
in beer) set version of a Red Hat add-on entitlement?

In fact, some of my initial concerns here (again, 100% thinking of the
Red Hat customers I have been at that use EPEL) has only been further
justified by statements not only like the one above, but other
statements such as ...
"and if we stop, we're taking something away from the community"

I think some are really, really getting off-track here with these
types of statements -- so much so that I don't want to respond further
in public. I only wanted to put forth how this affects Red Hat
customers who use/contribute to EPEL. Understand that's 100% of my
viewpoint, and not anything else.

Greg Swift wrote:
> 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).

And if they mirror EPEL into, say, a RHN Satellite Server channel, how
do they know all of what to filter out from EPEL because it's
conflicting with RHN packages? Especially when the packages are newer
than the RHN ones.

Understand they won't be loading the epel-release package on to their
systems, so they don't have the yum prorities it includes. Now the
customer could go in add them, and setup their channels and related
solutions, clone selectively, etc..., but should they have to deal
with more added management?

Case-in-point ...

I mean, this sounds more and more like EPEL will be something more
difficult to manage at Red Hat customers as if they tapped ... say ...
CentOS Extras for example. Again, I must be really missing something,
because I really thought the guidelines were designed to avoid such,
so EPEL is what it is.

If not, then I'd have to move to change my recommendations on EPEL at
Red Hat customers. It's just my opinion, but I think this changes the
project in a way that benefits no one. Again, I understand the new
entitlement offering is causing this consideration. But that will
always happen, as customer requirements for support and certification
options will in the future too.


--
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, 12:25 AM
Dennis Jacobfeuerborn
 
Default Keep or remove GlusterFS from EPEL-6?

On 05/17/2012 02:07 AM, Bryan J Smith wrote:
> And if they mirror EPEL into, say, a RHN Satellite Server channel, how
> do they know all of what to filter out from EPEL because it's
> conflicting with RHN packages? Especially when the packages are newer
> than the RHN ones.

Is it possible to create an "EPEL-extended" repo? That seem to be the
logical solution. Keep EPEL completely collision free and push packages
like GlusterFS into "EPEL-extended" that users can enable in the repo config.

That way RHEL customers wouldn't have to change a thing and just keep
running basic EPEL but they (and derivative distro users) can opt-in to get
the difficult stuff.

Regards,
Dennis

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

On 16 May 2012 18:07, Bryan J Smith <b.j.smith@ieee.org> wrote:
> Kevin Fenzi wrote:
>> 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.
>
> Stephen John Smoogen wrote:
>> 1) We decided about a year ago that if its not a SRPM in the RHEL OS
>> directory we would not count it as something we could not build
>> against.
>
> Wait. ¬*These two seem to be in conflict, at least to me. ¬*Kevin says
> one policy (with the possibility of revisiting), then Stephen says
> something else was decided last year.

No I think we are talking about the same thing. Just saying it
different ways. If it is not in

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server

then it is ok to be built and shipped. That to me is the RHEL OS
directory. Kevin writes better English than I do. If gluster shows up
in that tree then it will get pulled from EPEL. If it does not show up
in there it does not.

> Stephen John Smoogen wrote:
>> This was because we would have needed to remove puppet and
>> several other tools that various RHEL layered products included at old
>> releases that we had gone past in version by the time the product was
>> released.
>
> I think Spacewalk/Satellite's inclusion of select packages is a
> general issue, at least as long as the Oracle DB is the backend (seems
> to be changing with PostgreSQL). ¬*But those are just a few support
> packages.

I don't believe it was Spacewalk. It was MRG and another product line
that caused us to rethink the issue.

> Now we're talking an entire entitlement offering. ¬*
>
> Stephen John Smoogen wrote:
>> 2) Using any add on repository comes at a price. EPEL can do as much
>> as it can to lower that price, but at a certain point there are going
>> to be issues.
>
> Of course. ¬*My only point, based on 100% account experience, is that
> we're talking about conflicting with an entire entitlement offering.
> All other arguments aside (and can be discussed off-list), this means
> that Red Hat customers will have to start to consider not using EPEL
> as a result.

That was happening before with different entitlements. While I
disagreed originally I have come to agree with DAG's advice. Anyone
who links directly to an outside repository for production systems
needs to really rethink how they do system administration. [Having had
to do this with RHN updates across a cluster made it clear that if you
are going to run something large.. making sure you know what is going
to be put on the systems is always a system administrators job.]

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

On Wed, May 16, 2012 at 8:25 PM, Dennis Jacobfeuerborn
<dennisml@conversis.de> wrote:
> Is it possible to create an "EPEL-extended" repo? That seem to be the
> logical solution. Keep EPEL completely collision free and push packages
> like GlusterFS into "EPEL-extended" that users can enable in the repo config.

You mean like CentOS Extras?

I.e. you're sorta agreeing with me, that's why I made my point (just
's/CentOS Extras/EPEL-extended/g') ...

'Case-in-point ...
I mean, this sounds more and more like EPEL will be something more
difficult to manage at Red Hat customers as if they tapped ... say ...
CentOS Extras for example. Again, I must be really missing something,
because I really thought the guidelines were designed to avoid such,
so EPEL is what it is.'

Just 's/EPEL/EPEL-extended/g' and it fits. Of course, that still come
back to ...

'Is the purpose of EPEL to be the location where both Red Hat customers
and users of "EL Rebuilds" can go to have an unified, free binary (as
in beer) set version of a Red Hat add-on entitlement?'

CentOS with its Extras option addresses this. Scientific Linux has
its options. There are many "EL Rebuilds" that have many options. As
always, my view was 100% from the standpoint of being at Red Hat
customers, and having to deal with this.

On Wed, May 16, 2012 at 8:30 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
> No I think we are talking about the same thing. Just saying it
> different ways. If it is not in
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server
> then it is ok to be built and shipped ...

My sincerest apologies.

> I don't believe it was Spacewalk. It was MRG and another product line
> that caused us to rethink the issue.

Oh, there have been several. Even JBoss EAP throws a curve with EPEL too.

> That was happening before with different entitlements. While I
> disagreed originally I have come to agree with DAG's advice. Anyone
> who links directly to an outside repository for production systems
> needs to really rethink how they do system administration.

And I don't disagree with DAG at all. In fact, I have to preach this
to Red Hat customers regularly too. But EPEL used to be something
that ensured certain guidelines. It's the one repository I didn't
have to worry about X, Y and Z, even if some other conflicts would
arise (unlike DAG, CentOS Extras, etc...).

So in this case, now that we have identified such a case (even though
the change was caused by Red Hat creating an add-on entitlement), it
still doesn't remove the considerations for Red Hat customers, per the
guidelines (at least if I understand them correctly).


--
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, 01:01 AM
Greg Swift
 
Default Keep or remove GlusterFS from EPEL-6?

So I did respond below. But I also went to go reference something in
the guidelines and now I'm confused. This looks to be clearly stated
in the Guidelines and Policy:

http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
c
EPEL packages must never conflict with packages in RHEL Base
(Including Advanced Platform).
EPEL packages can conflict with packages in other RHEL channels. <--------

How does that not specifically address this?

-greg

On Wed, May 16, 2012 at 7:07 PM, Bryan J Smith <b.j.smith@ieee.org> wrote:
> Greg Swift wrote:
>> 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.
>
> Whoa!
> Are you suggesting EPEL be an "evaluation" for Red Hat add-on entitlements?
no. not at all. That being said, its a community project, the
community wanted it in EPEL (obvious from its existence). Many times
a community trying out software can lead to them wanting support for
that software. It was a general statement that Red Hat can benefit,
not that they should specifically pursue the concept for any of their
software.

> If so, what is the purpose of Red Hat evaluations of add-on
> entitlements for Red Hat customers?

1) RH add-on software is sometimes a different version than the
community version
2) Some people have policies against external repository use
3) Its more 'professional' for RH to present their evaluation channel
when talking to people less comfortable with the concept of upstream
being an applicable evaluation (IMO)

> And for those who are not using Red Hat products, for those using "EL
> Rebuilds" for that matter?
>
> Is the purpose of EPEL to be the location where both Red Hat customers
> and users of "EL Rebuilds" can go to have an unified, free binary (as
> in beer) set version of a Red Hat add-on entitlement?

I never said that the Red Hat provided add-on == the EPEL built one
(although in theory they would be very similar). The EPEL provided
build would be the Fedora community provided build. Nothing more than
it ever has been.

> In fact, some of my initial concerns here (again, 100% thinking of the
> Red Hat customers I have been at that use EPEL) has only been further
> justified by statements not only like the one above, but other
> statements such as ...
> *"and if we stop, we're taking something away from the community"
>
> I think some are really, really getting off-track here with these
> types of statements -- so much so that I don't want to respond further
> in public. *I only wanted to put forth how this affects Red Hat
> customers who use/contribute to EPEL. *Understand that's 100% of my
> viewpoint, and not anything else.
I am a RH customer that contributes to EPEL. I also don't use CentOS,
or Scientific or any other redistribution of RH. Just so my viewpoint
is clear as well.

> Greg Swift wrote:
>> 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).
>
> And if they mirror EPEL into, say, a RHN Satellite Server channel, how
> do they know all of what to filter out from EPEL because it's
> conflicting with RHN packages? *Especially when the packages are newer
> than the RHN ones.
>
> Understand they won't be loading the epel-release package on to their
> systems, so they don't have the yum prorities it includes. *Now the
> customer could go in add them, and setup their channels and related
> solutions, clone selectively, etc..., but should they have to deal
> with more added management?

Valid point. But Satellite doesn't complain about software using the
same namespace? I know our Sat admin tells us it does... so that
might be something to consider. See also Steven's point

>
> Case-in-point ...
>
> I mean, this sounds more and more like EPEL will be something more
> difficult to manage at Red Hat customers as if they tapped ... say ...
> CentOS Extras for example. *Again, I must be really missing something,
> because I really thought the guidelines were designed to avoid such,
> so EPEL is what it is.
>
> If not, then I'd have to move to change my recommendations on EPEL at
> Red Hat customers. *It's just my opinion, but I think this changes the
> project in a way that benefits no one. *Again, I understand the new
> entitlement offering is causing this consideration. *But that will
> always happen, as customer requirements for support and certification
> options will in the future too.

Leaning on Steve's response... at some point the system administrators
need to be aware of their system. I know that I'd be aware of this.

I also think that the understanding that the base repository is the
primary conflict point seems to be very valid.

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

So, I'm not going to answer all the (verbose) replies in this thread
point by point.

I looked up what exactly we agreed to for policy last year before
launching EPEL6, and it was:

"EPEL6 will not ship any packages that have src.rpms on public mirrors
under 6* directories with the following exception: If the binary rpm is
only shipped in some arches in RHEL, EPEL may ship a package as close
as possible to the RHEL version with a leading package Release of 0.
(ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly
with the RHEL src.rpm where possible)."

Cite:
http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2011-01-03-20.30.html

So, under this current policy, glusterfs should sadly be removed from
EPEL.

I'll note there's a few other packages in that channel that might also
cause some problems for other projects:

python-greenlet and python-eventlet are used by openstack.
pyxattr is used by rdiff-backup and also duplicity.
hekafs uses glusterfs.

RHUI and DirServ both have a number of conflicting packages too.

I fear we are going to have to collect all the SRPMS and see what the
effects are here. I also note that the SAM channel has a old
puppet/facter version in it.

Would anyone care to create a script to collect all these src.rpms and
compare against epel?

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

On Thu, May 17, 2012 at 4:08 AM, Kevin Fenzi <kevin@scrye.com> wrote:
> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories"

So simple solution is to move RHS SRPMs out of "under 6* directories"

> So, under this current policy, glusterfs should sadly be removed from
> EPEL.

Or RHS could rename their packages to avoid conflicts, like they did
with their patched Swift, RPM was renamed to gluster-swift.

> I'll note there's a few other packages in that channel that might also
> cause some problems for other projects:
>
> python-greenlet and python-eventlet are used by openstack.

Yes, if those go out of EPEL, all of OpenStack RPMs go with them

> pyxattr is used by rdiff-backup and also duplicity.

Also used by openstack-swift and openstack-glance.

Cheers,
Alan

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 10:38 AM
Karanbir Singh
 
Default Keep or remove GlusterFS from EPEL-6?

Hi Guys,

On 05/17/2012 03:08 AM, Kevin Fenzi wrote:
> "EPEL6 will not ship any packages that have src.rpms on public mirrors
> under 6* directories with the following exception: If the binary rpm is
> only shipped in some arches in RHEL, EPEL may ship a package as close
> as possible to the RHEL version with a leading package Release of 0.
> (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly
> with the RHEL src.rpm where possible)."
>
> Cite:
> http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2011-01-03-20.30.html
>
> So, under this current policy, glusterfs should sadly be removed from
> EPEL.
>

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.

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.

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 01:50 PM
David Egts
 
Default 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.

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

_______________________________________________
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 06:38 PM.

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