<div dir="ltr"><div>Hi folks,</div><div><br></div><div>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.</div><div><br></div>

<div>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. </div>

<div>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. </div>

<div><br></div><div><br></div><div>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. </div>

<div>Currently we write these defintions in MuranoPL, and the constraints and limitations are defined as its Contracts.</div><div><br></div><div>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.</div>

<div>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:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="courier new, monospace">$.class(Instance).check($.flavor.cpuCores>=2 and $.flavor.ramMb>=8192) </font></div>
</blockquote><div>(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)</div><div><br></div><div>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. </div>

<div><br></div><div>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. </div>

<div>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. </div>

<div><br></div><div><br></div><div>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. </div>

<div>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.</div><div>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.</div>

<div><br></div><div><br></div><div><br></div><div>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. </div>

<div><br></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/97904/" target="_blank">https://review.openstack.org/#/c/97904/</a></div><div>[2] <a href="https://blueprints.launchpad.net/murano/+spec/filter-flavor-for-each-service" target="_blank">https://blueprints.launchpad.net/murano/+spec/filter-flavor-for-each-service</a></div>
<div><br></div><div><font>--<br></font><div dir="ltr"><font>Regards,<br>Alexander Tivelkov</font></div></div>
</div>