Re: [gentoo-dev] Large scale deployments - and portage

[Brian Jackson <iggy@gentoo.org>]

You could pin packages in the world file (/var/cache/edb/world).

<apache-2
<courier-0.42.3
<mysql-4.0.5

etc. etc. Then copy that file to each server, and tada, you've got a standard 
profile type thing.

--Brian Jackson



On Sunday 17 August 2003 05:09 pm, Ron O'Hara wrote:
> 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

-- 
Home -- http://www.brianandsara.net
Gentoo -- http://gentoo.brianandsara.net

--
gentoo-dev@gentoo.org mailing list