Improved, automatic network config generation

Registered by Nolan Brubaker

Overview
########

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 (https://galaxy.ansible.com/list#/roles/1570) 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 http://docs.debops.org/en/latest/ansible/roles/debops.ifupdown.html
Code is at https://github.com/debops/ansible-ifupdown

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:

dresden-weekly.network-interfaces (https://galaxy.ansible.com/list#/roles/2766) - The tasks in the role try to do way too many conditionals and don't appear to follow Ansible best practices.
bennojoy.network_interfaces (https://galaxy.ansible.com/list#/roles/3) - 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.

Alternatives
------------

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
---------------

None

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
---------------

None

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

Status:
Complete
Approver:
None
Priority:
Medium
Drafter:
Nolan Brubaker
Direction:
Needs approval
Assignee:
Nolan Brubaker
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Nolan Brubaker

Related branches

Sprints

Whiteboard

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.