Add network selection element to UI form¶

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/murano/+spec/ui-network-selection

Sometime a VM should be placed to existing network rather then to a new network created during deployment. While our workflows support this, there is no way for the end user to select this network in the easy way in the UI. It will be great if there is a special form element which will pre-populate a list of available networks and provide an easy option to select desired network for the application.

Problem description¶

Currently murano supports only so called “Default Scenario” when it comes to networking: it creates a single network per environment, picks a router, allocates an IP range and creates a subnet with this range within a created network. This behavior is fine for most of the cases, however it may be insufficient in complicated scenarios and topologies.

For example, an application may require some pre-configured networks to exist so it may manipulate with the resources associated to them, allocate floating IPs from the specific net etc. In this case, the existing net becomes a valid input property for the application, so its developer may ask the users to specify it before the deployment.

Another scenario is the need to have all the VMs of the environment to join some pre-configured network - regardless of their configuration and the applications they run for. This may be caused by some specific networking requirements of a particular cloud (a frequent example is a custom proxy to access the internet which is reachable only from a specific network segment).

When the Network Management scenarios were initially introduced in murano [1] we planed to have a so-called “Advanced scenario”, i.e to provide the users with an ability to use existing networks, subnets, routers etc, or configure some sophisticated combination of them.

This scenario was properly supported at engine and at the level of the Core Library: the io.murano.resources.Instance class has a networks field which allows to specify customNetworks as a collection of objects inheriting from io.murano.resources.Network, which may include the existing networks or new networks with non-default configuration.

However, there is no support of this functionality at the UI level: the object model being generated by the Dynamic UI contains the default networking definitions only: i.e. the directive to join Environment’s default network, which is - in its turn - is hardcoded to be a newly created network and a subnet in it.

Proposed change¶

A new field will be added to the Dynamic UI framework which will allow to pick the network and a subnet from the ones available to the current user. This will be a drop-down list populated when the form is rendered. The value selected by the user in this field will be a tuple, consisting of the network id and a subnet id. This ids may be passed to the application either as plain strings or as part of a more complicated Object Model, for example as the properties of io.murano.resources.ExistingNeutronNetwork objects. It is up to application developer to properly interpret and use these values. The existing applications will not be affected by this change, as their “configure instance” step of the UI dialog will not include any networking settings. In future some of our standard apps may be updated to utilize this new field, but those updates are out of the scope of this spec.

A similar field (but a static one rather then defined as part of Dynamic UI framework) should be added to the New Environment dialog form, so the user may choose an existing network to be the default network of a given environment. The default value in that choice should lead to the creation of a new environment’s network (i.e. to replicate the existing behavior), while any other choice should lead to a generation of a new object of type io.murano.resources.ExistingNeutronNetwork which will be passed to murano-api as part of defaultNetworks dictionary as the default environment’s network.

Both these fields should share the same logic for value population. Additionally, the dynamic UI field should have the following options, defined as constructor arguments and exposed to dynamic ui as yaml attributes:

include_subnets - True by default. If True, the dropdown includes all the possible combinations of network and subnet. E.g. if there are two available networks X and Y, and X has two subnets A and B, while Y has a single subnet C, then the dropdown will include 3 item: (X, A), (X, B), (Y, C). If set to False the subnet info will not be retrieved, and None values will be returned as second items in output tuples, so only network ids are available.
filter - None by default. If set to a regexp string, will be used to display only the networks with names matching the given regexp.
murano_networks - None by default. May have values None, exclude or translate. Defines the handling of networks which are created by murano. Such networks usually have very long randomly generated names, and thus look ugly when displayed in dropdown. If this value is set to exclude then these networks are not shown in the dropdown at all. If set to translate the names of such networks are replaced by a string Network of %env_name%. Note that this functionality is based on the simple string matching of the network name prefix and the names of all the accessible murano environments. If the environment is renamed after the initial deployment this feature will not be able to properly translate or exclude its network name.
allow_auto - True by default. Defines if the default value of the dropdown (labeled “Auto”) should be present in the list. The default value is a tuple consisting of two None values. The logic on how to treat this value is up to application developer. It is suggested to use this field to indicate that the instance should join default environment network. For use-cases where such behavior is not desired, this parameter should be set to False.

The string representation of the dropdown items should look like %NetworkName%: %cidr% (%SubnetName%), where %SubnetName% part is optional and may be not present if the subnet’s name is not set.

If neutron is not available (so murano falls back to nova-network support) the dropdown (both the static and dynamic ones) are not populated and appropriate hints are available in the New Environment dialog.

Alternatives¶

Currently the only way to change the default networking behavior is the usage of networking.yaml file which allows to override the networking setting at the environment level, for all the murano environments of all the tenants. This is not flexible enough and does not provide the desired user experience.

However this method will remain, as it allows to override the network setting globally.

Data model impact¶

No impact. The existing data structures will be used.

REST API impact¶

No impact. The existing API methods will be used.

Versioning impact¶

As this feature adds a new type of Dynamic UI fields this will bump the minor version of Dynamic UI format version. The version will change from 2.0 to 2.1

Other end user impact¶

The user will see the new field in the “Create Environment” dialog. It will also be shown when the environment is created inline in the environments grid. The default value of this new field will follow the old behavior.

The user experience with the existing applications will not be changed.

Deployer impact¶

The dropdown in Dashboard will be calling public neutron APIs. If they are not accessible due to some reason, the UI will guess that neutron is not installed at all so nova network usage will be assumed. However, the actual decision on the fallback to nova-network is done at the murano-api. So, if the dashboard is unable to connect to neutron while the api is then the behavior is inconsistent: the UI tells user that nova-network is used, while this is not true. No error occur in this case though.

Developer impact¶

The application developers may need to modify their apps to use the new feature. Patch [2] may be used as an example. Existing apps will not be affected, they will just have the old default behavior.

Murano-dashboard / Horizon impact¶

The whole change proposed in this spec is a change of murano-dashboard. No other components are modified.

Implementation¶

Assignee(s)¶

Primary assignee:: ativelkov
Other contributors:: ddovbii

Work Items¶

Implement the shared logic to retrieve and filter the list of networks
Implement the DynamicUI control to select networks in apps
Add a dropdown field to a static Create Environment form to select the default network of the environment.
Add the support of the new control in the existing murano apps in murano-apps repository.

Dependencies¶

Include specific references to specs and/or blueprints in murano, or in other projects, that this one either depends on or is related to.
If this requires functionality of another project that is not currently used by Murano, document that fact.
Does this feature require any new library dependencies or code otherwise not included in OpenStack? Or does it depend on a specific version of library?

Testing¶

There should be an acceptance testing implemented on this feature:

We should test deploying the apps with existing network selected and with the default option.
Modified application (for example [2]) should be deployed both with “Auto” as instance network or with some existing network selected.
The test cases above should verify the ability to assign floating IPs to the VMs
The networks being used as an options for the manual selection should be connected to a router uplinked to the external network (otherwise app deployment will fail). Also the DNS nameservers has to be manually assigned on those networks.

Documentation Impact¶

A new Dynamic UI field type has to be documented at Dynamic UI definition specification guide at [3]