Open Stack

On 02/09/2018 08:49 AM, Jiri Tomasek wrote:
> *Step 2. network-environment -> NIC configs*
> 
> Second step of network configuration is NIC config. For this 
> network-environment.yaml is used which references NIC config templates 
> which define network_config in their resources section. User is 
> currently required to configure these templates manually. We would like 
> to provide interactive view which would allow user to setup these 
> templates using TripleO UI. A good example is a standalone tool created 
> by Ben Nemec [3].
> 
> There is currently work aimed for Pike to introduce jinja templating for 
> network environments and templates [4] (single-nic-with-vlans, 
> bond-with-vlans) to support composable networks and roles (integrate 
> data from roles_data.yaml and network_data.yaml) It would be great if we 
> could move this one step further by using these samples as a starting 
> point and let user specify full NIC configuration.
> 
> Available information at this point:
> - list of roles and networks as well as which networks need to be 
> configured at which role's NIC Config template
> - os-net-config schema which defines NIC configuration elements and 
> relationships [5]
> - jinja templated sample NIC templates
> 
> Requirements:
> - provide feedback to the user about networks assigned to role and have 
> not been configured in NIC config yet

I don't have much to add on this point, but I will note that because my 
UI is standalone and pre-dates composable networks it takes the opposite 
approach.  As a user adds a network to a role, it exposes the 
configuration for that network.  Since you have the networks ahead of 
time, you can obviously expose all of those settings up front and ensure 
the correct networks are configured for each nic-config.

I say this mostly for everyone's awareness so design elements of my tool 
don't get copied where they don't make sense.

> - let user construct network_config section of NIC config templates for 
> each role (brigdes/bonds/vlans/interfaces...)
> - provide means to assign network to vlans/interfaces and automatically 
> construct network_config section parameter references

So obviously your UI code is going to differ, but I will point out that 
the code in my tool for generating the actual os-net-config data is 
semi-standalone: 
https://github.com/cybertron/tripleo-scripts/blob/master/net_processing.py

It's also about 600 lines of code and doesn't even handle custom roles 
or networks yet.  I'm not clear whether it ever will at this point given 
the change in my focus.

Unfortunately the input JSON schema isn't formally documented, although 
the unit tests do include a number of examples. 
https://github.com/cybertron/tripleo-scripts/blob/master/test-data/all-the-things/nic-input.json 
covers quite a few different cases.

> - populate parameter definitions in NIC config templates based on 
> role/networks assignment
> - populate parameter definitions in NIC config templates based on 
> specific elements which use them e.g. BondInterfaceOvsOptions in case 
> when ovs_bond is used

I guess there's two ways to handle this - you could use the new jinja 
templating to generate parameters, or you could handle it in the 
generation code.

I'm not sure if there's a chicken-and-egg problem with the UI generating 
jinja templates, but that's probably the simplest option if it works. 
The approach I took with my tool was to just throw all the parameters 
into all the files and if they're unused then oh well.  With jinja 
templating you could do the same thing - just copy a single boilerplate 
parameter header that includes the jinja from the example nic-configs 
and let the templating handle all the logic for you.

It would be cleaner to generate static templates that don't need to be 
templated, but it would require re-implementing all of the custom 
network logic for the UI.  I'm not sure being cleaner is sufficient 
justification for doing that.

> - store NIC config templates in deployment plan and reference them from 
> network-environment.yaml
> 
> Problems to solve:
> As a biggest problem to solve I see defining logic which would 
> automatically handle assigning parameters to elements in network_config 
> based on Network which user assigns to the element. For example: Using 
> GUI, user is creating network_config for compute role based on 
> network/config/multiple-nics/compute.yaml, user adds an interface and 
> assigns the interface to Tenant network. Resulting template should then 
> automatically populate addresses/ip_netmask: get_param: TenantIpSubnet. 
> Question is whether all this logic should live in GUI or should GUI pass 
> simplified format to Mistral workflow which will convert it to proper 
> network_config format and populates the template with it.

I guess the fact that I separated the UI and config generation code in 
my tool is my answer to this question.  I don't remember all of my 
reasons for that design, but I think the main thing was to keep the 
input and generation cleanly separated.  Otherwise there was a danger of 
making a UI change and having it break the generation process because 
they were tightly coupled.  Having a JSON interface between the two 
avoids a lot of those problems.  It also made it fairly easy to unit 
test the generation code, whereas trying to mock out all of the UI 
elements would have been a fragile nightmare.

It does require a bunch of translation code[1], but a lot of it is 
fairly boilerplate (just map UI inputs to JSON keys).

1: 
https://github.com/cybertron/tripleo-scripts/blob/171aedabfead1f27f4dc0fce41a8b82da28923ed/net-iso-gen.py#L515

Hope this helps.

-Ben