|
Roberto Nibali wrote:
> I haven't replied to Joe's posting because I'm still fighting
> whether I should tell you my opinion on this or not.
I thought you were busy in London and I wouldn't hear from you
for a while :-)
> o document and tell the user that certain things have to be done.
fine except users don't read documents. This is reasonable in
a lot of ways. If I'm trying something new, I execute the obvious
commands. If it does something sensible and looks well written,
then I look at the docs to get it to work my way.
> You cannot expect your script to detect everything.
I put the tests in initially because someone came up on the mailing list
because the configure script wouldn't run.
It turns out he hadn't compiled something into the kernel.
I didn't want people coming to me to find out what to do everytime.
The most common question for a while about the configure.pl script
was about the "file not found" error. They didn't have perl installed
or it wasn't in the same location as the script was looking for it.
These sorts of questions drive me nuts. I'll do a lot not to get them.
> If you absolutely
> want to be fool-proof, then do something like
> ip link add dev tun0 || { echo "Sorry, mate, but we need the ipip.o
> support in the kernel."; exit 23; }
Sounds good.
I won't have to keep up with every new format of output from dmesg etc in the
kernel
either
> o Generally fail to execute the configure.pl in the above situation
> and just describe in the end why it failed and what can be done to
> fix the problem.
This was what I was trying to do. However testing for stuff in the kernel, and
then
in modules and then attempting to load the module if I don't find it each time,
winds
up being a lot of code. (Of course all names are different for 2.2. and 2.4)
> The above 3 things are part of a tradeoff you have to take responsability
> for by deciding if configure.pl should reach product status or be a
> very handy and easy-to-debug LVS setup tool.
>
> I just don't like huge deviations in a tool. Keep it simple, stupid
> or document the features. Because if people will not be able to fix
> the problem of a missing ipip module, I don't think they will be
> able to understand the rest of the load balancing stuff.
OK, if a command fails tell them what sort of things to do, rather than
trying to fix it in the script.
> YMMV and it's your code. Just my 3.5 cents,
sure, but there's no point in writing code that no-one will use :-)
Thanks
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
