Hi All, I've made some additional updates to my wireframes[1] and I think they are in a good spot now for a discussion/review at the PTG next week.
Please feel free to reach out with any questions or feedback! Thanks, Liz [1] https://lizsurette.github.io/OpenStack-Design/tripleo-ui/3-tripleo-ui-edge-cases/7.advancednetworkconfigurationandtopology On Thu, Feb 22, 2018 at 7:55 PM, Dan Sneddon <dsned...@redhat.com> wrote: > > > On Thu, Feb 15, 2018 at 2:00 AM, Jiri Tomasek <jtoma...@redhat.com> wrote: > >> >> On Wed, Feb 14, 2018 at 11:16 PM, Ben Nemec <openst...@nemebean.com> >> wrote: >> >>> >>> >>> 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/t >>> ripleo-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/tes >>> t-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/171aedabfe >>> ad1f27f4dc0fce41a8b82da28923ed/net-iso-gen.py#L515 >>> >>> Hope this helps. >> >> >> Ben, thanks a lot for your input. I think this makes the direction with >> NIC configs clearer: >> >> 1. The generated template will include all possible parameters >> definitions unless we find a suitable way of populating parameters section >> part of template generation process. Note that current jinja templates for >> NIC config (e.g. network/config/multiple-nics/role.role.j2.yaml:127) >> create these definitions conditionally by specific role name which is not >> very elegant in terms of custom roles. >> > > This patch recently landed, which generates all the needed parameters in > the sample NIC configs based on the composable networks defined in > network_data.yaml: > https://review.openstack.org/#/c/523638 > > Furthermore, this patch removes all the role-specific hard-coded > templates, and generates templates based on the role-to-network association > in roles_data.yaml. > > I think we could use this method to generate the needed parameters for the > templates generated in the UI. I would personally like to see a workflow > where the user chose one of the built-in NIC config designs to generate > samples, which could then be further edited. Presenting a blank slate to > the user, and requiring them to build up the hierarchy is very confusing > unless the installer is very familiar with the desired architecture (first > add a bridge, then add a bond to the bridge, then add interfaces to the > bond, then add VLANs to the bridge). It's better to start with a basic > example (VLANs on a single NIC, one NIC per network, DPDK, etc.), and allow > the user to customize from there. > > >> >> 2. GUI is going to define forms to add/configure network elements >> (interface, bridge, bond, vlan, ...) and provide user friendly way to >> combine these together. The whole data construct (per Role) is going to be >> sent to tripleo-common workflow as json. Workflow consumes json input and >> produces final template yaml. I think we should be able to reuse bunch of >> the logic which Ben already created. >> >> Example: >> json input from GUI: >> ..., { >> type: 'interface', >> name: 'nic1', >> network_name_lower: 'external' >> },... >> transformed by tripleo-common: >> ... >> - type: interface >> name: nic{{loop.index + 1}} >> use_dhcp: false >> addresses: >> - ip_netmask: >> get_param: {{network.name}}IpSubnet >> ... >> >> With this approach, we'll create common API provided by Mistral to >> generate NIC config templates which can be reused by CLI and other clients, >> not TripleO UI specifically. Note that we will also need a 'reverse' >> Mistral workflow which is going to convert template yaml network_config >> into the input json format, so GUI can display current configuration to the >> user and let him change that. >> >> Liz has updated network configuration wireframes which can be found here >> https://lizsurette.github.io/OpenStack-Design/tripleo- >> ui/3-tripleo-ui-edge-cases/7.advancednetworkconfigurationandtopology . >> The goal is to provide a graphical network configuration overview and let >> user perform actions from it. This ensures that with every action >> performed, user immediately gets clear feedback on how does the network >> configuration look. >> >> -- Jirka >> > > I like the wireframes overall. However, I'm trying to avoid a flexible and > open-ended configuration if it isn't clear what the final configuration > should look like. We want to present the user with some basic forms, and > let them modify those forms to their needs. > > >> >> >> >>> >>> >>> -Ben >>> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Dan Sneddon | Senior Principal OpenStack Engineer > dsned...@redhat.com | redhat.com/openstack > dsneddon:irc | @dxs:twitter > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev