Till Maas

APIs strive to make programmers’ jobs easier by staying stable. Less attention is paid to make the jobs of system administrators easier by providing stable configuration interfaces. These interfaces consist of configuration file formats and various utilities that often change with new major OS releases. Ansible is a great tool for system management, but keeping Ansible playbooks working across major distribution version upgrades can be challenging due to this interface instability. We present Linux System Roles (github.com/linux-system-roles) which allow to manage RHEL, CentOS and Fedora with sufficient abstraction to enable using the same playbooks for different releases and to avoid the need of changing playbooks due to implementation changes. The main difficulty of this approach is getting the interface right to avoid the need of incompatible changes in the future. We will show how to use Linux System Roles with Ansible to configure your Fedora, RHEL or CentOS systems and discuss the challenges that one may encounter when designing such a system or Ansible roles in general.

APIs strive to make programmers’ jobs easier by staying stable. Less attention is paid to make the jobs of system administrators easier by providing stable configuration interfaces. These interfaces consist of configuration file formats and various utilities that often change with new major OS releases. Ansible is a great tool for system management, but keeping Ansible playbooks working across major distribution version upgrades can be challenging due to this interface instability. We present Linux System Roles (github.com/linux-system-roles) which allow to manage RHEL, CentOS and Fedora with sufficient abstraction to enable using the same playbooks for different releases and to avoid the need of changing playbooks due to implementation changes. The roles currently support configuring: - kdump - SELinux - networking - time synchronization - postfix - storage - logging

The main difficulty of this approach is getting the interface right to avoid the need of incompatible changes in the future. We will explain and discuss the choices that we made in the design of the interfaces of our roles. We expect our experience to be generally useful for those who design Ansible roles.

Attendees will gain a practical understanding of how to use Linux System Roles with Ansible to configure their Fedora, RHEL or CentOS systems consistently across multiple releases. The audience is assumed to have a basic understanding of Ansible and experience with Linux (preferably Fedora-derived) system administration.

NMState is a new declarative API that simplifies Linux network management.

Various services built on top of Linux need to manage the network configuration. Each service models network entities differently and uses various APIs to change the network state, multiplying the required work. NMState centralizes the challenges by providing a unified declarative representation of the Linux network state and allowing to modify it using the same schema. NMState also provides Ansible network modules to manage Linux systems, conforming to the same uniform schema used to control network appliances. The talk will introduce NMState, its core capabilities, current users and roadmap, including plans for Kubevirt, oVirt, Openshift and Openstack support. Afterwards, the audience will understand the benefits of using NMState to centralize collaboration on Linux network management.