[augeas-devel] Re: Augeas and Puppet

Kjetil Torgrim Homme kjetilho at linpro.no
Fri Aug 1 11:21:39 UTC 2008


"Raphaël Pinson" <raphink at gmail.com> writes:
> [Kjetil Torgrim Homme]:
>
>     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.

I don't really want the "holistic" view, I prefer Augeas to work on
individual files.  keeps it simple, and also much faster, since only
the files you're going to edit will be parsed.  consider if I wanted
to edit ~mysql/.bashrc -- should Augeas pull in *all* user's .bashrc
in its tree?  that would not be a pretty sight on a system with LDAP
and NFS :-)

also, I don't want to hardcode the location of configuration files in
the lens -- it can vary from system to system.  some system has this
or that file in /etc/mysql, some other system in /usr/lib/mysql, and a
third system may have multiple independent MySQL-instances.  that's
information which should be in Puppet, not Augeas, IMHO.

> 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.

yeah, I know it's not a complete fit, it was just an example.

> 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 agree this is nicer.  it doesn't identify the file, which I want,
though.  it also is unordered, so be aware -- what node would
"/files/etc/logrotate.d/apache2/rule[2]": action => rm remove ?

> 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 :) ).

sounds reasonable.

> 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.

sure.

> 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

I don't see how the define is used here.

> 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.

perhaps separate editfile and augeas providers would make sense for
this reason, ie. use editfile for standalone edits, and augeas when
you want to pull the entire configuration into the tree.

-- 
Kjetil T.
Linpro AS




More information about the augeas-devel mailing list