Make a few cleanups:
- Remove obsolete sections from setup.cfg
- Switch to using sphinx-build
- Cleanup doc/source/conf.py to remove now obsolete content.
- Switch to openstackdocstheme version
- Remove install_command from tox.ini, the default is fine
- Fix docs warnings
Change-Id: Icf6a2d4229392e9d38af67567167b60d02d68019
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I42f1d2f325a7ba9785ebf33bbe76497f031d6bb4
Story: #2002586
Task: #24311
Extend the context with custom parameters to make it
generally available for custom actions and support
the separation of OpenStack actions from the core.
Change-Id: If5ea987f3d9d70c288b12f549434f9e8d6853c66
Creating and running workflows within a namespace will allow users to create
many workflows with the same name. This is useful when a user already has many
workflows that are connected to each other implemented and one of the workflow
names is already in use and the user does not want to edit the that workflow
and all the ones referencing it or merge them to a workbook.
blueprint create-and-run-workflows-within-a-namespace
Change-Id: I5a8e6c8761bfe31bf04026083c4755468f580429
* While implementing the previous spec ('Workflow Global Context')
we realized that the proposed language syntax is not enough
flexible and concise. The proposed spec replaces the issues of
the previous spec.
Change-Id: I7bc926698b7be0301919718f6caa854387bab7f6
The idea of policies is to document something related to the project
that isn't tied to a specific release and often isn't related to code.
For example, a policy could be related to how we organise or how we
agree to do code reviews.
This process is inspired by the policies used in TripleO and the policy
template is a direct copy of the one used in TripleO.
Change-Id: I05f5076a1559790bf6d0f7b68d528748a2acd20b
This new function will allow user to get a list of tasks matching certain
filter. For example only task in state ERROR from the current execution.
This will work in both YAQL an Jinja2 expressions.
blueprint yaql-tasks-function
Change-Id: I218ad84770e93a25708ff64ce17e10f08187c6d3
Currently it is not possible to provide any reasonable output in case of a
task or workflow failure. Implementing this would greatly simplify error
handling in workflows.
Change-Id: I2442178a5eb50f5485097a165d9fbe8b2d97c959
Add support for executing workflows on any cloud without having to
reconfigure the Mistral service.
Change-Id: I008dfe88fb0d71262abe419c6a8af4379abc681e
Signed-off-by: Andras Kovi <akovi@nokia.com>
This spec adds support to run Mistral workflows in response to AMPQ events.
This will provide cloud operators the ability to automate their operations
by running workflows in response to specific notification events,
including those emitted by OpenStack.
Change-Id: I345d29b4252d0118a0f63358532df97163f9ac9a
Implements: blueprint event-notification-trigger
Implementation of this spec will allow workflow author to
define meaningful message for fail/success/pause transition.
Change-Id: Ie196763a4a340b8cd92cf552a8a8b4acbc05d0bd
Implements: blueprint mistral-fail-transition-message
This is regarding the use case where a workflow execution failed
because of environment related issues (i.e. endpoint unavailable,
etc.). Endpoints and credentials can be passed on workflow invocation
under the env param and then accessed by workflow tasks using the
env() function. It is possible that the endpoint is replaced (i.e.
different host/ip) as part of resolving the environment related
issues or that the token passed as credential has expired. In these
cases, the user will need to be able to update the env variables
prior to re-run.
Change-Id: Icc8faf990a3cbdb8e969ae4cda56c0d06f11155f
Add structure, unit tests, and template for mistral-specs, creating
a functional specs repository without any approved specs.
Put example.rst in mitaka/approved and mitaka/implemented respectively
to avoid doc build warnings:
"pattern u'specs/mitaka/approved/*' didn't match any documents"
Implements: blueprint mistral-spec-repository
Change-Id: I092ec2f9b1aef9b1bf328658674119eb3cdf3380
Manpreet Kaur