Improved, automatic network config generation

Registered by Nolan Brubaker


Our deployment should allow for an automatically-created interfaces file based on information container in the Ansible inventory. This will help deployers/operators be more efficient with their rollouts.

Problem Description

Currently, administrators deploying our stack have to manually configure the networking for each node. This is tedious and error prone, especially in large clusters.

There existed a `host_networks` role that created a interfaces file that could be manually reviewed then linked, but the implementation left a lot to be desired - the specification of the interfaces was all done inside of the playbooks, and was actually more verbose than writing the interfaces file by hand.

Proposed Change

I propose that we investigate using the debops.ifupdown Galaxy role ( for a few reasons

1 - It's already written, hopefully meaning we don't have to implement this ourselves
2 - It requires us to move towards an ansible-galaxy-based workflow, which can be useful in the future if we start to 'galaxify' other standard components like MariaDB or Rabbit.
3 - Thus far, the maintainer has been fast to answer bugs and open to making changes.
4 - The overaching debops collection of roles might be useful for other generic services as mentioned in 2, which then gives us a consistent base to build on.

Documentation is at
Code is at

I've given a brief review of the other two galaxy roles that manage networks on Ansible Galaxy, and have decided against them for the following reasons: ( - The tasks in the role try to do way too many conditionals and don't appear to follow Ansible best practices.
bennojoy.network_interfaces ( - The tasks seem to be fairly clean and it follows Ansible best practices, but has a lot of logic for dealing with Red Hat systems, which might be too much overhead. This might be a good second alternative to look into, though.

Playbook Impact

This will require that we make some of our roles depend on the debops.ifupdown role. Also, we will need to modify our installation process to fetch ansible-galaxy roles.

For configuration files, we will need to enter the networking information.


Write our own implementation, which would allow us to control the exact details and delay the need to write ansible-galaxy logic in our installation scripts/docs.

However, any solution will require changes to our configuration files if the user decides to have ansible generate their interfaces file.

Security Impact


Performance Impact

The performance impact here should be negligible to nonexistent - the generated files should be the same as what's currently written by hand, but with less operator time spent.

End User Impact


Deployer Impact

More straightforward deployment, since manually creating the network files is unnecessary. There does, however, exist the possibility that the boxes could become unreachable if the wrong information is specified in the ansible configuration.

Developer Impact

This will require changing our process for installation, as it will introduce a dependency on the ansible-galaxy program, and on having the debops.ifupdown role available. We're also exposed to potential upstream changes within that role. The AIO scripts and gating will also need to be updated to make sure the ifupdown configurations we specify actually work.

Blueprint information

Nolan Brubaker
Needs approval
Nolan Brubaker
Series goal:
Milestone target:
Completed by
Nolan Brubaker

Related branches



This has been obsoleted due to the fact that further discussions have led to to the decision that host network configuration does not belong in openstack-ansible-deployment. It may be implemented outside of the repository, but it's not a goal for the main project.


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.