1 |
Hi Chris |
2 |
|
3 |
Chris Smith wrote: |
4 |
[chop] |
5 |
|
6 |
>I think the real trick to it, is having a central server for you. There is a |
7 |
>great post on it in the forums somewhere. Having one box for 500 gentoo boxes |
8 |
>downloading all the distfiles, and doing all the rsyncs is a big bandwidth |
9 |
>saver! |
10 |
> |
11 |
> |
12 |
> |
13 |
>>Now the only question is - did I miss something and this already exists? |
14 |
>> |
15 |
>> |
16 |
> |
17 |
>Not really. Here is that forum post if you are interested: |
18 |
>http://forums.gentoo.org/viewtopic.php?t=59134 |
19 |
> |
20 |
|
21 |
Thanks for the link. Ok I've read it and along with you, a few others |
22 |
have explained how they are using their own mirror of files (in one form |
23 |
or other) .. I am already assumming that that is the approach that every |
24 |
large site would setup. |
25 |
My issue is more about version control and change control in a complex |
26 |
large deployment - the bandwidth issue is solved by the local mirror, |
27 |
but versioning is not. |
28 |
|
29 |
I put a lot more about this in a reply to Stuart and Cc'd the list. In |
30 |
essence, big sites want things to operate at a known software level for |
31 |
all components. Gentoo gives brilliant support for deployment and |
32 |
upgrades, but does not directly support locking things down at a |
33 |
'specific release'. The local mirror is just a hack for that aspect (it |
34 |
is still needed for performance reasons) |
35 |
|
36 |
One thing I didn't point out in the earlier mail, is another consequence |
37 |
of change control issues in large deployments. Many huge sites ALWAYS |
38 |
run multiple release levels of all sorts of things, for the simple |
39 |
reason that logistics prevent them ever having all systems running at |
40 |
the same level. Change windows are constrained and there are multiple |
41 |
teams of developers and admins working through changes all the time. |
42 |
Organized hell!! |
43 |
|
44 |
Eg. BT in the Uk deploys a new Cisco router about every 30 minutes... |
45 |
every day of the year!! Thats an operation with SCALE. By definition, |
46 |
their routers are never ALL running the same release of IOS.. they are |
47 |
always managing the operation of multiple versions in production - and |
48 |
multiple migration paths are being tested all the time. - Continuous |
49 |
organized hell!! |
50 |
A similar situation exists for their Solaris deployments - multiple |
51 |
versions in production. |
52 |
|
53 |
You also get the situation where one business application is only |
54 |
certified to run on version x.y.z with patches a+b+c of an operating |
55 |
system, and another (also essential) business application is only |
56 |
certifed to run on some other version with some other set of patches. |
57 |
|
58 |
How do you support that using the current Gentoo? Unfortunately not as |
59 |
easily as you can with a distro like RedHat. But I suspect that if some |
60 |
form of 'tag' or 'label' becomes supported through the portage tree, |
61 |
then Gentoo will in fact offer the equivelant support in this area and |
62 |
have a superior ability in the upgrade/security fix area. |
63 |
|
64 |
|
65 |
As for how this could be done... hmmmm. I suspect putting the portage |
66 |
tree into CVS and then using something like 'cvsfs' |
67 |
(http://www.gnu.org/directory/sysadmin/vc/cvsfs.html) to present it to |
68 |
rsync would be good enough.. |
69 |
|
70 |
|
71 |
|
72 |
Thinking out loud:::: |
73 |
|
74 |
backward compatibility - current rsync updates would continue unchanged |
75 |
so 'migration' is a non-event. |
76 |
|
77 |
New features: If you mirrored the CVS repository to your local miror (I |
78 |
think the cvs client can do that?), then your local mirror can offer |
79 |
different views of the portage tree at any of the labels it holds. |
80 |
Multiple concurrent versions could be presented under different 'host |
81 |
names' for the internal rsync process. |
82 |
In fact you could use that to achieve the same thing for the global |
83 |
situation too. |
84 |
|
85 |
|
86 |
Eg. |
87 |
|
88 |
Assume I have set up a fake host called 'Aug2003.acme.com' as one way |
89 |
to access my local rsync mirror. In this host name, rsyncd runs chrooted |
90 |
to the CVS view of the files against the 'tag' for August-2003. The |
91 |
same can happen for any other 'tag' to allow multiple externally |
92 |
accessible views of the portage tree via rsync against my local mirror. |
93 |
|
94 |
All I need to do for my Aug2003 version gentoo machines is point them at |
95 |
that fake host name. The same goes for other versions. |
96 |
|
97 |
|
98 |
Ok - where is that different to running multiple local mirrors? It's |
99 |
different in one important way (and there is a saving on disk |
100 |
space/bandwidth too). |
101 |
The primary difference is that the 'tags' are publicly defined by the |
102 |
Gentoo project. That means that external vendors can take a 'tag' and QA |
103 |
their software against it. Their customers can then install using the |
104 |
predefined 'tag' and use that vendors software ... |
105 |
|
106 |
Plus if, the gentoo project choses to offer the same type of central |
107 |
repository, then a 'release' also implies the creation of an rsync |
108 |
hostname for accessing that release (and only that release). It also |
109 |
provides a way to remove 'supported' access to that release by removing |
110 |
the hostname -- simple DNS changes. |
111 |
For those companies that take a mirror - there is no need to remove the |
112 |
internal CVS labels so old 'releases' in the portage tree can live for |
113 |
a long time after they are publicly accessible from Gentoo. |
114 |
|
115 |
|
116 |
end of thinking through my hat!! |
117 |
|
118 |
more ramblings from me.... but still - worth discussing to help bring |
119 |
Gentoo into the corporate realm |
120 |
|
121 |
|
122 |
|
123 |
Regards |
124 |
Ron O'Hara |
125 |
http://www.openconsulting.us |
126 |
|
127 |
|
128 |
|
129 |
-- |
130 |
gentoo-dev@g.o mailing list |