[openstack-dev] [TripleO] Network Configuration in TripleO UI
openstack at nemebean.com
Thu Dec 15 21:46:05 UTC 2016
On 12/08/2016 08:05 AM, Jiri Tomasek wrote:
> Hi all,
> 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
> # Overview
> 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
> # 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:
> OS::TripleO::Network::Storage: ../network/storage.yaml
This seems like an obvious improvement, and is essentially how my tool
works too except that it munges all of the individual environments back
together at the end.
Definite +1 from me.
> 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.
This sounds reasonable to me, but I do want to note that assigning roles
to networks feels a little backwards to me. I tend to think of a role
as kind of the top level thing here, to which we assign other things
(services and networks, for example). So my mental model kind of looks
as opposed to what I think you're describing, which is
Maybe there are benefits to modeling it as the latter, but I think the
former fits better with the composable roles architecture.
> 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.
>  https://github.com/openstack/tripleo-heat-templates
>  https://openstack.invisionapp.com/share/UM87J4NBQ#/screens/179046668
>  https://openstack.invisionapp.com/share/UM87J4NBQ#/screens/179046679
>  https://review.openstack.org/#/c/396383/
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev