Open Stack

Hi folks,

There is an important topic which I would like to discuss: it seems like
there is a place for improvement in UI validation and filtering in Murano.

The reason of writing this is a change-set [1] (being an implementation of
blueprint [2]) which allows package developers to specify the constraints
for Flavor fields in dynamic UI definitions, and a little controversy about
this commit among the core team.
In my opinion, the change itself is great (thanks, Ryan!) and I am going to
put my +2 on it, but I would like to say that there may exist a better and
more complete approach, which we probably should adopt in future.


The main idea is that in Murano we have a concept of Application
Definitions, and these definitions should be complete enough to specify all
the properties, dependencies, constraints and limitations for each
application in the Catalog.
Currently we write these defintions in MuranoPL, and the constraints and
limitations are defined as its Contracts.

For example, imagine we have an application which should be run on a Server
having some specific hardware spec, e.g. having not less then 2 CPU cores
and at least 8 Gb of RAM.
In this case, these limits may be expressed as the Contract on the property
defining the reference to the VM. The contract may look like this:

$.class(Instance).check($.flavor.cpuCores>=2 and $.flavor.ramMb>=8192)

(this will require us to create a data structure for flavors: currently we
use plain string names - but this is quite an easy and straitforward change)

Defining filter constraints on the UI side without having them in MuranoPL
constraints is not enough: even if the UI is used to restrict the values of
some properties, these restrictions may be ignored if the input object mode
is composed manually and is sent to MuranoAPI without UI usage. This means
that the MuranoPL contract should be the primary source of
constraints/limitations, while the UI-side properties only suppliment them.

This causes the need of defining constraints in two locations: in MuranoPL
for runtime validation and in UI definitions for "client-side" checks and
filtering. These two have different notations: MuranoPL uses flexible
yaql-based contracts, which allow to construct and enforce almost eny
expressions, while DynamicUI has a limited number of available properties
for each type of input field. If some field does not have ability to
enforce some check, then it has to be added in python code and commited to
Murano's codebase, which contradicts with the mission of Application
Catalog.
This approach is overcomplicated, as it requires the package developer to
learn two different notations. Also it is error-prone, as there is no
automatic way to ensure that the "ui-side" constraint definitions do really
match the MuranoPL contracts.


So, I would prefer to have a single location of constraint definitions -
MuranoPL contracts. These contracts (in their yaql form) should be
processible by the dynamic UI  and should be used for both field value
checks and dropdown lists filterings.
Also, the UI form for each component of the environment should be displayed
and validated in the context of the contract applied to this component.
In the example given above, the virtual machine contract is defined for the
application class, while the UI form for it is defined for "Instance"
class. While this form should be the same in all usages of this class, its
context (availability and possible values of different fields) should be
defined by the contracts defined by the class which uses it, i.e. the
Application.



As a bottom line, I would suggest to accept commit [1] for now (we need
flavor filtering anyway), but agree that this should be a temporary
workaround. Meahwile, we need to design and implement a way of passing
contracts from MuranoPL classes to the UI engine and use this contracts fro
both API-side validation and list filtering.


[1] https://review.openstack.org/#/c/97904/
[2]
https://blueprints.launchpad.net/murano/+spec/filter-flavor-for-each-service

--
Regards,
Alexander Tivelkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/299ef047/attachment.html>