[augeas-devel] Re: Augeas and Puppet

Raphaël Pinson raphink at gmail.com
Fri Aug 1 12:58:09 UTC 2008


On Fri, Aug 1, 2008 at 1:21 PM, Kjetil Torgrim Homme <kjetilho at linpro.no>wrote:

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



I don't know how to do that though. The association lens<=>file is inner to
the lens itself. I don't think it currently possible to force it in the API.
Setting your file as the root in augeas doesn't work (at least in augtool it
doesnt work):

 $ augtool -r /etc/dput.cf
augtool> ls /
augeas/ = (none)


In any case, I think the augeas API would be initialized only once per
puppet call, which means that all known files have to be added to the augeas
tree. Once they are in the tree, it doesn't make it any slower to access the
full tree.


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.



That might be something to improve in augeas, then.



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


Yes, it is unordered in this case, but ordering it is a matter or adding
dependencies, like

before => Augeas["/files/etc/logrotate.d/apache2/rule[1]"]


Actually, this makes me think that it might be better to give an independent
name to the puppet object, in case I want to use a path several times (which
is not possible in puppet if the path is the object name), like :

augeas {
    "set query cache limit":
        path    => "/files/etc/my.cnf/mysqld/query_cache_limit",
        ensure => "present",
        value   => "1048576";

    "remove log slow queries":
        path    => "/files/etc/my.cnf/mysqld/log-slow-queries",
        ensure => absent,
        require => Augeas["set query cache limit"],
        notify   => Service["mysql"];
}



There is another thing to think about also: should there be a save for each
command, or only in the end of the session (which might fail more likely)?



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


It is not here, this was a thing-to-be-implemented kind of comment :)



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

Yes, and also editfiles allows to modify virtually any file in the system
(binary files might be a bit tricky ;)) whereas augeas needs lenses for
that, so I think the distinction has to be clear.



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


More information about the augeas-devel mailing list