Loading modules with Python

Python is well suited to building a loader system. Despite being classified as a very high-level language (and not a mid-level language like C), Python has a lot of control over how it manages its own internals. The existence of robust module introspection built into Python was very useful for Salt, as it made the arbitrary loading of virtual modules at runtime a very smooth operation.

Each Salt module can support a function called __virtual__(). This is the function that detects whether or not a module will be made available to Salt on that system.

When the salt-minion service loads, it will go through each module, looking for a __virtual__() function. If none is found, then the module is assumed to have all of its requirements already met, and it can be made available. If that function is found, then it will be used to detect whether the requirements for that module are met.

If a module type uses the lazy loader, then modules that can be loaded will be set aside to be loaded when needed. Modules that do not meet the requirements will be discarded.

Detecting grains

On a Minion, the most important things to load are probably the grains. Although grain modules are important (and are discussed in Chapter 3, Extending Salt Configuration), there are in fact a number of core grains that are loaded by Salt itself.

A number of these grains describe the hardware on the system. Others describe the operating system that Salt is running on. Grains such as os and os _family are set, and used later to determine which of the core modules will be loaded.

For example, if the os_family grain is set to redhat, then the execution module located at salt/modules/yumpkg.py will be loaded as the pkg module. If the os_family grain is set to debian, then salt/modules/aptpkg.py will be loaded as the pkg module.

Using other detection methods

Grains aren't the only mechanism used for determining whether a module should be loaded. Salt also ships with a number of utilities that can be used. The salt.utils library contains a number of functions that are often faster than grains, or have more functionality than a simple name=value (also known as a key-value pair) configuration can provide.

One example is the salt.utils.is_windows() function that, as the name implies, reports whether Salt is being run inside of Windows. If Windows is detected, then salt/modules/win_file.py will be loaded as the file module. Otherwise, salt/modules/file.py will be loaded as the file module.

Another very common example is the salt.utils.which() function, which reports whether a necessary shell command is available. For instance, this is used by salt/modules/nginx.py to detect whether the nginx command is available to Salt. If so, then the nginx module will be made available.

There are a number of other examples that we could get into, but there is not nearly enough room in this book for all of them. As it is, the most common ones are best demonstrated by example. Starting with Chapter 2, Writing Execution Modules, we will begin writing Salt modules that make use of the examples that we've already gone over, plus a wealth of others.