From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12604 invoked by uid 1002); 17 Aug 2003 22:09:10 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 2289 invoked from network); 17 Aug 2003 22:09:09 -0000 Message-ID: <3F3FFCFF.2080804@sentuny.com.au> Date: Mon, 18 Aug 2003 08:09:03 +1000 From: Ron O'Hara User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@gentoo.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] Large scale deployments - and portage X-Archives-Salt: e71ea588-67ae-43cc-9104-ce3604335f84 X-Archives-Hash: e0cd3d691ff80aae3d74ae4afd9d309d 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