[openstack-dev] [TripleO] Network Configuration in TripleO UI
jtomasek at redhat.com
Thu Dec 8 14:05:19 UTC 2016
I've been investigating how to implement TripleO network configuration
in TripleO UI. Based on my findings I'd like to propose a solution.
tl;dr proposal: Slightly refactor Network environment files to match GUI
usage, Use Jinja Templating to generate dynamic parts of the
I've used Ben Nemec's amazing Network template generator as a reference
to help me understand how the network configuration works . In
general the process of configuring the network in TripleO is:
Define which Networks we intend to use -> Assign Roles to the Networks
(+ Assign Role Services to the Network) -> Generate NIC config templates
based on previous information
# Deeper dive into templates
We currently have 2 environment files in THT  which define network
network-environment.yaml  - holds the information on NIC
configuration for each Role using
OS::TripleO::<RoleName>::Net::SoftwareConfig resource + related
- defines the list of networks using OS::TripleO::Network::<NetworkName>
- defines ports configuration for each network using
OS::TripleO::Network::Ports::<NetworkName>VipPort (note that both
resources point to the static templates - those templates don't require
any manual modification)
- holds Roles - Networks assignment using
OS::TripleO::<RoleName>::Ports::<NetworkName>Port for each role and
storage (again, templates referenced by those resources don't require
User is intended to go ahead and modify those environments and provide
NIC config templates to achieve a network configuration that matches his
# How GUI works
Before proceeding to proposed changes I need to describe briefly how
TripleO UI works. TripleO UI is using THT as a source of truth, which
means that it is trying not to add any additional business logic or
manipulate templates. Rather it uses environment files as a 'features'
which user can enable or disable depending on the needs of the
deployment. The information about inter-environment relationships is
tracked in capabilities-map.yaml which is also part of the THT. Based on
these choices, UI allows user to configure parameters for those
features. The parameter values and information about which environments
are selected is stored in mistral environment. This approach leaves the
plan templates intact. Huge benefit of this approach is that UI (or
tripleo-common) does not need to hold explicit business logic related to
certain deployment features as it is purely driven by THT. Also Adding a
new feature involves only providing the templates/environments and it
automatically appears as an option in UI.
To achieve best user experience while using this approach, the
environment files need to be defined in a granular manner, so they don't
require user to modify them and each describe an isolated 'feature'.
Roles and Network Configuration are exceptions to this concept as they
require modification/generation of the templates/environments and
therefore they use Jinja templating to achieve that.
# The proposal
So having described previous, here is the approach I think we should use
to achieve network configuration using TripleO UI:
1. Put networks definitions into separate environment for each network:
- this way GUI can provide a list of networks available to use and let
user select which of them he wants to use. These environments are not
dynamic and if user wants to add a new network, he does so by creating
new templates and environment for it. UI also provides means to
configure parameters for each network at this point (if needed).
For example the environment for a Storage Network looks like this:
2. Assign Roles to Networks
Having the Networks selected as well as Roles defined, TripleO UI
provides user with means to assign Roles to Networks. This step involves
generating the network-environment.yaml file. So TripleO UI sends the
mapping of roles to network in json format to tripleo-common which in
turn uses network-isolation.j2.yaml Jinja template to generate the
environment file. I expect that pre-defined network-isolation.yaml will
be included in default plan so the user does not need to start from
scratch. Tripleo-common also provides an action to fetch network-roles
assignment data by parsing the network-isolation.yaml
In addition, user is able to assign individual Role Services to a
Network. ServiceNetMap parameter is currently used for this. GUI needs
to make sure that it represents Services-Networks assignment grouped by
Role so it is ensured that user assigns Services to only networks where
their Role is assigned.
3. Generate NIC Config templates
TripleO UI provides means to configure NICS, Bonds etc. for each Role,
using the information from previous steps. It sends the data in json
format to tripleo-common which then generates nic config templates for
each Role based on network/config/nic-configs/role.j2.yaml Jinja
template and generates network-environment.yaml based on
network-environment.j2.yaml which references those templates.
Note that network-environment.j2.yaml probably can't be combined with
network-isolation.j2.yaml as every time that environment would need to
get updated, all data the template needs would need to be provided.
There are wireframes made by Liz Blanchard currently available ,
althought they are not exactly up to date to this proposal. Ideally
whole network configuration would happen on a screen based on the
graphical representation of network .
Any comments to this proposal are very welcome, please note that I am
not a networking expert so I might be missing something.
There is a spec  in progress aimed for Ocata, but the feature will
highly probably not land in Ocata, so we'll need to update the spec and
move it to next cycle.
More information about the OpenStack-dev