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 |