Re: [openstack-dev] [TripleO][ui] Network Configuration wizard
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 wrote: > > > On Thu, Feb 15, 2018 at 2:00 AM, Jiri Tomasek wrote: > >> >> On Wed, Feb 14, 2018 at 11:16 PM, Ben Nemec >> 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
Re: [openstack-dev] [TripleO][ui] Network Configuration wizard
On Thu, Feb 15, 2018 at 2:00 AM, Jiri Tomasek wrote: > > On Wed, Feb 14, 2018 at 11:16 PM, Ben Nemec > 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
Re: [openstack-dev] [TripleO][ui] Network Configuration wizard
Re-sending from the account I'm subscribed with. On 02/15/2018 10:40 AM, Ben Nemec wrote: On 02/15/2018 04:00 AM, Jiri Tomasek wrote: 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. Oh, that reminds me: there were some things that I needed to store for GUI use that aren't represented in the output templates. That's why my tool writes out a pickle file that contains the intermediate data format, and when it loads a set of templates it actually reads that pickle file, not the templates themselves. I don't recall all of the bits, but at a glance I see that I had stored values for auto_routes, ipv6, and version. You can probably ignore version since you'll only ever need to support version 2, and it's possible you could derive the other two values based on the values in the templates. It would require some fuzzy logic though, I think. I believe there was also some one-way transformation done on the data when converting the JSON data to templates. I'm not sure whether that could be reversed from just the templates. It would certainly be more complex to do it that way. Just something to keep in mind. Especially because these templates will mostly never be seen by end-users since they'll go straight into the plan, it may be much simpler to store intermediate data alongside the templates and use that for populating the GUI. __ 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
Re: [openstack-dev] [TripleO][ui] Network Configuration wizard
On Wed, Feb 14, 2018 at 11:16 PM, Ben Nemec 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 an
Re: [openstack-dev] [TripleO][ui] Network Configuration wizard
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 the
