| 1 |
Martin Hajduch wrote: |
| 2 |
> |
| 3 |
> let me ask you a question - i went through a documentation of GSDS in |
| 4 |
> order to find an answer but haven't succeed |
| 5 |
> |
| 6 |
> does GSDS have any kind of support for binary packages ? if yes, then |
| 7 |
> how does it work ? |
| 8 |
|
| 9 |
I knew this was coming. ;) |
| 10 |
|
| 11 |
Actually, there is no current support for binary installations within |
| 12 |
the GSDS. This is because the initial plan is to get a system that will |
| 13 |
install from stage 1 almost exactly the same as a user entering the |
| 14 |
commands by hand. This is the GSDS's "lowest" form of operation and is |
| 15 |
similar to the "just do it" attitude. |
| 16 |
|
| 17 |
> i will deploy a number of gentoo servers in a near future and my plan |
| 18 |
> (now) is: |
| 19 |
> 1. take 'master' machine - one required for each processor architecture |
| 20 |
> to be supported; install them manually with all needed software |
| 21 |
> 2. tar/gzip / (with some filtering/cleaning beforehand of course) |
| 22 |
> 3. use this tar/gzip instead of an 'official' stage archive |
| 23 |
> 4. manually configure filesystems at the beginning; networking after the |
| 24 |
> install process |
| 25 |
|
| 26 |
My initial feeling is (and I haven't put too much thought into binaries, |
| 27 |
so stay with me on this) that the GSDS will build from source a system |
| 28 |
as per usual. In the installation profile, you will set some kind of |
| 29 |
"generate binaries if they do not exist" flag as well as a "use binaries |
| 30 |
if available flag" and set all machines to deploy in sequence. The |
| 31 |
initial machine will build from source and, in the process, generate |
| 32 |
binary packages of all ebuilds (see 'emerge -k' and the usepkg / |
| 33 |
buildpkg features in portage) along the way. This avoids the overhead of |
| 34 |
building "gold" systems yourself, packages are up to date, compiled for |
| 35 |
your arch with your cflags, and you gain the speed of binaries. Of |
| 36 |
course, adding new machines with the same install profile would use the |
| 37 |
binaries as well. The binaries could be stored on an nfs export from the |
| 38 |
GSDS server or, in a less dynamic environment, burned to a cd and |
| 39 |
dropped into each client being deployed. |
| 40 |
|
| 41 |
(That was 100% off the top of my head and is bound to be flawed, so |
| 42 |
don't take it as gospel.) |
| 43 |
|
| 44 |
> this has to be done binary, because of the speed |
| 45 |
|
| 46 |
Understandable. I'm still in flux about how the defaults actions of the |
| 47 |
GSDS will go. It has a lot to do with what the community wants (it would |
| 48 |
be silly to build something that doesn't work the way most people want |
| 49 |
it) which is why I'm glad these questions came up. |
| 50 |
|
| 51 |
> on the other hand - what else can be automated in this deployment process: |
| 52 |
|
| 53 |
It depends on the similarities between machines and the environment. The |
| 54 |
idea of the GSDS is that it will do a lot of "post flight" work for you |
| 55 |
as well such as installing packages that are not part of the system |
| 56 |
(i.e. postfix, apache, mod_perl, zope, cron of choice, etc.) and use |
| 57 |
something like cfengine to configure them all properly. It should also |
| 58 |
do trivial things like set up the default runlevel, build maintenance |
| 59 |
cron jobs, set up root mail aliases, set up IDS packages, and maybe even |
| 60 |
configure network health and watchdog monitoring clients. |
| 61 |
|
| 62 |
> - pre-config stuff like filesystems, etc ... ? - the disk is already |
| 63 |
> partitioned and will contain some data which has to be kept - doing it |
| 64 |
> manually is no more then 5 minutes per server and less dangerous |
| 65 |
|
| 66 |
This is always touchy. To be honest, I skipped over this stuff initially |
| 67 |
for this exact reason (that and testing it means repeatedly fdisking one |
| 68 |
of my boxes). ;) |
| 69 |
|
| 70 |
The current code picks up at about step 5 in the install handbook until |
| 71 |
we can figure out what people want and how it should work. |
| 72 |
|
| 73 |
> - network config ? - it is server environment with non-trivial |
| 74 |
> networking structure (HA, backup NICs, etc ..) - auto-configuration is |
| 75 |
> not possible |
| 76 |
|
| 77 |
Network configuration should really be automated since the client will |
| 78 |
have to pull packages over the network and do other network related |
| 79 |
tasks. Currently, no, it doesn't do this automagically, but it will. It |
| 80 |
will also handle HA situations like multiple cards, spanning tree and |
| 81 |
trunking configs, and other goodies. How? The magic of cfengine, |
| 82 |
probably. If the client is destined to run dhcp, hey, even better. |
| 83 |
|
| 84 |
The idea is to minimize the work required for mid to large networks, so |
| 85 |
if some post flight sysadmin work is required, so be it. We won't be |
| 86 |
able to handle every conceivable set up out there (but that doesn't mean |
| 87 |
we're not going to plan that way). |
| 88 |
|
| 89 |
> well, if could you find some time, it would be great if you could |
| 90 |
> explain me the basic advantages of GSDS over the above way of |
| 91 |
> deployment; it would be very helpful |
| 92 |
|
| 93 |
Currently, the GSDS is a test case that happens to work. I wouldn't try |
| 94 |
and roll out a 144 machine open mosix cluster with it right now. |
| 95 |
|
| 96 |
You bring up some interesting questions and that's worth all the |
| 97 |
potentia I can dream up on my own. Hopefully, I've given you a better |
| 98 |
idea of where things are going, but I'm *looking* for questions to |
| 99 |
answer and for people to play devil's advocate, so feel free to give a |
| 100 |
shot if I haven't answered your questions here. |
| 101 |
|
| 102 |
Thanks again... |
| 103 |
-- |
| 104 |
Eric Sammer |
| 105 |
eric@××××××××××××.com |
| 106 |
http://www.ineoconcepts.com |
| 107 |
http://store.ineoconcepts.com |
Archives