Difference between revisions of "Merlin/MuranoUseCases"

Latest revision as of 13:45, 28 August 2014

Murano uses the concepts of Application and Environment: once user adds an Application to an Environment and configures it, it can be deployed there and provides some services. Several Applications in one Environment can interact with each other and be composed - e.g. MS SQL Server can rely on the Active Directory Server in the same Environment. Most Applications are not atomic Environment components - they are deployed on VM instances, which are Environment components on their own. Moreover, it is theoretically possible for 2 Applications to be deployed on one VM instance, effectively sharing it.

Currently all the configuration steps of an Application are filled using the wizard, where each step is roughly equivalent to a separate component. Application composition is implemented using slightly tuned ‘add-select’ Horizon’s input widget. Suppose we have a Java App relying on a Tomcat Servlet Container App and a PostgreSQL Server App, then the typical workflow for the creation of a new Java App in an empty Environment will be the following: start with Add Java App wizard, on the first step press Add Tomcat App, an Add Tomcat App wizard pop-ups on top of Add Java App, here we cycle through all the steps of Tomcat App creation, press Create, return to the Add Java App wizard, press Add PostgreSQL Server App, an Add PostgreSQL App wizards pop-ups now, cycle through all of its steps, press Create, return to the Add Java App wizard, cycle through all of its steps - voila, Java App and its 2 dependencies are added to the same Environment, configured and ready to deploy. That seems ok from technical point of view, and even the users could get used to that workflow (at least, simultaneous addition of User and Project in ‘Project’ dashboard employs the same workflow).

The problems with a linear sequence of wizards start when we go one level deeper (and believe me, we’ll need it). Suppose we want to deploy several Applications onto one VM instance. At first, it’s simple: just add ‘add-select’ widget typed to show and create only VM instances - then, we create such instance during configuring the first App and select it during configuring the second one. Then add another 3 Apps and tie them all to the same instance. Most probably none of them will function properly after deploy - because 5 Apps is too much for a single VM instance. Of course, there should constraint of some kind - e.g. no more than 2 Apps on the same Instance with ‘Medium’ flavor, no more than 3 Apps on ‘Large’, etc. The engine could hide the ‘Medium’-flavor Instance once the user has tied it to 2 Apps, but such behaviour will be misguiding: how could that constraint be visible to the user, if he doesn’t see any links between the Apps and that Instance? To perceive such constraint, the user has to watch the Instance, all the Apps referencing it and the links between them simultaneously. So, the linear wizards do not provide satisfactory UX in part of constraints handling.

The next limitation with linear wizards arises when one configures multi-instance Application, say Active Directory Service, which consists of one Primary Controller and, optionally, several Secondary Controllers. Current approach is to specify the total number of controllers and make them all the same - according to the parameters specified for all Active Directory App. But what if the user wants to specify, say, ‘Large’ flavor for the Primary Controller’s VM instance and ‘Medium’ flavor for all other Secondary Controllers’ instances? Technically, there are 2 options:

• use the approach from the previous example, where each controller’s instance is configured in a separate wizard - thus the user is forced to specify the values for all the secondary controllers (even if they all use the same configuration), but here is another gotcha - the number of ‘add-select’ widgets needs to be calculated on the fly, based on total number of controllers
• configure each controller on a separate wizard’s step, and configure each successive secondary controller’s instance only if ‘Configure the next controller’s instance’ checkbox on the previous step was set - that option seems a bit better.

But the UX value of both options is nothing compared to the painfulness (or maybe impossibility) of their implementation using current Murano UI processor - I’ve estimated required changes for the second option here, and the result was really disgusting.

So it seems that current Murano App’s configuration UI - both from user’s perspective, and from the implementation’s one - is very limited when it comes to fine-grained Application’s components tuning. Murano needs a UI that:

• exposes link entity - to perceive composition constraints;
• allows for non-linear components configuration - to configure as many components of an Application as user wants and leave other with reasonable defaults - so that he can send the App to deploy with single click instead of tedious filling all components;
• is able to display complex Applications consisting of several levels of hierarchy, i.e. deeply nested components - in order to traverse different levels of hierarchy/nesting, a zoom feature is required;