You need to study more before making a statement like this. It's like saying -- 
when I
lift the hood of my car I don't like seeing that the engine is complex. You 
have no right
to make my engine complex.

I have been trying to encourage people to use a standard set of promise bodies 
and *not*
quote all of the engine parts every time, because that makes everything look 
much more
complicated than it needs to be. But people on this list are often experts and 
they want
to dig around in the engine. That should not put you off using a more sedate 
version of
the vehicle.

You could take the Puppet approach and conceal many details so that you no 
longer actually
control what is going to happen without reprogramming the software at a much 
more
fundamental level.

M

michoski wrote:
> On 2/9/10 10:30 AM, "Andrew J. Millar" <andrew.mil...@net-a-porter.com>
> wrote:
>>> bundle agent test
>>> {
>>>  files:
>>>   "/root"
>>>     create => "true",
>>>     perms => m("700"),
>>>     file_select => folder(".ssh"),
>>>     depth_search => recurse("1");
>>>   
>>>   "/root/.ssh/authorized_keys"
>>>     create => "true",
>>>     perms => m("600");
>>> }
>>>
>>> body file_select folder(regex)
>>> {
>>>  leaf_name  => { ".*$(regex)$"};
>>>  file_result => "leaf_name";
>>> }
>>>
>>> body perms m(mode)
>>> {
>>>  mode => "$(mode)";
>>> }
>>>
>>> body depth_search recurse(d)
>>> {
>>>  depth => "$(d)";
>>> }
>> Indeed - I had just come up with a similar promise which does the trick
>> :-) It seems a little overkill just to get a directory permission right,
>> but it works :-)
> 
> I have to admit the lack of elegance in some solutions bothers me (when I
> read over parts of the above I'm reminded of perl).  This is in no way
> bashing the solution -- it just seems the new language of expression
> requires much and policies lost "readability".  Ironically, this lack of
> what I call "sensible readability", where even a newer admin has some sense
> of what a policy does by reading over it, was one of the original reasons I
> chose cfengine over alternatives.  (I'm sure I just need to go back to CSCE
> for a few years, then I'll feel at home with the new syntax.)
> 
> Even if there is a reason for such complexity, I can't help but question so
> many lines for such a simple task...  As an admin, I tout "KISS" all too
> often.  I tend to balk when I see the opposite.  Admittedly, this is
> probably like new car models...  You always hate them at first, and swear
> you'll never own one...but somehow the bubbly futuristic look eventually
> sucks you in (or your wife, or that overly talkative friend).
> 
> I do hope that the standard library continues to evolve, and of course
> community examples will grow, so we will have more access to "best practice"
> solutions for common problems and less re-inventing the wheel.  I found it
> was the same way when first learning cf2 -- initial frustration over lack of
> examples (the docs got better every year) that's replaced by elation as a
> community full of great content slowly evolves.
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine

-- 
Mark Burgess

-------------------------------------------------
Professor of Network and System Administration
Oslo University College, Norway

Personal Web: http://www.iu.hio.no/~mark
Office Telf : +47 22453272
-------------------------------------------------
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to