Murano/Documentation/DynamicUI
Contents
Dynamic UI Definition specification
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.
Structure
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, optional
- Templates - optional, auxiliary section, using together with an Application section, optional
- Application - object model description which will be used in application deployment, required
- Forms - web form definitions, required
Version
Version of supported dynamic UI syntax. The latest version is 2. Version mapping: Murano 0.4 - version 1 Murano 0.5 - version 2
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
Example:
Application:
?:
type: com.mirantis.murano.services.windows.activeDirectory.ActiveDirectory
name: $.serviceConfiguration.name
primaryController:
?:
type: com.mirantis.murano.services.windows.activeDirectory.PrimaryController
host: $host
secondaryControllers: repeat($secondaryController, 2, $.serviceConfiguration.dcInstances + 1)
Forms
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. Apply filters to all murano images by image type name, registered during adding metadata to an image.
Example
Forms:
- serviceConfiguration:
fields:
- 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:
fields:
- 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