Gentoo Archives: gentoo-dev

From: Ron O'Hara <rono@×××××××××××.au>
To: gentoo-dev@g.o
Subject: [gentoo-dev] Large scale deployments - and portage
Date: Sun, 17 Aug 2003 22:09:10
Message-Id: 3F3FFCFF.2080804@sentuny.com.au
1 Hi,
2
3 I may have missed something in all the docs, but as far as I can see
4 there is what should be a fairly simple enhancement to portage that
5 would help considerably in making Gentoo more practical in larger
6 deployments.
7
8 I came to gentoo to get the advantages of being able to tailor my
9 system(s) and still have a simple, consistent upgrade path for all the
10 component software - portage is great for that. From the developer and
11 tinkerer point of view it is hard to see improvements in the overall
12 strategy behind portage.
13
14 BUT - for larger deployments, there are extra needs which are not
15 currently handled by portage - but should be a snap to implement.
16
17 In large deployments, it is critical to maintain strong change control
18 and have predictable environments that you can validate application
19 performance in. Many places use a strategy like: "All production
20 servers are RedHat 7.1 (or Solaris 2.7, or Windows 2000 +SP5 ... etc)"
21
22 At present I cant see a way to easily do that with gentoo. Eg. Gentoo
23 1.4 final is really just a starting point - the minute you do an 'emerge
24 sync', you have an unknown mix of software. And worse, if you do it an
25 hour later on a different machine, it could be a slight different mix
26 again - different from the first box.
27 It is relatively easy to compare the portage trees and work out what the
28 differences are, but thats not much help
29
30 If it were possible to 'tag' the portage tree with labels at regular
31 intervals, and and do an 'emerge sync' with a nominated 'tag' - then you
32 would have the equivelant of the fixed points that other distributions
33 have when they cut a release CD.
34
35
36
37
38 As an example scenario for someone building deployment images in a huge
39 telco.
40
41 After some experimentation, they decide that their basic gentoo system
42 will be 'gentoo with rsync tag gentoo-1.4-Aug-2003'
43
44 They take the first box and do a standard gentoo install, but at the
45 'emerge sync' point in the instructions, they do 'emerge sync
46 tag=gentoo-1.4-Aug-2003'.
47 They then complete all the package installations and tweaking that they
48 want - site specific choices.
49
50
51 This is a repeatable process!! - critical for duplicating an environment.
52
53 As each of the systems is deployed - they are in a known state. Even
54 nicer is that deployed systems can be easily upgraded to some other
55 'known environment' by doing an 'emerge sync tag=xxxx' to some later tag.
56
57 For 'hotfixes', deployed boxes probably need the normal 'emerge sync'
58 which will give them acvcess to the latest and greatest bug fix - but
59 you would probably not do an 'emerge -u world' on these boxes unless
60 moving it from one 'tag level' to another.
61
62 Now the only question is - did I miss something and this already exists?
63
64 Regards
65 Ron O'Hara
66
67
68
69
70
71
72
73
74 .
75
76
77 --
78 gentoo-dev@g.o mailing list

Replies