This knowledge base has moved to the documentation site. Please visit the knowledge base here for the most up to date content. This site is no longer maintained.

Cumulus Linux Modules for DevOps Tools


Cumulus Networks has deprecated the following Puppet and Chef modules we've created:

Cumulus Networks is still taking pull requests and we encourage forks, but Cumulus Networks is no longer maintaining or contributing code to these modules.

Why Have They Been Deprecated?

Because Cumulus Linux is a Debian-based Linux operating system, native Linux modules created by Puppet and Chef for any Linux distribution just work. There is no need for proprietary or vendor-specific modules when using Cumulus Linux, such as the ones Cumulus Networks created.  

The native modules that Puppet and Chef created for Linux already provide idempotency, so you can run the Chef Cookbook and Puppet Manifest repeatedly and get the same result. This means that not only can you configure Cumulus Linux with Puppet and Chef, but you can enforce policy (configuration) state with native Linux modules.  

The native Linux modules are tested and supported by Chef and Puppet, and are already being used by a huge install base worldwide.  

For example, check out our Puppet and Chef demos on GitHub where we use the native modules:

  • Puppet. Specifically, see the file module being used here.
  • Chef. Specifically, see the template module being used here.

Flat File Enhancements for Native Linux Modules

To enable flat file manipulation of the network configuration on Cumulus Linux, Cumulus Networks made two huge enhancements so that these native modules just work.

First, Cumulus Networks implemented the ifreload feature in ifupdown2, the network interface configuration utility. ifupdown2 interacts with the /etc/network/interfaces flat file, which controls all network configuration (VLANs, MTU, IP addressing) except routing. When the /etc/network/interfaces file is edited and overwritten, issuing an ifreload -a or systemctl reload networking.service causes ifupdown2 to apply changes only to the part of the configuration that was modified.

For example, if swp1-10 are currently configured on a switch and configurations for swp11-20 are added to the /etc/network/interfaces file, an ifreload only changes the configuration of swp11-20, and doesn't disrupt the already working network ports.  

The second enhancement relates to the /etc/quagga/Quagga.conf flat file (which will be supplanted by /etc/frr/frr.conf when the Free Range Routing project is integrated into Cumulus Linux 3.4.0). The Quagga/FRR daemon also has the ability to do a smart reload (Quagga reload). A systemctl reload quagga.service can be issued after the /etc/quagga/Quagga.conf file is overwritten.

For example, if swp49-52 were running OSPF and then you overwrote the configuration so that now swp1-10 were also going to run OSPF, the already working swp49-52 are not restarted when you reload the Quagga service. Quagga reload provides the equivalent functionality to ifupdown2's ifreload for the routing configuration (whether static, OSPF, BGP and so forth), providing the ability to make non-disruptive routing changes.

Keep in mind that both systemctl restart quagga.service and systemctl restart networking.service are disruptive and not the equivalent of reloading those services.

Are You Removing the Modules from Your Website?

There are no current plans to remove the existing Chef and Puppet GitHub code, as customers that are already happy with these modules or who have forked any of these projects can continue to contribute and work on them. However, for new customers, Cumulus Networks recommends using native Linux modules whenever possible.


This support portal has moved

Cumulus Networks is now part of the NVIDIA Networking Business Unit! The NVIDIA Cumulus Global Support Services (GSS) team has merged its operations with the NVIDIA Mellanox support services team.

You can access NVIDIA Cumulus support content from the Mellanox support portal.

You open and update new cases on the Mellanox support portal. Any previous cases that have been closed have been migrated to the Mellanox support portal.

Cases that are still open on the Cumulus portal will continue to be managed on the Cumulus portal. Once these cases close, they will be moved to the Mellanox support portal.

Powered by Zendesk