[gentoo-dev] Large scale deployments - and portage

[Ron O'Hara <rono@sentuny.com.au>]

Hi,

I may have missed something in all the docs, but as far as I can see 
there is what should be a fairly simple enhancement to portage that 
would help considerably in making Gentoo more practical in larger 
deployments.

I came to gentoo to get the advantages of being able to tailor my 
system(s) and still have a simple, consistent upgrade path for all the 
component software - portage is great for that. From the developer and 
tinkerer point of view it is hard to see improvements in the overall 
strategy behind portage.

BUT - for larger deployments, there are extra needs which are not 
currently handled by portage - but should be a snap to implement.

In large deployments, it is critical to maintain strong change control 
and have predictable environments that you can validate application 
performance in. Many places use a strategy like:  "All production 
servers are RedHat 7.1 (or Solaris 2.7, or Windows 2000 +SP5 ... etc)" 

At present I cant see a way to easily do that with gentoo. Eg. Gentoo 
1.4 final is really just a starting point - the minute you do an 'emerge 
sync', you have an unknown mix of software. And worse, if you do it an 
hour later on a different machine, it could be a slight different mix 
again - different from the first box.
It is relatively easy to compare the portage trees and work out what the 
differences are, but thats not much help

If it were possible to 'tag' the portage tree with labels at regular 
intervals, and and do an 'emerge sync' with a nominated 'tag' - then you 
would have the equivelant of the fixed points that other distributions 
have when they cut a release CD.




As an example scenario for someone building deployment images in a huge 
telco.

After some experimentation, they decide that their basic gentoo system 
will be 'gentoo with rsync tag gentoo-1.4-Aug-2003'

They take the first box and do a standard gentoo install, but at the 
'emerge sync' point in the instructions, they do 'emerge sync 
tag=gentoo-1.4-Aug-2003'.
They then complete all the package installations and tweaking that they 
want - site specific choices.


This is a repeatable process!! - critical for duplicating an environment.

As each of the systems is deployed - they are in a known state. Even 
nicer is that deployed systems can be easily upgraded to some other 
'known environment' by doing an 'emerge sync tag=xxxx' to some later tag.

For 'hotfixes', deployed boxes probably need the normal 'emerge sync' 
which will give them acvcess to the latest and greatest bug fix - but 
you would probably not do an 'emerge -u world' on these boxes unless 
moving it from one 'tag level' to another.

Now the only question is - did I miss something and this already exists?

Regards
Ron O'Hara








.


--
gentoo-dev@gentoo.org mailing list