openstack/murano-specs
Code Issues Proposed changes

Add network selection element to UI form

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

Spec for blueprint ui-network-selection

Change-Id: I94b4017ec466be09bddc6df01b975bbad63cac3b
This commit is contained in:
Alexander Tivelkov 2015-07-21 17:57:36 +03:00
parent 420ec35c7b
commit bc3d0b7634
1 changed files with 267 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

267
specs/liberty/ui-network-selection.rst Normal file
View File

@ -0,0 +1,267 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
========================================
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] <https://wiki.openstack.org/wiki/Murano/Specifications/Network_Management>`_
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]
References
==========
* [1] https://wiki.openstack.org/wiki/Murano/Specifications/Network_Management
* [2] https://review.openstack.org/#/c/201659/
* [3] https://murano.readthedocs.org/en/latest/draft/appdev-guide/muranopackages/dynamic_ui.html#dynamicuispec