[augeas-devel] Re: Augeas and Puppet

Raphaël Pinson raphink at gmail.com
Fri Aug 1 07:39:34 UTC 2008


On Fri, Aug 1, 2008 at 12:17 AM, Kjetil Torgrim Homme <kjetilho at linpro.no>wrote:

> Bryan Kearney <bkearney at redhat.com> writes:
> > I am going to work on getting this into the puppet common modules,
> > but if you are using puppet we have a module [1] which exposes
> > augeas to puppet. It accepts a set of changes as either a single
> > string, or an array of strings. It replaces using regular
> > expressions to edit files, or to put an entire file into puppet as a
> > template.
>
> can you give us an example or two?
>
> it's with Puppet I want to use Augeas, and what I had envisioned is
> something like
>
>   editfile { "/etc/my.cnf":
>      lens => 'generic-ini,
>      set => '/mysqld/query_cache_limit=1048576',
>      rm => '/mysqld/log-slow-queries',
>  }
>


Why specify the lens? I don't think you can force the lens with the augeas
API, and it's not necessary since augeas knows what lens to use on what
file.

Btw, my.cnf is not a standard inifile, since it uses flags. I'm currently
working on it, based on inifile.aug + a flag entry.


I'm personnaly for keeping the xpath syntax in puppet, because otherwise we
lose a lot of functionality from augeas, so I was thinking of something like
:


augeas {

"/files/etc/my.cnf/mysqld/query_cache_limit":
   action => set,
   value  => "1048576",
   notify => Service["mysql"];

"/files/etc/my.cnf/mysqld/log-slow-queries":
   action => rm,
   notify => Service["mysql"];

"/files/etc/logrotate.d/apache2/rule[1]":
   action => mv,
   newnode => "/files/etc/logrotate.d/apache2/rule[2]",
   notify => Service["logrotate"];

}


I believe using an "action" parameter is better than using "set", "insert",
"rm", etc. because using the latter would make you think that you can
perform several actions in one puppet call, which is not possible (or I
don't know how to do it at least :) ).

Calling the object "augeas" makes it clear that it's an an editfile syntax
like in Cfengine, but specifically an augeas syntax, and that this object is
likely to evolve with the augeas API.


When it comes to setting several values with one call, I think it is the
task of specific constructed types in puppet, like :

define mysql::server ( $query_cache_limit="123456", $log-slow-queries, other
parameters...) {

blah blah
package management
blah blah


    augeas {
        "/files/etc/mysql.cnf/query_cache_limit":
           action => set,
           value  => "123456";

        "/files/etc/my.cnf/log-slow-queries":
           action => rm;
    }

}


This type could check for values, and do :
   - set the value if the value is defined
   - rm the value if the value is not defined


Or there could be a keyword to tell the type to delete the value...


editfile { "/etc/ssh/sshd_config":

>      lens => 'sshd,
>      match => '/sshd/AcceptEnv/*',
>      rm => 'match',
>  }



using the xpath format directly in the action would lead to this aswell :

augeas { "/files/etc/ssh/sshd_config/sshd/AcceptEnv/*":
    action => rm;
}


I'm for keeping the full path (including /files) because there might be
interesting things to grab in /augeas aswell (sanity of a file, last created
node - as discussed with David lately, etc.). It would be too bad to
restrict the API in puppet and later one have to work around to access
values that were available from the beginning.

Of course, it forces puppet users that want to use the augeas object to
learn a bit about augeas, but this is not bad. After all, if they plan to
manage their config file with the augeas object, they might very well have
to write an augeas lens for them!


Btw, I'm forwarding this conversation to the puppet-dev group to have more
insight/ideas from other puppet experts.



Raphaël
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20080801/19bfa14b/attachment.htm>


More information about the augeas-devel mailing list