Puppet with Solaris RAD

Solaris 11.3 beta ships with a REST-API for the Solaris Remote Administration Daemon (RAD), which makes RAD finally easy to use with Ruby and Puppet. The following is a small experiment to test its capabilities.

Puppet provides a nice abstraction layer of the configuration of a system. A Puppet manifest is usually easier and faster to understand than a documentation with many CLI commands. But there is no magic involved, Puppet usually executes also the same CLI commands in the background. With the debug option you can observe this command executions.

For example, the following manifest enables compression on a ZFS filesystem:

fs-config.pp
1
2
3
zfs { 'rpool/export':
  compression  => 'on',
}

Applying with the debug option reveals which CLI commands are executed in the background:

# puppet apply --debug fs-config.pp
...
Debug: Executing '/usr/sbin/zfs list'
Debug: Executing '/usr/sbin/zfs get -H -o value compression rpool/export'
Debug: Executing '/usr/sbin/zfs set compression=on rpool/export'
Notice: /Stage[main]/Main/Zfs[rpool/export]/compression: compression changed 'off' to 'on'
...

The Puppet provider, the responsible component, executes the commands and parses them. This works fine as long as the output of the commands does not change. As you can imagine it can happen that such a provider executes many, many commands. For example like the default zfs provider.

A full resource listing can be very slow. For example on my test system with 20 filesystems it needs almost a whole minute:

# time puppet resource zfs
...
real    0m56.906s
user    0m25.095s
sys     0m30.804s

Because it executes so many processes in the background. On my system more than 600!

# puppet resource --debug zfs | grep -c Executing
641

With Solaris 11.3 a new RAD module for ZFS is available. I migrated the Puppet zfs provider to the RAD REST-API, basically by replacing all /usr/sbin/zfs executions with API calls. I used a new name for the type: local_zfs.

By using the API, the execution is a lot faster (10x):

# time puppet resource local_zfs
...
real    0m4.796s
user    0m2.794s
sys     0m0.517s

So using RAD is easily faster, but there are more advantages:

  • The API is a stable interface, the output of CLI commands usually not.
  • The Ruby code of a Puppet provider can become easily “ugly”, if the CLI commands are not handy for that job. Using the API allows an increased quality of the Puppet provider.
  • The RAD API also allows remote executions.

Actually this experiment is only the groundwork for a more useful Puppet resource type (remote_zfs), which I will describe in the next blog post.

The source code and further description of local_zfs are available on GitHub: local_zfs

Share Comments