El Thu, 19-08-2010 a las 22:02 -0600, Daniel Drake escribió:
> > Actually, no cleanup was being done on that particular schoolserver.
> 
> Are you sure?

Yes, and now I know why:

[r...@schoolserver ~]# /usr/bin/ds-cleanup.sh
Traceback (most recent call last):
  File "/usr/bin/ds-cleanup.py", line 42, in <module>
    import syck
ImportError: No module named syck


The package is also missing on our xs 0.6. It's simply a missing
dependency in ds-backup-server, but it broke all schoolservers
worldwide ;-)

After installing syck-python, ds-cleanup.py still doesn't seem to do
anything. I'll figure out why another day, now it's 2am again.


> There's more than that. It's a tool that makes you really think
> through the changes that your making. It helps you centralize
> everything. It also results in a configuration that results in the
> ability to upgrade from any point in time to the latest version. It
> would be less error prone in many ways.

That's true. The problem with this sort of tools is that it's very hard
to diagnose what went wrong.

On a puppetized machine, a rule containing "rpm -i package;
do_something" failed after the first command for some obscure reason.
Then, the first command would also keep failing because the package was
already installed.

This time we could blame it on the incautious rule author who forgot
"--force", but you see what I mean: error paths become complex with
puppet because the flow control is non-linear (like in make) and rule
execution happens asynchronously and in thebackground (even more obscure
than make).


> And if you have a mix of offline and online servers, its a no-brainer.
> The puppet benefits (vs shell script) for connected servers are very
> significant. And if you can just take a few easy steps to share the
> configuration with your offline servers, you save a lot of time.

That is true. OTOH, one could also share a script to be executed off a
USB stick or over the net with Puppet.

As ugly as it may sound, humans would probably find it easier to
maintain linear code that could be debugged interactively from the
command line, independently of an asynchronous client/server system
based on interdependent rules. [takes breath]

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

_______________________________________________
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel

Reply via email to