Jump to: navigation, search


< Murano‎ | Documentation
Revision as of 13:30, 14 April 2014 by Efedorova (talk | contribs) (Forms)

Dynamic UI Definition Manual

The main purpose of Dynamic UI is to generate application creation forms "on-the-fly". Murano dashboard doesn't know anything about what applications can be deployed and witch web form need to be used to create application instance. So all application definitions should contain a yaml file which will tell dashboard now to create an application and what validation to be applied. This document will help you to compose a valid UI definition to your application.


UI definition should be a valid yaml file and should contain the following sections (for version 2):

  • Version - points out to which syntax version is used
  • Templates - optional, auxiliary section, using together with an Application section
  • Application - object model description which will be used in application deployment
  • Forms - web form definitions


Version of supported dynamic UI syntax

Application and Templates

In the Application section "application object model" is described. This model will be translated into json and according to that json application will be deployed. Application section should contain all necessary keys that required for murano-engine to deploy an application. Note that under ? section goes system part of the model. You can pick parameters you got from the user (they should be described in the Forms section) and pick the right place where they should be set. To do this YAQL is used:

  • way of setting variables ($ as the first symbol)
  • repeat function
  • interpolate functions
  type: com.mirantis.murano.services.windows.activeDirectory.ActiveDirectory
  name: $.serviceConfiguration.name
         type: com.mirantis.murano.services.windows.activeDirectory.PrimaryController
         host: $host
         secondaryControllers: repeat($secondaryController, 2, $.serviceConfiguration.dcInstances + 1)


This section describes Django forms. Set name for your form and provide fields and validators. Each field should contain:

  • name - system field name, could be any
  • label - name, that will be displayed in the form
  • description - description, that will be displayed in the form description area. Use yaml line folding character >- to keep the correct formatting during data transferring.
  • type - system field type
  • string - Django string field
  • boolean - Django boolean field
  • text - Django boolean field
  • integer - Django integer field
  • password - Specific field with validation for strong password
  • clusterip - Specific field, used for cluster IP
  • floatingip - Specific field, used for enabling Floating IP during deployment
  • domain - Specific field, used for Active Directory domain
  • databaselist - Specific field, a list of databases (comma-separated list of database names, where each name has the following syntax: first symbol should be latin letter or underscore; subsequent symbols can be Latin letter, numeric, underscore, at the sign, number sign or dollar sign)
  • table - Specific field, used for defining table in a form
  • flavor - Specific field, used for defining flavor in a form
  • keypair - Specific field, used for defining KeyPair in a form
  • image- Specific field, used for defining image in a form
  • azone - Specific field, used for defining availability zone in a form
  • psqlDatabase -Specific field, used for browsing deployed PostgreSQL databases
  • imageType - only for fields of image type. Supported choices are


  - serviceConfiguration:
        - name: name
          type: string
          label: Service Name
          description: >-
            To identify your service in logs please specify a service name
        - name: dcInstances
          type: integer
          attributeNames: units
          hidden: true
          initial: 1
          required: false
          maxLength: 15
          helpText: Optional field for a machine hostname template
  - instanceConfiguration:
            - name: flavor
              type: flavor
              label: Instance flavor
              description: >-
                Select registered in Openstack flavor. Consider that service performance
                depends on this parameter.
              required: false
            - name: osImage
              type: image
              imageType: linux
              label: Instance image
              description: >-
                Select valid image for a service. Image should already be prepared and
                registered in glance.
            - name: availabilityZone
              type: azone
              label: Availability zone
              description: Select availability zone where service would be installed.
              required: false