Ideas virt_net

Everything started with issues with the virt_net modules:

This page collects ideas for dicussion to find the right way of a fix / improvement.

Contents

General paradigm
Operational scenarios and usage examples
Related work
Issues with the current implementation and further design aspects

General paradigm

From Ansible use case configuration management:

Ansible features an state-driven resource model that describes the desired state of computer systems and services, not the paths to get them to this state. No matter what state a system is in, Ansible understands how to transform it to the desired state (and also supports a "dry run" mode to preview needed changes). This allows reliable and repeatable IT infrastructure configuration, avoiding the potential failures from scripting and script-based solutions that describe explicit and often irreversible actions rather than the end goal."

Good example from https://hvops.com/articles/ansible-vs-shell-scripts (with slight wording improvements):

---
- hosts: all
  tasks:

  - name: Ensure the PGP key is installed
    apt_key: >
      state=present
      id=AC40B2F7
      url="http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0x561F9B9CAC40B2F7"

  - name: Ensure https support for apt is installed
    apt: >
      state=present
      pkg=apt-transport-https

  - name: Ensure the passenger apt repository is configured
    apt_repository: >
      state=present
      repo='deb https://oss-binaries.phusionpassenger.com/apt/passenger raring main'

  - name: Ensure nginx is installed
    apt: >
      state=present
      pkg=nginx-full

  - name: Ensure passenger is installed
    apt: >
      state=present
      pkg=passenger
      update_cache=yes

  - name: Ensure the nginx configuration is correct
    copy: >
      src=/app/config/nginx.conf
      dest=/etc/nginx/nginx.conf

  - name: Ensure nginx is running
    service: >
      name=nginx
      state=started

Some critical / skeptical words: https://regebro.wordpress.com/2014/09/17/a-script-is-not-configuration

Operational scenarios and usage examples

This section focuses on the user context, when using virt_net. The purpose is to understand the workflow of the user. It is insufficient to just look at libvirt network features.

Developer using a virtual machine for testing on her own machine

An Ansible developer wants to run a virtual machine as staging environment for her Ansible configuration. Could be a network of several virtual machines. Mainly, I assume the virtual machine runs on the local host in the user space.

Basic steps:

Boot up a fresh virtual machine from a fresh image
Bootstrap Ansible playbook
Test everything
Clean up in the end

As part of the first step, we must ensure the virtual staging network is set up as needed.

Example: Adapt the default network

---
- name: Ensure the test environment is set up correctly
  hosts: localhost
  tasks:
    - name: Ensure the default network defined correctly and running
      community.libvirt.virt_net:
        xml: '{{ lookup("template", "network_default.xml") }}'
        persistent: yes
        active: yes

I do not define parameters here, which are already part of the XML template. Especially I avoided the parameter name in the example to see how it feels. The combination of name and xml has issues in the current implementation (see parameter name). However, the default network already exists. The user needs not specify an XML definition, if she is happy with the default definition of libvirt. In this case, she needs a parameter name.

---
- name: Ensure the test environment is set up correctly
  hosts: localhost
  tasks:
    - name: Ensure the default network is running
      community.libvirt.virt_net:
        name: default
        active: yes

Example: Additional network

This network can be non-persistent

---
- name: Ensure the test environment is set up correctly
  hosts: localhost
  tasks:
    - name: Ensure the network *development* is defined correctly and running
      community.libvirt.virt_net:
        xml: '{{ lookup("template", "network_development.xml") }}'
        persistent: no
        active: yes

After running the tests, the developer could clean up the development environment.

---
- name: Ensure a cleaned up development environment
  hosts: localhost
  tasks:
    - name: Ensure the network *development* is removed
      community.libvirt.virt_net:
        name: development
        persistent: no
        active: no

Having the parameter name sometimes in and out makes it a bit difficult, to bring the corresponding definitions together, if there are several network definitions.

Testing virtual machines in a CI environment

Testing systems in a continuous integration environment is basically the next step after the previous use case. The CI system might select the right test machine bootstrap the virtual machine, run test case and clean up everything in the end. Ansible can help to create the virtual machine as well as to deploy the current software in the virtual machine. Note: I think libvirt might be good for small setups. For bigger setups we have usual other suspects like OKD, OpenStack etc.

The Ansible playbook is very similar to the previous use case: non-persistent setup (everything managed by Ansible), but no local host.

---
- name: Ensure the test environment is set up correctly
  hosts: {{ staging_host }}
  tasks:
    - name: Ensure the network *development* is defined correctly and running
      community.libvirt.virt_net:
        xml: '{{ lookup("template", "network_development.xml") }}'
        persistent: no
        active: yes

Run a service in a virtual machine on a dedicated host

Run a service XY in a virtual machine. Again this is for small environments. The host could be selected by the infrastructure file or by a simple management component. In this case, we would configure the autostart option.

---
- name: Ensure the service XY is running
  hosts: all
  tasks:
    - name: Ensure the network *storage* is defined correctly and running
      community.libvirt.virt_net:
        xml: '{{ lookup("template", "network_storage.xml") }}'
        persistent: yes
        active: yes
        autostart: yes