Does anyone have a clue as to what upstream are likely to be doing w.r.t the sub-release in a release situation ? As in, will there be a 5.0.1 and 5.1.0 ?
On 9/5/07, Karanbir Singh mail-lists@karan.org wrote:
Does anyone have a clue as to what upstream are likely to be doing w.r.t the sub-release in a release situation ? As in, will there be a 5.0.1 and 5.1.0 ?
As far as I understand it.. yes there will be a 5.0.1 and a 5.1.0.
The 5.0.1 release should only be security errata and will be built against the 5.0.0 glibc and libraries.
The 5.1.0 release will be product upgrades and security errata. New security errata for the 5.1.x tree will be built against the 5.1.0 updated glibc/kernel/etc. The API's shouldnt change but I am guessing there might be some ABI issues.
Stephen John Smoogen wrote:
As far as I understand it.. yes there will be a 5.0.1 and a 5.1.0.
not clear if you meant that there are going to be 5.0.1 iso's as well ?
The 5.0.1 release should only be security errata and will be built against the 5.0.0 glibc and libraries.
Thats going to be quite interesting, since it might imply a completely new release. Lets see how it all pans out - if there are any real plans or redhat endorsed docs that someone can point us at, that would be great.
btw, does someone want to have a go at drafting up a policy we could use on the mirror.centos.org network and on external mirrors so as to minimise drivespace usage and still be able to offer the same user experience as upstream ? I know that between Johnny, Lance and I we did do some prep work for this - and a lot of options exist. But it would be good to get some fresh ideas on board and see if we can work something out that works for most people.
On 9/5/07, Karanbir Singh mail-lists@karan.org wrote:
Stephen John Smoogen wrote:
As far as I understand it.. yes there will be a 5.0.1 and a 5.1.0.
not clear if you meant that there are going to be 5.0.1 iso's as well ?
I do not know. I was under the impression that there would not be new isos for 5.0.1 but that could be the ASS U ME of the sales person 3-6 months ago.
The 5.0.1 release should only be security errata and will be built against the 5.0.0 glibc and libraries.
Thats going to be quite interesting, since it might imply a completely new release. Lets see how it all pans out - if there are any real plans or redhat endorsed docs that someone can point us at, that would be great.
I have nothing but what I got from asking questions of the TAM et al a while back. I do not know if all of 5.1 would be rebuilt or just the parts that get technology updates.
btw, does someone want to have a go at drafting up a policy we could use on the mirror.centos.org network and on external mirrors so as to minimise drivespace usage and still be able to offer the same user experience as upstream ? I know that between Johnny, Lance and I we did do some prep work for this - and a lot of options exist. But it would be good to get some fresh ideas on board and see if we can work something out that works for most people.
I was wondering if we should see about stealing the new Dell built one for Fedora?
Stephen John Smoogen wrote:
I was wondering if we should see about stealing the new Dell built one for Fedora?
I dont know what that is :)
On 9/5/07, Karanbir Singh mail-lists@karan.org wrote:
Stephen John Smoogen wrote:
I was wondering if we should see about stealing the new Dell built one for Fedora?
I dont know what that is :)
Matt Domsch wrote a whole set of infrastructure tools for Fedora to push out updates to mirrors. I think it is what causes the fedora-enchilada to show up on various mirrors these days.
http://fedoraproject.org/wiki/Infrastructure/Mirroring
I can see the one downside to the system is:
Fedora Account System
* You must have an account in the Fedora Account System. (More info also at Infrastructure/AccountSystem.) You are not required to sign the Contributors License Agreement to merely mirror Fedora content, but you must do so if you wish to contribute to other aspects of Fedora.
Stephen John Smoogen wrote:
Matt Domsch wrote a whole set of infrastructure tools for Fedora to push out updates to mirrors. I think it is what causes the fedora-enchilada to show up on various mirrors these days.
we dont need anything of this nature, we have something in place that seems to be working mostly. What I meant by mirror management is how the stuff looks when its on the mirror
pushing out each tree, as it is, for upto 3 sub-release deep is just plain stupid. So if anyone has ideas on how we can do this in a sane manner, please do speak up :)
--- Karanbir Singh mail-lists@karan.org wrote:
pushing out each tree, as it is, for upto 3 sub-release deep is just plain stupid.
Well, I definitly can't see how the "3 sub-release deep" (4.5.x and 5.0.x, and so on) can work in the actual tree and procedure updates for the "2 sub-release deep" (4.y.0) will have greater version number than updates for "3 sub-release" so yum will install them
so, _if_ CentOS team want to provide similar package for "premium centos support" users I can only see one solution break the now procedure to "hardlink" directory 4 --> 4.<lastversion> so every "2 sub-release deep" release will have its on repos: os, updates, csgfs, extras (just the same channels that redhat provide, not the one that centos owns by itseft: centosplus, addons, etc) every 4.5, 4.6, 5.0, 5.1 need to be releases by its own just as mayor releases
lots of work and space to maintain, that is one of the reason redhat charge so much ;-)
cu roger
__________________________________________ RedHat Certified ( RHCE ) Cisco Certified ( CCNA & CCDA )
____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
Roger Peña wrote:
Well, I definitly can't see how the "3 sub-release deep" (4.5.x and 5.0.x, and so on) can work in the actual tree and procedure
the sub-releases will be like :
5.0.1 + 5.1.0 being released at the same time, and being the 2 release trees for CentOS-5 till such time as :
5.0.2 + 5.1.1 + 5.2.0 are released at the same time, which are then the 3 sub-releases for CentOS-5 till such time as :
5.0.3 + 5.1.2 + 5.3.0 are released at the same time.
I hope this clears things up. There is no such sub-release plan for CentOS-4 ( that I am aware of )
break the now procedure to "hardlink" directory 4 --> 4.<lastversion>
that raises 2 angles to the same problem.
1) should people be moved along normally, as we do now, by /5/ always pointing at the latest version / newest set of packages - and let users opt-in to staying within a sub-tree, so they would need to manually choose to stay on 5.0.x when 5.1.x is released.
2) We change the behavior completely and have /5/ only stay within the same sub-release, so when 5.1.0 is released, /5/ only points at /5.0.x tree. users would then need to make the manual choice of moving their machines to 5.1.x tree.
Personally, I would like to go with what we have in place, and have /5/ always reflect the latest ( highest number ) release within 5.x.x . This is also less likely to cause orphaned machines when sysadmins dont make a choice at the end of life for a sub-release ( eg. 5.0.3 comes to an end, where do they go then ? since 5.3.0 would have now been released, and the changeset from 5.0.3 to 5.3.0 might be fairly large ). So I am going to vote for (1) above.
On 9/8/07, Karanbir Singh mail-lists@karan.org wrote:
Roger Peña wrote:
Well, I definitly can't see how the "3 sub-release deep" (4.5.x and 5.0.x, and so on) can work in the actual tree and procedure
the sub-releases will be like :
5.0.1 + 5.1.0 being released at the same time, and being the 2 release trees for CentOS-5 till such time as :
5.0.2 + 5.1.1 + 5.2.0 are released at the same time, which are then the 3 sub-releases for CentOS-5 till such time as :
5.0.3 + 5.1.2 + 5.3.0 are released at the same time.
I hope this clears things up. There is no such sub-release plan for CentOS-4 ( that I am aware of )
Actually.. that was in the air when we talked with sales.. the reasoning for calling it 4.6 versus 4U6 was to look at allowing that to happen... however it might be too much work and not enough customers.
break the now procedure to "hardlink" directory 4 --> 4.<lastversion>
that raises 2 angles to the same problem.
- should people be moved along normally, as we do now, by /5/ always pointing
at the latest version / newest set of packages - and let users opt-in to staying within a sub-tree, so they would need to manually choose to stay on 5.0.x when 5.1.x is released.
- We change the behavior completely and have /5/ only stay within the same
sub-release, so when 5.1.0 is released, /5/ only points at /5.0.x tree. users would then need to make the manual choice of moving their machines to 5.1.x tree.
Personally, I would like to go with what we have in place, and have /5/ always reflect the latest ( highest number ) release within 5.x.x . This is also less likely to cause orphaned machines when sysadmins dont make a choice at the end of life for a sub-release ( eg. 5.0.3 comes to an end, where do they go then ? since 5.3.0 would have now been released, and the changeset from 5.0.3 to 5.3.0 might be fairly large ). So I am going to vote for (1) above.
I agree and would like to vote for 1
Karanbir Singh wrote:
Stephen John Smoogen wrote:
Matt Domsch wrote a whole set of infrastructure tools for Fedora to push out updates to mirrors. I think it is what causes the fedora-enchilada to show up on various mirrors these days.
we dont need anything of this nature, we have something in place that seems to be working mostly. What I meant by mirror management is how the stuff looks when its on the mirror
pushing out each tree, as it is, for upto 3 sub-release deep is just plain stupid. So if anyone has ideas on how we can do this in a sane manner, please do speak up :)
mirrormanager though adds a number of features like using preferred netblocks, country mirrors, etc. In addition someone could add his local mirror for private use which, for large corporations may be useful.
I admit I haven't been fooling around much with what CentOS has in place right now though ;-)
Jeroen van Meeuwen wrote:
Karanbir Singh wrote:
we dont need anything of this nature, we have something in place that seems to be working mostly. What I meant by mirror management is how the stuff looks when its on the mirror pushing out each tree, as it is, for upto 3 sub-release deep is just plain stupid. So if anyone has ideas on how we can do this in a sane manner, please do speak up :)
mirrormanager though adds a number of features like using preferred netblocks, country mirrors, etc. In addition someone could add his local mirror for private use which, for large corporations may be useful.
Which still doesn't solve the space problem on mirrors.
Ralph
On Fri, 2007-09-07 at 00:36 +0100, Karanbir Singh wrote:
Stephen John Smoogen wrote:
Matt Domsch wrote a whole set of infrastructure tools for Fedora to push out updates to mirrors. I think it is what causes the fedora-enchilada to show up on various mirrors these days.
we dont need anything of this nature, we have something in place that seems to be working mostly. What I meant by mirror management is how the stuff looks when its on the mirror
pushing out each tree, as it is, for upto 3 sub-release deep is just plain stupid.
Don't pull any punches now. :-)
Seems it could get to more than 3 sub-releases, unless the upstream policy is to limit it to the last 3. Witness 3.9 and 4.5.
So if anyone has ideas on how we can do this in a sane manner, please do speak up :)
Well, how about backing up to the basic assumptions before suggesting solutions. Just because the upstream with their much greater (paid) resources seem to be going to a M.N release scheme, is CentOS constrained to follow precisely in their footsteps? What's wrong with keeping the current scheme of following the latest release and continuing to have M as a pointer to the latest M.N tree? If someone REALLY needs the minor release[es] with associated updates, they can go to the upstream for support; however, I suspect that would be a relatively rare case. If the demand is there down the road, can always re-evaluate the policy.
So, am I sane?
Phil
--- Phil Schaffner Philip.R.Schaffner@NASA.gov wrote:
On Fri, 2007-09-07 at 00:36 +0100, Karanbir Singh wrote:
pushing out each tree, as it is, for upto 3
sub-release deep is just plain
stupid.
Don't pull any punches now. :-)
Seems it could get to more than 3 sub-releases, unless the upstream policy is to limit it to the last 3. Witness 3.9 and 4.5.
So if anyone has ideas on how we can do this in a
sane manner, please do
speak up :)
Well, how about backing up to the basic assumptions before suggesting solutions. Just because the upstream with their much greater (paid) resources seem to be going to a M.N release scheme, is CentOS constrained to follow precisely in their footsteps? What's wrong with keeping the current scheme of following the latest release and continuing to have M as a pointer to the latest M.N tree? If someone REALLY needs the minor release[es] with associated updates, they can go to the upstream for support; however, I suspect that would be a relatively rare case. If the demand is there down the road, can always re-evaluate the policy.
I agree 100%
but _if_ centos team whant to provide same taste as uptream but do not have hardware to support it, I subjest to make a public statement, explaining that (willing to do but lack of hard) maybe CentOS get an storage donation to provide that ;-)
So, am I sane?
I hope you are, because I agree with your criteria ;-)
cu roger
__________________________________________ RedHat Certified ( RHCE ) Cisco Certified ( CCNA & CCDA )
____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
There should not be a great space usage associated with this - you only need to store one copy of each rpm/hdr file. (Unless they actually rebuild everything for 5.1... which seems very unlikely) The only actual 'extra' disk storage space would be cause by storing actual iso cd/dvd images - as mentioned many times before, this can be gotten around with jigdo.
5.0/arch/base - base 5.0 from release time 5.0/arch/updates - updates till 5.1 + security updates to 5.0 past 5.1 release [no automatic upgrade to 5.1 path] 5.1/arch/base - base 5.1 ie. Update 1 from release time 5.1/arch/updates - updates till 5.2 (+ when 5.2 comes out: security updates to 5.1 past the 5.2 release [no automatic update to 5.2 path]
5 - symlink which points to current version (ie. 5.0 currently, soon 5.1, afterwards 5.2).
You want 5.0? You ask for 5.0, You want 5.newest? You ask for '5'.
How do you upgrade from 5.0 to 5.1? Either change the yum repo definitions or do a manual rpm -hiv http:///....///centos-release-5.1.noarch.rpm
[remember all rpms/hdrs are hardlinked to each other were identical within multiple 5.x/arch/base,update directories]
Cheers, Maciej
On 9/7/07, Roger Peña orkcu@yahoo.com wrote:
--- Phil Schaffner Philip.R.Schaffner@NASA.gov wrote:
On Fri, 2007-09-07 at 00:36 +0100, Karanbir Singh wrote:
pushing out each tree, as it is, for upto 3
sub-release deep is just plain
stupid.
Don't pull any punches now. :-)
Seems it could get to more than 3 sub-releases, unless the upstream policy is to limit it to the last 3. Witness 3.9 and 4.5.
So if anyone has ideas on how we can do this in a
sane manner, please do
speak up :)
Well, how about backing up to the basic assumptions before suggesting solutions. Just because the upstream with their much greater (paid) resources seem to be going to a M.N release scheme, is CentOS constrained to follow precisely in their footsteps? What's wrong with keeping the current scheme of following the latest release and continuing to have M as a pointer to the latest M.N tree? If someone REALLY needs the minor release[es] with associated updates, they can go to the upstream for support; however, I suspect that would be a relatively rare case. If the demand is there down the road, can always re-evaluate the policy.
I agree 100%
but _if_ centos team whant to provide same taste as uptream but do not have hardware to support it, I subjest to make a public statement, explaining that (willing to do but lack of hard) maybe CentOS get an storage donation to provide that ;-)
So, am I sane?
I hope you are, because I agree with your criteria ;-)
cu roger
RedHat Certified ( RHCE ) Cisco Certified ( CCNA & CCDA )
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Maciej Z.enczykowski wrote:
There should not be a great space usage associated with this - you only need to store one copy of each rpm/hdr file. (Unless they actually rebuild everything for 5.1... which seems very unlikely) The only actual 'extra' disk storage space would be cause by storing actual iso cd/dvd images - as mentioned many times before, this can be gotten around with jigdo.
5.0/arch/base - base 5.0 from release time 5.0/arch/updates - updates till 5.1 + security updates to 5.0 past 5.1 release [no automatic upgrade to 5.1 path] 5.1/arch/base - base 5.1 ie. Update 1 from release time 5.1/arch/updates - updates till 5.2 (+ when 5.2 comes out: security updates to 5.1 past the 5.2 release [no automatic update to 5.2 path]
5 - symlink which points to current version (ie. 5.0 currently, soon 5.1, afterwards 5.2).
You want 5.0? You ask for 5.0, You want 5.newest? You ask for '5'.
How do you upgrade from 5.0 to 5.1? Either change the yum repo definitions or do a manual rpm -hiv http:///....///centos-release-5.1.noarch.rpm
[remember all rpms/hdrs are hardlinked to each other were identical within multiple 5.x/arch/base,update directories]
We are not talking about 5.1 and 5.2 ... those we do provide and have a process for.
We are talking about (if it happens) a 5.0.1 and a 5.1.0 released simultaneously ... and then later a 5.0.2, 5.1.1, and 5.2 released simultaneously ... and further on a 5.0.3, 5.1.2, 5.2.1, 5.3 ... on and on :D
The problem is that these are ALL different (if they do what they say).
The whole point of the sub numbers is that the 5.0.x (5.0, 5.0.1, 5.0.2, 5.0.3 in my example) are going to be 5.0 with just security updates and things pushed into the 5.0.x tree at that point.
The compiles for the 5.0.x branch would be built via the 5.0 gcc and glibc forever. Meaning that the 5.1 (or 5.2) gcc/glibc would not be used ... so anything new built in 5.1.x (or 5.2.x) and anything new built for 5.0.x are built on different gccs and glibcs and against different repos (the 5.1 stuff will be built against the new 5.1.x repo ... the 5.0 will be built against only the 5.0.x repo, etc.). As there will be different versions of libraries in the different repos, the resulting binaries will be different in some cases.
Now ... I have yet to see anything like this actually done upstream ... and it is currently just something that the sales people are saying will happen. I have not seen anything in RHN implementing this in practice.
So as someone suggested (Phil I think) ... let's just wait and see if it is even done (or if so, in what context it might be done) upstream.
Thanks, Johnny Hughes
On 9/7/07, Roger Peña orkcu@yahoo.com wrote:
--- Phil Schaffner Philip.R.Schaffner@NASA.gov wrote:
On Fri, 2007-09-07 at 00:36 +0100, Karanbir Singh wrote:
pushing out each tree, as it is, for upto 3
sub-release deep is just plain
stupid.
Don't pull any punches now. :-)
Seems it could get to more than 3 sub-releases, unless the upstream policy is to limit it to the last 3. Witness 3.9 and 4.5.
So if anyone has ideas on how we can do this in a
sane manner, please do
speak up :)
Well, how about backing up to the basic assumptions before suggesting solutions. Just because the upstream with their much greater (paid) resources seem to be going to a M.N release scheme, is CentOS constrained to follow precisely in their footsteps? What's wrong with keeping the current scheme of following the latest release and continuing to have M as a pointer to the latest M.N tree? If someone REALLY needs the minor release[es] with associated updates, they can go to the upstream for support; however, I suspect that would be a relatively rare case. If the demand is there down the road, can always re-evaluate the policy.
I agree 100%
but _if_ centos team whant to provide same taste as uptream but do not have hardware to support it, I subjest to make a public statement, explaining that (willing to do but lack of hard) maybe CentOS get an storage donation to provide that ;-)
So, am I sane?
I hope you are, because I agree with your criteria ;-)
cu roger
Phil Schaffner wrote:
Well, how about backing up to the basic assumptions before suggesting solutions. Just because the upstream with their much greater (paid) resources seem to be going to a M.N release scheme, is CentOS constrained to follow precisely in their footsteps?
maybe, or maybe not. the issue here is that if VAR Mr.$X only supports a product on 5.3.1 and CentOS does not provide that, there is a problem. The landscape is littered with people / vendors / support people only recommending people stick within a specific release Update version ( which might be one of the driving forces behind upstreams decision to create this sub-release thing in the first place ).
What's wrong with keeping the current scheme of following the latest release and continuing to have M as a pointer to the latest M.N tree? If someone REALLY needs the minor release[es] with associated updates, they can go to the upstream for support; however, I suspect that would be a relatively rare case. If the demand is there down the road, can always re-evaluate the policy.
ok, so for now - lets assume that we will not be doing the sub-release [1], then what can we do now to make sure that we provision in the ability to make this call at a later stage ?
[1] although, if it happens upstream there will be a lot of people asking for it within CentOS as well, and to be honest - as long as we can, we should.
[ sorry for the late reply, catching up with e-mail after holiday ]
On Sat, 8 Sep 2007, Karanbir Singh wrote:
the issue here is that if VAR Mr.$X only supports a product on 5.3.1 and CentOS does not provide that, there is a problem. The landscape is littered with people / vendors / support people only recommending people stick within a specific release Update version
IMHO, this comes specifically from the fact that upstream doesn't only provide fixes (including security ones) but also functional improvements, such that ISVs fear that future updates can influence the functionality of their products. So upstream has decided to make it clear which updates are considered "safe" and which could potentially bring incompatibilities. F.e. for a scientific program that only does computation and doesn't use any graphical libraries, a security fix for 'kdelibs' coming in 5.0.2 would be sure to not break the program which worked on 5.0.0 and 5.0.1, therefore the ISV could certify the program for the whole 5.0.x series; OTOH, a new kernel coming in 5.1.0 could potentially change some memory map layout (not important for the great majority of software out there) and break the program (which was badly written in the first place, but the customer doesn't know this ;-)), therefore the specific software version would loose its certification for 5.1.x.
So the way I interpret this: there are not going to be n+1 different distributions released at n-th update step (5.0.2, 5.1.1 and 5.2.0 at update step 2, following 5.0.1 and 5.1.0 at update step 1), but n+1 different distributions in total after n-th step (5.0.2 will replace 5.0.1 which replaced 5.0.0, 5.1.1 will replace 5.1.0, 5.2.0 is the new kid on the block). It's a very similar way of thinking now of versions 3 and 4 with updates, but without the potential breakage associated with those updates.
As such, I believe that there's not going to be any need of maintaining a CentOS 5.0.1 forever, but this is going to be replaced by 5.0.2, just as now 3.8 is replaced by 3.9; it's going to be needed however to keep 5.0.x and 5.1.y (and so on) as separate distributions just as now 3 and 4 are kept. But between 5.0.x and 5.1.y there is still a large chance of identical packages (as upstream doesn't like to rebuild packages that work even if, or especially if, the compiler set changes) which should also translate into identical CentOS packages. Those could very well be handled by hard links, just like today. Some packages will certainly drift over time and will therefore require extra space, but I don't believe that it's going to be such an explosive growth as expressed here earlier. And there's going to be needed a 5.0 soft link pointing to the latest 5.0.x release, a 5.1 soft link pointing to the latest 5.1.y release and so on.
The only problem that I can see is the storage of the ISO images; there's very probably going to be a need for storage of the latest 5.0 image, latest 5.1 image, etc. just like now the latest 3 (3.9) and 4 (4.5) images are stored. And, well, those images need to first be created, so there's going to be a need to create n+1 images at update step n. More work for the CentOS devs :-)
Note: The thoughts expressed above come only from interpreting public information; I have no connection to Red Hat.
-
Bogdan Costescu -
Jeroen van Meeuwen -
Johnny Hughes -
Karanbir Singh -
Maciej Żenczykowski -
Phil Schaffner -
Ralph Angenendt -
Roger Peña -
Stephen John Smoogen