Open Stack

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
> templates/environments
>
>
> # Overview
>
> I've used Ben Nemec's amazing Network template generator as a reference
> to help me understand how the network configuration works [1]. 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
>
>
[snip]
> # 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:
>
> resource_registry:
>   OS::TripleO::Network::Storage: ../network/storage.yaml
>   OS::TripleO::Network::Ports::StorageVipPort:
> ../network/ports/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 
like:

roles:
   Controller:
     networks:
       - provision
       - external
       - internal
       ...
   Compute:
     networks:
       -provision
       ...

as opposed to what I think you're describing, which is

networks:
   Provision:
     roles:
       - controller
       - compute
   External:
     roles:
       - controller
   ...

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 [5],
> 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 [6].
>
>
> 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 [7] 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.
>
>
> [1]
> http://blog.nemebean.com/content/tripleo-network-isolation-template-generator
>
> [2] https://github.com/openstack/tripleo-heat-templates
> [3]
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/network-environment.yaml
>
> [4]
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/network-isolation.yaml
>
> [5] https://openstack.invisionapp.com/share/UM87J4NBQ#/screens/179046668
> [6] https://openstack.invisionapp.com/share/UM87J4NBQ#/screens/179046679
> [7] https://review.openstack.org/#/c/396383/
>
> Thanks
> Jirka
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev