Open Stack

On Thu, Dec 15, 2016 at 03:46:05PM -0600, Ben Nemec wrote:
> 
> 
> 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:

I agree - we already have a list of roles (in roles_data.yaml), so the
approach I've been experimenting with is to also define a list of networks,
then we can assign those networks to each role in roles_data.yaml (or some
other file containing the same data).

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

+1 this is pretty much what I have proposed here:

https://review.openstack.org/#/c/409920/2/roles_data.yaml

Then the missing piece is a list of networks (so that in future we can have
fully composable or custom networks), I proposed a network_data.yaml here:

https://review.openstack.org/#/c/409921/

There is some discussion about if we do that, or instead have a single file
e.g "plan_data.yaml" or similar, but logically I think both of these fit
with your preferred mental model? :)

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

I agree, this second approach is awkward wrt the custom roles architecture,
and I'd prefer the former.

Thanks!

Steve