In a deployable XML document, the "parameter" XML element indicates a piece of information passed to a configuration script for a launching instance.
Each parameter may be either a reference parameter or a launch-time parameter. Reference parameters collect their value from another launching instance in the same deployment. Launch-time parameters require the person launching the deployment to provide the value via Conductor.
In Conductor, the "type" attribute (previously associated with the parameter XML element) indicates the type of value the individual must provide when launching the deployment. Conductor uses the type attribute to know which HTML field to present to the user during the launch process. For instance, a "password" type indicates that Conductor should display an HTML password field, so as to hide the entered value in the display (NOTE: Currently only "scalar" and "password" types are supported).
In Conductor 1.1, the "type" attribute has been moved from the parameter XML element to the value XML element. This more accurately reflects the notion that only launch-time parameters require a "type" to be set, because reference parameters inherit their type from the launching instance providing the value for parameter.
A deployable with a type attribute on a parameter XML element will produce the following warning:
"Deprecation Warning: Parameter '<parameter name>' in service '<service name>' has a type attribute. Remove the type attribute or move it to a child value tag."
To remedy this, the deployable maintainer can either remove the type attribute from the parameter XML element, or move the type attribute from the parameter XML element to the value XML element nested inside the parameter. NOTE: If the deployable maintainer chooses to remove the type attribute (and not move it to the value XML element), Conductor will assume that the HTML field type should be a standard text input field.
Example 1: Deprecated parameter block
<parameter type="scalar" name="Parameter1">
<value>Default</value>
</parameter>
Example 2: Fix by removing type attribute
<parameter name="Parameter1">
<value>Default</value>
</parameter>
Example 3: Fix by moving the type attribute to the value element
<parameter name="Parameter1">
<value type="scalar">Default</value>
</parameter>
Created attachment 628364[details]
Screen Shot of Deprication Warning
When a user uses services that have "type=" and they save their blueprint,
they will see the warnings in the attached screenshot.
We should have a release note that explains why it's being depreciated and provides an example of how to change a blueprint that was using it to fit the new mode of operation.
in 1.O application blueprint template:
<service>
...
<parameter name="param-1" type="scalar">
...
</service>
in 1.1 application blueprint template:
<service>
...
<parameter name="param-1">
<value type="scalar">default_text</value>
</parameter>
...
</service>
Q1: Does both templates evoke warnings?
Q2: Need more info on why "type=" is deprecated.
Thanks,
Julie
Created attachment 628364 [details] Screen Shot of Deprication Warning When a user uses services that have "type=" and they save their blueprint, they will see the warnings in the attached screenshot. We should have a release note that explains why it's being depreciated and provides an example of how to change a blueprint that was using it to fit the new mode of operation.