Writing netapi modules

netapi modules, put simply, bind a port and start a service. They are purposefully open-ended and can be used to present a variety of external interfaces to Salt, and even present multiple interfaces at once.


All netapi configuration is done in the Salt master config and takes a form similar to the following:

  port: 8000
  debug: True
  ssl_crt: /etc/pki/tls/certs/localhost.crt
  ssl_key: /etc/pki/tls/certs/localhost.key

The __virtual__ function

Like all module types in Salt, netapi modules go through Salt's loader interface to determine if they should be loaded into memory and then executed.

The __virtual__ function in the module makes this determination and should return False or a string that will serve as the name of the module. If the module raises an ImportError or any other errors, it will not be loaded.

The start function

The start() function will be called for each netapi module that is loaded. This function should contain the server loop that actually starts the service. This is started in a multiprocess.

Multiple instances

New in version 2016.11.0.

rest_cherrypy and rest_tornado support running multiple instances by copying and renaming entire directory of those. To start the copied multiple netapi modules, add configuration blocks for the copied netapi modules in the Salt Master config. The name of each added configuration block must match with the name of each directory of the copied netapi module.

Inline documentation

As with the rest of Salt, it is a best-practice to include liberal inline documentation in the form of a module docstring and docstrings on any classes, methods, and functions in your netapi module.

Loader “magic” methods

The loader makes the __opts__ data structure available to any function in a netapi module.