| 1 |
On Sat, 2 Aug 2003 19:03:43 +0200 |
| 2 |
"Frido Ferdinand" <frido@××××××.net> wrote: |
| 3 |
|
| 4 |
[snip] |
| 5 |
> 1. Easy deployment (as in redhat kickstart) |
| 6 |
> 2. Easy package management (security updates) |
| 7 |
|
| 8 |
The underlying goals here are what we're looking for, IMHO. But |
| 9 |
thinking in terms of "package management" is too limiting. At |
| 10 |
least, that's the gist of what I get from the infrastructures.org |
| 11 |
stuff. So bump up the level of abstraction a notch or two :) Try |
| 12 |
thinking in terms of their "virtual machine" instead. In many ways, |
| 13 |
the implementation has some overlap with what you describe, but |
| 14 |
there are significant differences as well. |
| 15 |
|
| 16 |
> I intentionally left configuration management out of this because |
| 17 |
> my ideas on the above topics are more refined. To start with the |
| 18 |
> second point, my basic theory is that: Package Management should |
| 19 |
> be left to Portage. This sounds logical on 1 computer, but what if |
| 20 |
> you have a network ? Should portage be made network aware ? I |
| 21 |
> think so. Package management on a network should be as easy as: |
| 22 |
> |
| 23 |
> emerge --target="host.domain.tld" emerge apache |
| 24 |
[snip] |
| 25 |
|
| 26 |
I think we want to follow the gold server concept here, where the |
| 27 |
builds would be done via distcc (controlled by the master gold |
| 28 |
server) and binary packages distributed to specific instances of |
| 29 |
virtual targets, ie, servers with a specified set of virtual |
| 30 |
services, a specific class of desktop machine, etc. |
| 31 |
|
| 32 |
In that scenario, portage would not need to be any more "network |
| 33 |
aware" than it already is. Most of the tools are already there as |
| 34 |
well. The new machine boot/install process would be similar to what |
| 35 |
you describe, except it could be even simpler. See Step 3: |
| 36 |
|
| 37 |
http://www.infrastructures.org/papers/bootstrap/bootstrap.html |
| 38 |
|
| 39 |
The only thing we would need to create besides documentation would |
| 40 |
be a few scripts (maybe integrated with portage, maybe not) and |
| 41 |
perhaps a web interface for selecting a specific machine build. |
| 42 |
|
| 43 |
It seems mostly straight-forward (at least conecptually) with maybe |
| 44 |
the trickiest part being handling the cpu/arch optimizations. I'm |
| 45 |
not a gcc expert, so it would be nice to know somehting about the |
| 46 |
performance differences between the following (say for a machine |
| 47 |
with an Athlon-XP chip in it): |
| 48 |
|
| 49 |
march=athlon-xp |
| 50 |
mcpu=athlon-xp |
| 51 |
mcpu=athlon |
| 52 |
mcpu=i686 |
| 53 |
|
| 54 |
I guess it's basically a trade-off between the complexity of |
| 55 |
managing the configuration and build stuff for a given number of |
| 56 |
machine architectures vs. the performance gains/losses. That seems |
| 57 |
like the biggest question to me. |
| 58 |
|
| 59 |
As soon as my stupid desktop is sufficiently rebuilt, I'll hit the |
| 60 |
wiki... |
| 61 |
|
| 62 |
Steve |
| 63 |
|
| 64 |
PS. Somebody let me know if I'm way off base here, but the more I |
| 65 |
look at the infrastructures.org stuff, the more I think it's a |
| 66 |
perfect fit with Gentoo (and the more I like it). My goals are the |
| 67 |
same as theirs, in terms of reducing TCO, sysadmin effort, etc. Our |
| 68 |
goals here are the same, right? I can't see a better approach right |
| 69 |
now, so let's find out what parts fit our requirements and get |
| 70 |
cracking... |
Archives