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 > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 11-19-2011, 08:53 PM
Les Mikesell
 
Default moving the CR repo into mainstream release

On Fri, Nov 18, 2011 at 1:58 PM, Greg Lindahl <greg@blekko.com> wrote:
>> What stability problems would you expect from updates beyond a point
>> release? *The whole point of an 'enterprise' distribution is the
>> effort they make to not break api's across a whole major-rev's life.
>> Would an upstream system break if you selectively update packages
>> beyond a point release without doing a full update?
>
> Upstream has never tested the combination of packages available in CR.
> It's easily possible that package A depends on package B being updated
> to avoid an obscure bug, but the CR only has A's update. Gentoo users
> are quite familiar with this issue.

Version dependencies are supposed to be noted in the rpms and this
isn't gentoo - the apis aren't generally supposed to be changing at
all or you couldn't expect your own and 3rd party applications to
continue to run.

> It is likely that many CentOS users think they aren't bothered by
> these issues, but CentOS is used in a lot of production environments,
> and I bet there will be some surprises.

I've fairly routinely updated individual packages only across minor
rev changes or held some back without problems. Your argument would
be more convincing if you had several examples of update combinations
not prevented by package dependencies that will break something.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-20-2011, 03:53 AM
Greg Lindahl
 
Default moving the CR repo into mainstream release

On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote:
> On 11/18/2011 07:58 PM, Greg Lindahl wrote:
> > Upstream has never tested the combination of packages available in CR.
>
> if you look at the rhn experience for most people - its actually quite
> in line with the CR/ process - as if it were just one release moving
> along with point-in-time install media being made available. Otoh, its
> been a long time since i did anything with rhn, have things changed ?

Well, my experience (and I think this is fairly typical) is that I
install all the updates soon after they arrive. So there's no way I
could end up with a 6.0+6.0updates with a single 6.1 package, which is
what CR is intended to do.

During the 5.X series, there was one time that I downgraded a package,
expat, due to a bug that took Upstream a long time to fix. One.

> Also, keep in mind that people can opt out of the process and lock their
> machines into a point release ( eg. lock into 6.1, and only move to 6.2
> when they want to ).

Yes, of course, that's what I plan on doing.

Les Mikesell brings up the reasonable question of whether version
dependencies might save the day. They probably will in most cases, but
with both Gentoo and Debian, I have discovered enough errors in those
dependencies that I don't expect Upstream to get this right,
especially when almost all of their users aren't going to try to
install a single 6.1 package on 6.0. I doubt I'll convice Les with
this argument, but there you have it. As an Enterprise user, I'm not
interested in experimenting with having most CentOS users do something
that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)

-- greg


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-20-2011, 01:38 PM
Johnny Hughes
 
Default moving the CR repo into mainstream release

On 11/19/2011 10:53 PM, Greg Lindahl wrote:
> On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote:
>> On 11/18/2011 07:58 PM, Greg Lindahl wrote:
>>> Upstream has never tested the combination of packages available in CR.
>>
>> if you look at the rhn experience for most people - its actually quite
>> in line with the CR/ process - as if it were just one release moving
>> along with point-in-time install media being made available. Otoh, its
>> been a long time since i did anything with rhn, have things changed ?
>
> Well, my experience (and I think this is fairly typical) is that I
> install all the updates soon after they arrive. So there's no way I
> could end up with a 6.0+6.0updates with a single 6.1 package, which is
> what CR is intended to do.
>

Not sure where you got that. CR is intended to add many packages and
distribute them more evenly throughout the point release creation
process in a stage way.

Where the media set is not yet done for the future point release, but
all the RPMs are in CR.

It allows us to prioritize building (get enough "dependencies" done and
get the security updates out in the first batch and release them to CR
... then build all the other RPMs in the point release.

We can also build the updates for the next point release (some of the
zero day ... also many Firefox, etc. come out) while we are still
putting together the final point release media set.

It seems to me that you are arguing for a process that puts out staged
sets of updates and then saying CR is bad (which is how we can do staged
updates).

> During the 5.X series, there was one time that I downgraded a package,
> expat, due to a bug that took Upstream a long time to fix. One.
>
>> Also, keep in mind that people can opt out of the process and lock their
>> machines into a point release ( eg. lock into 6.1, and only move to 6.2
>> when they want to ).
>
> Yes, of course, that's what I plan on doing.
>
> Les Mikesell brings up the reasonable question of whether version
> dependencies might save the day. They probably will in most cases, but
> with both Gentoo and Debian, I have discovered enough errors in those
> dependencies that I don't expect Upstream to get this right,
> especially when almost all of their users aren't going to try to
> install a single 6.1 package on 6.0. I doubt I'll convice Les with
> this argument, but there you have it. As an Enterprise user, I'm not
> interested in experimenting with having most CentOS users do something
> that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)

Again ... not sure what you think CR is.

CR is basically dumping all updates as we get them built and working
into a repo that people can install in real time, instead of waiting a
month (oe more) for every single update to complete before we release
anything (our current practice). I am really failing to see how that is
what you are talking about at all ... maybe I am lost.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-20-2011, 08:32 PM
Greg Lindahl
 
Default moving the CR repo into mainstream release

On Sun, Nov 20, 2011 at 08:38:18AM -0600, Johnny Hughes wrote:

> Again ... not sure what you think CR is.
>
> CR is basically dumping all updates as we get them built and working
> into a repo that people can install in real time, instead of waiting a
> month (oe more) for every single update to complete before we release
> anything (our current practice). I am really failing to see how that is
> what you are talking about at all ... maybe I am lost.

That's exactly what I'm talking about. Sorry that I wasn't clear. Let
me try again with an example:

Let's say that "foo" is one of the many packages updated in 6.1.

With CR, let's say that "foo" happens to be the first 6.1 package
added to 6.0-CR.

When I install "foo" from 6.0-CR, I am now running a combination of
6.0 + a single 6.1 rpm. This combination has probably never been
tested by upstream; almost all of the upstream people installed almost
all of the new 6.1 rpms together.

I'm here posting about this issue because I'm responding to this
question:

> What stability problems would you expect from updates beyond a point
> release? The whole point of an 'enterprise' distribution is the
> effort they make to not break api's across a whole major-rev's life.
> Would an upstream system break if you selectively update packages
> beyond a point release without doing a full update?

The fact that upstream hasn't tested these rpm combinations means that
there's risk involved.

-- greg


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-20-2011, 11:27 PM
Les Mikesell
 
Default moving the CR repo into mainstream release

On Sun, Nov 20, 2011 at 3:32 PM, Greg Lindahl <greg@blekko.com> wrote:
>
> I'm here posting about this issue because I'm responding to this
> question:
>
>> What stability problems would you expect from updates beyond a point
>> release? *The whole point of an 'enterprise' distribution is the
>> effort they make to not break api's across a whole major-rev's life.
>> Would an upstream system break if you selectively update packages
>> beyond a point release without doing a full update?
>
> The fact that upstream hasn't tested these rpm combinations means that
> there's risk involved.
>

Updates can't be tested against your local applications either - which
is what you'd care most about. But the risk of breakage is small
because upstream doesn't make changes that break API's as a matter of
policy across major revisions - which is the whole point of
'enterprise' versions. If you don't change an API, you don't need to
re-test against everything that uses it.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-21-2011, 12:10 AM
Greg Lindahl
 
Default moving the CR repo into mainstream release

On Sun, Nov 20, 2011 at 06:27:46PM -0600, Les Mikesell wrote:

> > The fact that upstream hasn't tested these rpm combinations means that
> > there's risk involved.
>
> Updates can't be tested against your local applications either - which
> is what you'd care most about.

Well, if you recall what I wrote previously in the thread, I said that
I tested my local applications carefully against point releases, and
not that much against intermediate updates, which tend to be much
smaller and less risky than the changes in the point releases.

With CR, I'd have to do a lot more testing.

> If you don't change an API, you don't need to
> re-test against everything that uses it.

You saw my previous comments about how upstream _does_ change APIs,
but seemingly only in point releases? For example, the InfiniBand
stuff changed dramatically through the 5.X releases. Each time they'd
backport a bunch of stuff into the kernel, and release matching
userspace rpms.

Sorry to be repeating myself so much, but I think the point about when
upstream makes bigger changes (point releases) is important for
everyone to understand.

-- greg

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-21-2011, 12:42 AM
Johnny Hughes
 
Default moving the CR repo into mainstream release

On 11/20/2011 03:32 PM, Greg Lindahl wrote:
> On Sun, Nov 20, 2011 at 08:38:18AM -0600, Johnny Hughes wrote:
>
>> Again ... not sure what you think CR is.
>>
>> CR is basically dumping all updates as we get them built and working
>> into a repo that people can install in real time, instead of waiting a
>> month (oe more) for every single update to complete before we release
>> anything (our current practice). I am really failing to see how that is
>> what you are talking about at all ... maybe I am lost.
>
> That's exactly what I'm talking about. Sorry that I wasn't clear. Let
> me try again with an example:
>
> Let's say that "foo" is one of the many packages updated in 6.1.
>
> With CR, let's say that "foo" happens to be the first 6.1 package
> added to 6.0-CR.
>
> When I install "foo" from 6.0-CR, I am now running a combination of
> 6.0 + a single 6.1 rpm. This combination has probably never been
> tested by upstream; almost all of the upstream people installed almost
> all of the new 6.1 rpms together.
>

But, any combination of the released package set should work together
(within the requires in the RPMs of course).

People update only a subset of packages all the time, mostly because of
custom software that they have done themselves.

But I think I actually agree with one point you are making. I truly
believe the CR should be exactly as it is now ... optional. If you want
to use it, you can easily issue the command:

yum install centos-release-cr

And if you want to do it only as a released version (no CR), then that
is OK too and it should be (IMHO) the default.

> I'm here posting about this issue because I'm responding to this
> question:
>
>> What stability problems would you expect from updates beyond a point
>> release? The whole point of an 'enterprise' distribution is the
>> effort they make to not break api's across a whole major-rev's life.
>> Would an upstream system break if you selectively update packages
>> beyond a point release without doing a full update?
>
> The fact that upstream hasn't tested these rpm combinations means that
> there's risk involved.

You are correct that some ABIs do change ... BUT ... in that case they
will include that in the RPM by something like "xulrunner > X.Y.Z", then
you can only install FOO if you meet the requirements. You absolutely
should be able to install any installable combination that is not hard
coded with a version in the requirements. If you can't then the RPM
requirements are not properly programmed and it is a bug.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-21-2011, 10:43 PM
Tom Sorensen
 
Default moving the CR repo into mainstream release

On Sun, Nov 20, 2011 at 4:32 PM, Greg Lindahl <greg@blekko.com> wrote:
> When I install "foo" from 6.0-CR, I am now running a combination of
> 6.0 + a single 6.1 rpm. This combination has probably never been
> tested by upstream; almost all of the upstream people installed almost
> all of the new 6.1 rpms together.
>
> I'm here posting about this issue because I'm responding to this
> question:
>
>> What stability problems would you expect from updates beyond a point
>> release? *The whole point of an 'enterprise' distribution is the
>> effort they make to not break api's across a whole major-rev's life.
>> Would an upstream system break if you selectively update packages
>> beyond a point release without doing a full update?
>
> The fact that upstream hasn't tested these rpm combinations means that
> there's risk involved.

FSVO risk, sure. Except that upstream recommends this all the time
when troubleshooting customer systesms.

We have several systems deployed at customer sites that are RHEL
5.3... with the 5.6 glibc. And this was recommended by 3rd level
support, not some 1st level person following a script.

Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on
an isolated network scattered all over the globe physically, so doing
that isn't very easy. And upstream understands this, as well as the
desire from some customers to not change from a particular sub-version
without cause. They may not have explicitly tested various package
combinations, but the commitment to a stable API/ABI means that mixing
packages from within the same major version number is safe with a
small number of exceptions (which are in the tech notes).

IOW, the risk is exceptionally small.

Tom Sorensen
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-21-2011, 10:50 PM
Stephen Walsh
 
Default moving the CR repo into mainstream release

On 11/22/2011 10:43 AM, Tom Sorensen wrote:
> FSVO risk, sure. Except that upstream recommends this all the time
> when troubleshooting customer systesms.
>
> We have several systems deployed at customer sites that are RHEL
> 5.3... with the 5.6 glibc. And this was recommended by 3rd level
> support, not some 1st level person following a script.
>
> Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on
> an isolated network scattered all over the globe physically, so doing
> that isn't very easy. And upstream understands this, as well as the
> desire from some customers to not change from a particular sub-version
> without cause. They may not have explicitly tested various package
> combinations, but the commitment to a stable API/ABI means that mixing
> packages from within the same major version number is safe with a
> small number of exceptions (which are in the tech notes).
>
> IOW, the risk is exceptionally small.

With a nice support contract and an army of willing RH engineers on the
other end of a phone, yes, the risk is small.

For $Johnny_webhost, who takes his daily income from his business, and
can't afford the above mentioned support on his rack full of EL boxes
(which is why he uses centos), he needs to balance the risk of losing
customers due a security incident vs running a full up to date and
stable system with a mix of current and upcoming release packages, and
all with the knowledge in his head and what he can get from the main
centos list (most of which last time I looked appeared to be a
conversation about why you should use ubuntu over centos).

The Lowest Common Denominator is the one we need to think about here.
The end user that wants EL stability and security, but can't afford to
spend the money on upstream subscriptions.




_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-21-2011, 11:05 PM
Les Mikesell
 
Default moving the CR repo into mainstream release

On Mon, Nov 21, 2011 at 5:50 PM, Stephen Walsh <steve@nerdvana.org.au> wrote:
> *On 11/22/2011 10:43 AM, Tom Sorensen wrote:
>> FSVO risk, sure. Except that upstream recommends this all the time
>> when troubleshooting customer systesms.
>
>
>> IOW, the risk is exceptionally small.
>
> With a nice support contract and an army of willing RH engineers on the
> other end of a phone, yes, the risk is small.

And you are running the same code...

> For $Johnny_webhost, who takes his daily income from his business, and
> can't afford the above mentioned support on his rack full of EL boxes
> (which is why he uses centos), he needs to balance the risk of losing
> customers due a security incident vs running a full up to date and
> stable system with a mix of current and upcoming release packages, and
> all with the knowledge in his head and what he can get from the main
> centos list (most of which last time I looked appeared to be a
> conversation about why you should use ubuntu over centos).
>
> The Lowest Common Denominator is the one we need to think about here.
> The end user that wants EL stability and security, but can't afford to
> spend the money on upstream subscriptions.

The question is whether this person would be better off getting
security updates that were built post-minor-rev-update or not in a
default 'yum update'. It's a yes or no question, where recommending
doing one thing and making the default something else doesn't make a
lot of sense. With/without the CR approach, the non-security related
updates are going to come along for the ride, and you will probably
want them anyway.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 12:28 PM.

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