| 1 |
Martin Hajduch wrote: |
| 2 |
> hi ! |
| 3 |
> |
| 4 |
> i can imagine automated network configuration when client is supposed to |
| 5 |
> get IP via dhcp |
| 6 |
> i can even imagine automated configuration of basic networking (here can |
| 7 |
> be a problem with multiple network cards and network topology, but |
| 8 |
> cfengine could try interfaces one by one until it gets connected to |
| 9 |
> deployment server, etc ...) |
| 10 |
> but i really can't imagine automated configuration of HA, multiple |
| 11 |
> cards, etc ... you could end up with a separate profile for every server |
| 12 |
> and it could result in too much overhead (well - i can imagine it but |
| 13 |
> ... i will get to this later) |
| 14 |
|
| 15 |
This is true. There are certain things that we'll just have to resolve |
| 16 |
to doing by hand. That said, if you could run a client and come back in |
| 17 |
an hour or two, configure some network info, and be done, that would be |
| 18 |
one or two hours more you can make pretty charts of your new HA systems. |
| 19 |
;) |
| 20 |
|
| 21 |
> such configuration is not on the server level, you have to go higher - |
| 22 |
> you need to have an overview of the network topology, which interface |
| 23 |
> can access which part of the network and what is the purpose of this |
| 24 |
> interface (which services should be running there, etc ...) |
| 25 |
|
| 26 |
That is an interesting idea. I hadn't thought of some kind of profile |
| 27 |
inheritance or component includes... hm... might just work. |
| 28 |
|
| 29 |
> of course, i would be glad to see a software capable of doing it |
| 30 |
> automatically, but unless it can read my thoughts, i doubt that it will |
| 31 |
> be able to configure it as i want ;-) |
| 32 |
|
| 33 |
You don't have a GBIC in the back of your head? That's so 1999... |
| 34 |
|
| 35 |
> i see a big potential in deploying client machines -> they are usually |
| 36 |
> very similar, no complicated networking since everything can be driven |
| 37 |
> from servers (dhcp, cups, proxy config, etc ...) |
| 38 |
> having a possibility of adding fully configured client just by booting |
| 39 |
> it from a special CD would be definitely great for any sysadmin in a |
| 40 |
> company using linux (gentoo) as a desktop platform |
| 41 |
|
| 42 |
Absolutely. This is also a goal, of course. In fact, things like |
| 43 |
computer labs for education or training would benefit from something |
| 44 |
like the GSDS. I would like to generalize it so it's useful to many such |
| 45 |
situations. I have a feeling (and I won't fight it when it happens) |
| 46 |
we're going to have to rename the GSDS as it will no longer apply. If |
| 47 |
that happens, I know we'll be on the right track. |
| 48 |
|
| 49 |
> i'm a little bit skeptic about smaller 'server networks', imagine you |
| 50 |
> have 2-5 web servers, 2 database servers, 2-4 application servers - if |
| 51 |
> you could do this with 3 profiles, it would be good |
| 52 |
> but i'm afraid you can't; you need (i believe) primary/secondary |
| 53 |
> database server profiles; you may have different applications spread |
| 54 |
> over application servers; etc ... (or a clever, sophisticated way of |
| 55 |
> profile building blocks and their combining ...) |
| 56 |
|
| 57 |
In this sort of highly specialized situation, it's still advantageous to |
| 58 |
get the base systems (say, a stage 3) up and running and ready for |
| 59 |
configuration by an SA. Whatever gets people closer to what they need is |
| 60 |
good. |
| 61 |
|
| 62 |
> of course, deploying openmosix cluster with 100 nodes which are more or |
| 63 |
> less identical - i believe that GSDS would do great in such case |
| 64 |
|
| 65 |
Yes. This is the ideal test bed for something like the GSDS. |
| 66 |
|
| 67 |
> at the end of the day, it all depends on how sophisticated your |
| 68 |
> configuration engine will be |
| 69 |
|
| 70 |
Yep. I agree. I imagine certain people (klieber) will continue to |
| 71 |
whisper 'cfengine' and plant the subliminal messages. How it will work, |
| 72 |
well, we haven't really gotten there yet. |
| 73 |
|
| 74 |
> to be somehow constructive, here is an example how it *could* work for |
| 75 |
> smaller 'server networks' - just some brainstorming, don't take it very |
| 76 |
> seriously ;-): |
| 77 |
|
| 78 |
snip |
| 79 |
|
| 80 |
> these were just some thoughts |
| 81 |
|
| 82 |
And good thoughts they were. The configuration engine or process is |
| 83 |
going to be tricky and will 100% *not* work for everyone. Again, if we |
| 84 |
can *help* people get as close as possible, that's great. |
| 85 |
|
| 86 |
> however - last but not least - this is (IMHO) not a deployment software, |
| 87 |
> this is, more or less, kind of auto-configuration framework for |
| 88 |
> services/applications/servers |
| 89 |
|
| 90 |
I'm not attached to names. Buzzwords annoy me. |
| 91 |
As long as we avoid the word "enterprise" I'll be ok. ;) |
| 92 |
|
| 93 |
> of course, the fact that it is automated makes it suitable for use in a |
| 94 |
> deployment process |
| 95 |
|
| 96 |
Indeed. |
| 97 |
|
| 98 |
Thanks again for all your comments and suggestions... |
| 99 |
-- |
| 100 |
Eric Sammer |
| 101 |
eric@××××××××××××.com |
| 102 |
http://www.ineoconcepts.com |
| 103 |
http://store.ineoconcepts.com |
Archives