Gentoo Archives: gentoo-dev

From: Ron O'Hara <rono@×××××××××××.au>
Cc: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Large scale deployments - and portage
Date: Mon, 18 Aug 2003 00:34:37
1 Hi Chris
3 Chris Smith wrote:
4 [chop]
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 >
19 >
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.
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)
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!!
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.
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.
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.
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 ( to present it to
68 rsync would be good enough..
72 Thinking out loud::::
74 backward compatibility - current rsync updates would continue unchanged
75 so 'migration' is a non-event.
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.
86 Eg.
88 Assume I have set up a fake host called '' 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.
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.
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 ...
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.
116 end of thinking through my hat!!
118 more ramblings from me.... but still - worth discussing to help bring
119 Gentoo into the corporate realm
123 Regards
124 Ron O'Hara
129 --
130 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Large scale deployments - and portage Paul de Vrieze <pauldv@g.o>