Mark Burgess wrote:
>> It's hard to imagine something that can't be described in perl - or a
>> seasoned sysadmin that doesn't already know how to do it (perhaps badly,
>> but odds are good that 90% of the job can be done with existing CPAN
>> modules...). Suppose you need to work with a process that exposes its
>> status with xml over http (increasingly common around here). Do you
>> have to write your own http and xml handling packages to manage it - or
>> shell out to perl anyway?
>>
>
> Of course you could express anything in Perl, that's not the point.
> The question is could you do everything that cfengine does in a clear way,
> and still be
> able to understand your perl program?
I don't see how that question changes based on the underlying language. I don't
see anything inherently clear in either case.
> Only if you were a full time programmer.
> And that is not a sysadmin's job description.
But one thing perl does very well is to allow the number of programmers
contributing content to scale - which seems to me to be the important part if
you want to avoid re-inventing every wheel and building things from atoms by
yourself. The point of using perl is that I can make an http request, parse
the
returned xml, and write the data to a database of my choice, only having to
write a few lines myself. And I can do that and other equally complicated
things because thousands of different people have written bits of code without
much coordination and the language permits it to all work together. Can a
mostly-uncoordinated set of people write different parts of a cfengine conf
without namespace collisions? Is there a way to track internal version
dependencies among the parts?
> Don't make the mistake of thinking of cfengine as just a scripting language.
> It is an
> automation framework.
Yes, but automating machines isn't particularly interesting or the main part of
what I'd like to accomplish. And seriously, modern systems run nearly
unattended for years these days anyway so that's not the hard job. What I
really want is to facilitate what a team of specialized humans do - and I don't
see how this part can scale unless I'm missing something. This is what I was
trying to ask earlier regarding different people in different roles. How do
the
people who have particular application knowledge provide that code in a way
that
a non-programming operations scheduler can choose when a particular application
version, which might need the corresponding cfengine conf code to manage, goes
to a particular machine?
> And as for "seasoned sysadmins", the more seasoned they think they
> are seasoned, the more they tend to be stuck in bad habits of the past. A
> *great* sysadmin
> is one that is constantly challenging his/her assumptions.
Yes, I'm intrigued at some of the concepts here, but some things aren't
assumptions, they are just facts. And I want the program to work for the
humans, not the other way around.
--
Les Mikesell
[email protected]
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
