[augeas-devel] Augeas and Puppet : Can I do a 'augshell / augtool connection pool'?

David Lutterkort lutter at redhat.com
Fri Aug 6 21:12:03 UTC 2010


On Fri, 2010-08-06 at 15:39 -0400, Aaron Lippold wrote:
> One thing I noticed about how the augeas integration works with puppet
> is that upon the execution of the catalog on the system, every time I
> have a module or code bit that using augeas, it loads a new augshell.
> 
> Is there a way that I could keep augshell/augtoo open for the live of
> the puppet catalog execution so I am not paying the cost for augeas
> start / stop.
> 
> I am thinking about this the same way you would for a webapp and the
> database / sql executions and dbh.

I am not sure where puppet is at in terms of maintaining objects for the
lifetime of a catalog run (I know that years ago this was hard, but that
may very well have changed)

Conceptually, even if you have Augeas running during hte whole
transaction, you'd still need to issue an aug_load before executing each
resource, to make sure you don't have stale data in the tree.

The main thing you'd be saving by caching is reparsing the lens
definitions, which is pretty quick anyway. BTW, puppet does not fork an
augtool process, it uses the Ruby bindings into libaugeas.

The big overhead most people incur is that by default, Augeas reads
pretty much any file under the sun, and most of those won't be used in
any given puppet resource. So even though you're only
changing /etc/hosts, Augeas still pulls in dozens of config files.

To avoid that, I added 'lens' and 'incl' parameters to the puppet type a
while ago. If you set these, Augeas will only read a specific file,
avoiding most of the unnecessary overhead. So, you should say something
like

        augeas { add_a_host:
          changes => "...",
          lens => "Hosts.lns",
          incl => "/etc/hosts"
        }
        
in your manifests, and everything will be lightning fast, even without
'connection pooling'.

David





More information about the augeas-devel mailing list