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 which web form are needed to create application instance. So all application definitions should contain a yaml file which tells dashboard how to create an application and what validations are to be applied. This document will help you to compose a valid UI definition for your application.
UI definition should be a valid yaml file and should contain the following sections (for version 2):
Version of supported dynamic UI syntax. The latest version is 2. This is optional section, default version is set to 1. Version mapping: Murano 0.4 - version 1 Murano 0.5 - version 2
In the Application section an 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 are required by 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. All lines are going to be checked for a yaql expressions. Currently, 2 yaql functions are provided for object model generation:
Note that while evaluating YAQL expressions referenced from Application section (as well as almost all attributes inside Forms section, see later) $ root object is set to the list of dictionaries with cleaned forms’ data. So to obtain cleaned value of e.g. field name of form appConfiguration , you should reference it as $.appConfiguration.name. This context will be called as standard context throughout the text.
Example:
Templates:
primaryController:
?:
type: io.murano.windows.activeDirectory.PrimaryController
host:
?:
type: io.murano.windows.Host
adminPassword: $.serviceConfiguration.adminPassword
name: generateHostname($.serviceConfiguration.unitNamingPattern, 1)
flavor: $.instanceConfiguration.flavor
image: $.instanceConfiguration.osImage
secondaryController:
?:
type: io.murano.windows.activeDirectory.SecondaryController
host:
?:
type: io.murano.windows.Host
adminPassword: $.serviceConfiguration.adminPassword
name: generateHostname($.serviceConfiguration.unitNamingPattern, $index + 1)
flavor: $.instanceConfiguration.flavor
image: $.instanceConfiguration.osImage
Application:
?:
type: io.murano.windows.activeDirectory.ActiveDirectory
name: $.serviceConfiguration.name
primaryController: $primaryController
secondaryControllers: repeat($secondaryController, $.serviceConfiguration.dcInstances - 1)
This section describes markup elements for defining forms (which are currently rendered and validated with Django). Each form has name, field definitions (mandatory) and validator definitions (optionally). Note that each form is splitted into 2 parts - input area (left side, where all the controls are located) and description area (right side, where descriptions of the controls are located).
Each field should contain:
Currently supported options for type attribute are:
Other arguments (and whether they are required or not) depends on field’s type and other attributes values. Among the most common attributes are:
Besides field-level validators form-level validators also exist. They use standard context for YAQL evaluation and are required when there is need to validate some form’s constraint across several fields.
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
hidden: true
initial: 1
required: false
maxLength: 15
helpText: Optional field for a machine hostname template
- name: unitNamingPattern
type: string
label: Hostname template
description: >-
For your convenience all instance hostnames can be named
in the same way. Enter a name and use # character for incrementation.
For example, host# turns into host1, host2, etc. Please follow Windows
hostname restrictions.
required: false
regexpValidator: '^(([a-zA-Z0-9#][a-zA-Z0-9-#]*[a-zA-Z0-9#])\.)*([A-Za-z0-9#]|[A-Za-z0-9#][A-Za-z0-9-#]*[A-Za-z0-9#])$'
# FIXME: does not work for # turning into 2-digit numbers
maxLength: 15
helpText: Optional field for a machine hostname template
# temporaryHack
widgetMedia:
js: ['muranodashboard/js/support_placeholder.js']
css: {all: ['muranodashboard/css/support_placeholder.css']}
validators:
# if unitNamingPattern is given and dcInstances > 1, then '#' should occur in unitNamingPattern
- expr: $.serviceConfiguration.dcInstances < 2 or not $.serviceConfiguration.unitNamingPattern.bool() or '#' in$.serviceConfiguration.unitNamingPattern
message: Incrementation symbol "#" is required in the Hostname template
- instanceConfiguration:
fields:
- name: title
type: string
required: false
hidden: true
descriptionTitle: Instance Configuration
description: Specify some instance parameters on which service would be created.
- 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: windows
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
Full example with Active Directory application form definitions is available here ad.yaml