hi,
I am guessing most people have looked at the larger-than-DVD install tree's in the shape of the 'base' and 'optional' repos in rhel6-beta.
When it comes to us doing the tree's there are a couple of options, one of which might be to stick with 'base' and 'optional' repositories. But I am fairly sure that Red Hat will productise their tree's into the various varients ( Workstation, Server, Cluster Suite etc ) and drop the 'optional' repo to make things look a lot more like the EL5 tree's.
Since we mix all the tree's into one - that creates the issue we have with 5.5/x86_64/DVD1 and DVD2. Not ideal.
I have a couple of ideas on this, but would like to hear what everyone else thinks is the best way to handle this. Keep in mind that we want to try to ensure that all kickstart / tools / code written for RHEL should justwork on CentOS ( well, as much as is possible ).
- KB
----- Original Message ----- | hi, | | I am guessing most people have looked at the larger-than-DVD install | tree's in the shape of the 'base' and 'optional' repos in rhel6-beta. | | When it comes to us doing the tree's there are a couple of options, | one | of which might be to stick with 'base' and 'optional' repositories. | But | I am fairly sure that Red Hat will productise their tree's into the | various varients ( Workstation, Server, Cluster Suite etc ) and drop | the | 'optional' repo to make things look a lot more like the EL5 tree's. | | Since we mix all the tree's into one - that creates the issue we have | with 5.5/x86_64/DVD1 and DVD2. Not ideal. | | I have a couple of ideas on this, but would like to hear what everyone | else thinks is the best way to handle this. Keep in mind that we want | to | try to ensure that all kickstart / tools / code written for RHEL | should | justwork on CentOS ( well, as much as is possible ). | | - KB | _______________________________________________ | CentOS-devel mailing list | CentOS-devel@centos.org | http://lists.centos.org/mailman/listinfo/centos-devel
I currently loop mount the DVD1 ISO installation media for my kickstarts. These installation servers are separated from the other update servers, so long as all the critical components are on one installation media I'm golden. I rarely, if ever, use the DVD media
I don't like the idea of having to duplicate the contents of the DVD into a "raw" tree if the critical kickstart components are broken across multiple disks.
-- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier@sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca MSN : subatomic_spam@hotmail.com
Does your OS has a man 8 lart? http://www.xinu.nl/unix/humour/asr-manpages/lart.html
----- Original Message ----- | Hi, | | > I don't like the idea of having to duplicate the contents of the DVD | > into a "raw" tree if the critical kickstart components are broken | > across multiple disks. | | What would you do if the contents of the tree were >= 7 GB ? | | - KB | _______________________________________________ | CentOS-devel mailing list | CentOS-devel@centos.org | http://lists.centos.org/mailman/listinfo/centos-devel
Probably expand the volume to support the new content and enable disk deduplication. It's less than ideal but I enjoy and use CentOS enough to provision additional space to support the project on my public mirrors.
-- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier@sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca MSN : subatomic_spam@hotmail.com
Does your OS has a man 8 lart? http://www.xinu.nl/unix/humour/asr-manpages/lart.html
On 10/20/2010 05:55 PM, James A. Peltier wrote:
|> I don't like the idea of having to duplicate the contents of the DVD |> into a "raw" tree if the critical kickstart components are broken |> across multiple disks. | | What would you do if the contents of the tree were>= 7 GB ?
Probably expand the volume to support the new content and enable disk deduplication. It's less than ideal but I enjoy and use CentOS enough to provision additional space to support the project on my public mirrors.
Sure, but you would have more than 1 DVD to contest with.
- KB
On Tue, Oct 19, 2010 at 12:36 PM, Karanbir Singh mail-lists@karan.org wrote:
hi,
I am guessing most people have looked at the larger-than-DVD install tree's in the shape of the 'base' and 'optional' repos in rhel6-beta.
Yep.
Since we mix all the tree's into one - that creates the issue we have with 5.5/x86_64/DVD1 and DVD2. Not ideal.
I have a couple of ideas on this, but would like to hear what everyone else thinks is the best way to handle this. Keep in mind that we want to try to ensure that all kickstart / tools / code written for RHEL should justwork on CentOS ( well, as much as is possible ).
To me, it would be more effective (from a space perspective) to align a little more closely with how RHEL distributes and have a 'core' or 'server' disk, and then a workstation disk. By separating out OpenOffice and a few other apps that should free up enough space to have a single iso that covers what people are looking for. Desktop users aren't really going to need tomcat6, ant, etc. and most server folks won't want openoffice or other similar stuff.
Just my $0.02(USD, $0.03 CND)
On 10/19/2010 08:57 PM, Jim Perrin wrote:
To me, it would be more effective (from a space perspective) to align a little more closely with how RHEL distributes and have a 'core' or 'server' disk, and then a workstation disk. By separating out OpenOffice and a few other apps that should free up enough space to have a single iso that covers what people are looking for. Desktop users aren't really going to need tomcat6, ant, etc. and most server folks won't want openoffice or other similar stuff.
Just my $0.02(USD, $0.03 CND)
I second that option. Not to mention that I do not even remember that last time that I had to install tomcat from the distro, as all web developers I am in touch with insisted on having newer versions. ( No, I do not suggest to leave tomcat out, but I am in favor of not including it in the Workstation disk)
( Jim's 0.0145507457 euro )
Hi,
On 10/20/2010 07:34 AM, Manuel Wolfshant wrote:
To me, it would be more effective (from a space perspective) to align a little more closely with how RHEL distributes and have a 'core' or> I second that option. Not to mention that I do not even remember that
There are two major implications from doing this :
1) we change what is the expected tree / behaviour in CentOS-2.1/3/4/5 - in that there is one rolled in product; and people would have come to expect that.
2) Storage and duplicated rpms across isos's : its not that big a deal in that we can most likely work around the need to have a lot more storage on each mirror / msync machine; but it is a concern.
The big issue is going to be (1), where it could potentially change the game for a lot of people. I am not sure if we really want to go down that route. There is a hybrid option, in that we have a consolidated tree with multiple DVD's for everyone who wants the whole distro; while we also create some more role-specific iso spins and maybe bring back the server isos[1].
- KB
[1]: given that lots of people have asked or it, I have done some work on this and hope to have a 5.5/server.iso for QA in the next few weeks with the hope that we can release something like this with 5.6 as an additional iso.
----- Original Message ----- | Hi, | | On 10/20/2010 07:34 AM, Manuel Wolfshant wrote: | >> To me, it would be more effective (from a space perspective) to | >> align | >> a little more closely with how RHEL distributes and have a 'core' | >> or> I second that option. Not to mention that I do not even | >> remember that | | There are two major implications from doing this : | | 1) we change what is the expected tree / behaviour in CentOS-2.1/3/4/5 | - | in that there is one rolled in product; and people would have come to | expect that.
Is this such a big deal? We're moving to CentOS 6. That's a major change and would but a viable reason to change the tree layout.
| 2) Storage and duplicated rpms across isos's : its not that big a deal | in that we can most likely work around the need to have a lot more | storage on each mirror / msync machine; but it is a concern.
multiple iso files does not equal duplicated RPMs that I can see. The tree would still be unified; no?!?
| The big issue is going to be (1), where it could potentially change | the | game for a lot of people. I am not sure if we really want to go down | that route. There is a hybrid option, in that we have a consolidated | tree with multiple DVD's for everyone who wants the whole distro; | while | we also create some more role-specific iso spins and maybe bring back | the server isos[1].
If the tree is unified, in that there is no difference between a server tree, an advanced server tree and the "default" tree, I'm fine with hosting a couple additional ISO files for each. However, I would hate to see a tree that had file1.rpm located in three different locations in the tree. i.e.
CentOS | |- 6 | |-Server | | | -file1.rpm |-Advanced | | | -file1.rpm
-- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier@sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca MSN : subatomic_spam@hotmail.com
Does your OS has a man 8 lart? http://www.xinu.nl/unix/humour/asr-manpages/lart.html
On 10/20/2010 06:03 PM, James A. Peltier wrote:
| 1) we change what is the expected tree / behaviour in CentOS-2.1/3/4/5 | in that there is one rolled in product; and people would have come to | expect that.
Is this such a big deal? We're moving to CentOS 6. That's a major change and would but a viable reason to change the tree layout.
I still think its a big deal, or can potentially become a big deal. Since this changes quite a lot of context in whats already available ( docs etc ) and what people would expect ( we have always said that we dont have any 'support driven / cost driven' build selections ).
| 2) Storage and duplicated rpms across isos's : its not that big a deal | in that we can most likely work around the need to have a lot more | storage on each mirror / msync machine; but it is a concern.
multiple iso files does not equal duplicated RPMs that I can see. The tree would still be unified; no?!?
Not really. Workstation build would have quite a lot of common ground with Server ( as an example: kernel / glibc / bash ). Also, the tree needs to ( or should ) match the primary install media or one loses out on a lot of potential tooling. eg Spacewalk / cobbler would then need to be aware of how the different tree's dont match up and howto handle those.
- KB
----- Original Message ----- | On 10/20/2010 06:03 PM, James A. Peltier wrote: | > | 1) we change what is the expected tree / behaviour in | > | CentOS-2.1/3/4/5 | > | in that there is one rolled in product; and people would have come | > | to | > | expect that. | > | > Is this such a big deal? We're moving to CentOS 6. That's a major | > change and would but a viable reason to change the tree layout. | | I still think its a big deal, or can potentially become a big deal. | Since this changes quite a lot of context in whats already available ( | docs etc ) and what people would expect ( we have always said that we | dont have any 'support driven / cost driven' build selections ). | | > | 2) Storage and duplicated rpms across isos's : its not that big a | > | deal | > | in that we can most likely work around the need to have a lot more | > | storage on each mirror / msync machine; but it is a concern. | > | > multiple iso files does not equal duplicated RPMs that I can see. | > The tree would still be unified; no?!? | | Not really. Workstation build would have quite a lot of common ground | with Server ( as an example: kernel / glibc / bash ). Also, the tree | needs to ( or should ) match the primary install media or one loses | out | on a lot of potential tooling. eg Spacewalk / cobbler would then need | to | be aware of how the different tree's dont match up and howto handle | those. | | - KB | _______________________________________________ | CentOS-devel mailing list | CentOS-devel@centos.org | http://lists.centos.org/mailman/listinfo/centos-devel
Sorry for my ignorance but I still don't see how this would not be possible with a unified tree. Let's look at the packages alone. Are they in fact different from each other in such a way that it could not be unified. No, I don't think so. If I am using the "advanced" kernel there would likely be a kernel labeled as such linux-XX.YY.ZZ-VER-advanced. So if I used the advanced installation media and ran yum upgrade pointing at the same updates tree would not be an issue. The fact that I chose a particular installation media based on needs is irrelevant. If the version that is installed for advanced is the same as server or workstation there is no duplication or point of contention, I just have additional DVD ISO media.
Keep in mind this is an assumption possibly based on ignorance, but that is how the current tree works. I also employ disk deduplication so it's not so much of an issue for me.
-- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier@sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca MSN : subatomic_spam@hotmail.com
Does your OS has a man 8 lart? http://www.xinu.nl/unix/humour/asr-manpages/lart.html
Hi all.
| On 10/20/2010 06:03 PM, James A. Peltier wrote: | > | 1) we change what is the expected tree / behaviour in | > | CentOS-2.1/3/4/5 | > | in that there is one rolled in product; and people would have come | > | to | > | expect that. | > | > Is this such a big deal? We're moving to CentOS 6. That's a major | > change and would but a viable reason to change the tree layout. | | I still think its a big deal, or can potentially become a big deal. | Since this changes quite a lot of context in whats already available ( | docs etc ) and what people would expect ( we have always said that we | dont have any 'support driven / cost driven' build selections ). | | > | 2) Storage and duplicated rpms across isos's : its not that big a | > | deal | > | in that we can most likely work around the need to have a lot more | > | storage on each mirror / msync machine; but it is a concern. | > | > multiple iso files does not equal duplicated RPMs that I can see. | > The tree would still be unified; no?!? | | Not really. Workstation build would have quite a lot of common ground | with Server ( as an example: kernel / glibc / bash ). Also, the tree | needs to ( or should ) match the primary install media or one loses | out | on a lot of potential tooling. eg Spacewalk / cobbler would then need | to | be aware of how the different tree's dont match up and howto handle | those.
Btw. split media support has been removed from anaconda in rawhide. Not sure if this will also affect rhel 6.
Greets Marcus
On 10/20/2010 5:28 AM, Karanbir Singh wrote:
Hi,
On 10/20/2010 07:34 AM, Manuel Wolfshant wrote:
To me, it would be more effective (from a space perspective) to align a little more closely with how RHEL distributes and have a 'core' or> I second that option. Not to mention that I do not even remember that
There are two major implications from doing this :
- we change what is the expected tree / behaviour in CentOS-2.1/3/4/5 -
in that there is one rolled in product; and people would have come to expect that.
- Storage and duplicated rpms across isos's : its not that big a deal
in that we can most likely work around the need to have a lot more storage on each mirror / msync machine; but it is a concern.
The big issue is going to be (1), where it could potentially change the game for a lot of people. I am not sure if we really want to go down that route. There is a hybrid option, in that we have a consolidated tree with multiple DVD's for everyone who wants the whole distro; while we also create some more role-specific iso spins and maybe bring back the server isos[1].
- KB
[1]: given that lots of people have asked or it, I have done some work on this and hope to have a 5.5/server.iso for QA in the next few weeks with the hope that we can release something like this with 5.6 as an additional iso.
What I've always wanted is a very minimal install iso that will get the machine to a point where yum works. And some moderately large number of pre-selected lists of packages you could tell yum to install either as group names yum knows about or just big lists of package names that someone familiar with them thinks would be suitable for some type of usage (office workstation, development system, media player, web server, etc.), and some tool to grab and maybe edit this list from your minimal (non-GUI) base install.
And of course this should work sensibly if you install many systems behind a caching proxy without any additional setup.
I think this makes sense because it gets you to a point where you can restart and diagnose/fix network problems with the base install, but then pulls current packages instead of loading the usually-outdated install versions that you are forced to update immediately anyway. And the package groupings could be changed over time and perhaps could include things from EPEL or other repos if there is a way for outside people to tweak them.
You'd probably still need some alternative full-install isos, but I'd expect this to be the preferred choice for anyone with a decent internet connection.
On Wed, 20 Oct 2010 13:16:54 -0500 Les Mikesell lesmikesell@gmail.com wrote:
What I've always wanted is a very minimal install iso that will get the machine to a point where yum works. And some moderately large number of pre-selected lists of packages you could tell yum to install either as group names yum knows about or just big lists of package names that someone familiar with them thinks would be suitable for some type of usage (office workstation, development system, media player, web server, etc.), and some tool to grab and maybe edit this list from your minimal (non-GUI) base install.
+1
Alternatively, why not introduce a 8GB image for usb keys? Or a simple method (say, a shell or python script) that would fetch everything from the net and locally put together a bootable usb?
-
James A. Peltier -
Jim Perrin -
Jure Pečar -
Karanbir Singh -
Les Mikesell -
Manuel Wolfshant -
Marcus Moeller