* For the sake of the service performance, it may make sense to
disable validation of the workflow language syntax if it is
affordable for a particular use case. For example, if all
workflows are auto-generated by a 3rd party system and tested
thoroughly (either by running them with Mistral or at least
validating them via the special Mistral endpoint) then we can
safely disable validation of the language syntax when uploading
workflow definitions. For production systems it makes a big
difference if workflow texts are large (thousands of tasks).
This patch adds the boolean parameter "skip_validation" for API
requests like "POST /v2/workflows" to disable validation, if
needed, and the new configuration property "validation_mode"
to set a desired validation mode.
The option is an enumeration and has the following valid values:
1) "enabled" - enabled for all API requests unless it's
explicitly disabled in the request itself
2) "mandatory" - enabled for all API requests regardless
of the flag in the request
3) "disabled" - disabled for all API requrests regardless
of the flag in the request
"mandatory" is choosen as the default value for this new
property to keep compatibility with the previous versions.
* Minor style changes.
Closes-Bug: #1844242
Change-Id: Ib509653d38254954f8449be3031457e5f636ccf2
* Various simple optimizations for creation of specs. Mostly
additional caching of non-growing data related to the
structure of the language spec classes. For huge workflows
with thousands of tasks these changes reduce execution time
by dozens of seconds.
* Minor style changes.
Partial-bug: #1844242
Change-Id: Ia700e25752d9d35ece18609f2977e6568062e4bf
Using default mutable parameter is bad.
Default parameters are evaluated only once
if you mutate it you will get unexpected results.
Since we don't mutate here the default paramter, make
sure it is unmutable.
Change-Id: Ib5c451a8c8cad7b6c9a009369c1c039563023368
Currently when we get a specification using the instantiate_spec function,
we always validate their schema and semantics over and over again.
To prevent it we add new validate parameter to a Spec class.
The validate parameter must be True when we create a workflow, workbook
or action using a mistral-api. In all other cases, it must be False.
Change-Id: Ia450ea9635bc75c204fe031cfeeab154f1d03862
Closes-Bug: #1738769
Signed-off-by: Vitalii Solodilov <mcdkr@yandex.ru>
Evaluate action names dynamically, so yaql or jinja expression can be
used
Change-Id: I48761c215f0255976c330ffa34f27bb695c944a9
Implements: blueprint mistral-dynamic-actions
Evaluate workflow names dynamically, so yaql or jinja expression
is allowed as sub-workflow name. Tasks names are not yet
dynamically evaluated.
Partially implements: blueprint mistral-dynamic-actions
Change-Id: Icfe591e27a4f45c2e3dcfa83512217f3b2122189
* Before this patch some language specification schemas were
validated twice (or even more) because some parent specs had
references to specific schemas of child specs in their schemas.
And due to our recursive parsing algorithm the same schemas were
checked many times. It reduces performance and complicates
the entire lang specification framework because there's too many
relationships between different specs. The better approach is to
reduce a number of relationships. One way is to not check schemas
child specs when checking parent spec schema. This patch removes
such references replacing them just common schemas like
"non-empty" or "any" which don't lead to validating sub-schemas
when validating parent schemas.
* Minor style changes
Change-Id: I6b695c1870bf8b70112332d4052115543382cdc7
* 'on-success', 'on-error' and 'on-complete' can now look like
described in "Advanced Publishing" specification [1]
* Refactored all places related to the spec changes
* Added unit tests for advanced schema of 'on-xxx' clauses
[1] https://github.com/openstack/mistral-specs/blob/master/specs/pike/approved/advanced_publishing.rst
Change-Id: I190fcec0a40ca6f97d712168f4be7a418bd1f0e8
Partially implements: blueprint mistral-advanced-publishing-global-vars
* The previous name of the package is not relevant anymore, it was
chosen for reasons that don't make sense anymore. A name of the
package should reflect that it's about the workflow language.
Change-Id: I7e05ba97abf0aa5db4e19d9d72b4ea0d52e328fb