ceilometer api and client have been deprecated for over
two releases and now removed completely. Lets drop these
actions and update the requirements.
Change-Id: Ica2b835a885b9b4705996f91080afc12587bd314
This commit adds docs and reno for migrating policies
into code [1].
Like oslo.config, with oslo.policy, we can define all of
default rules in code base and only change some rules
via policy file. Another thing that we should use yaml
format instead of json format.
[1] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
Co-authored-By: Dai Dang-Van <daidv@vn.fujitsu.com>
Change-Id: I67984292022e2a92306b268a40861cff625c22c9
This is a new and simplified version of the json_pp function. It uses on
the standard jsonutils formatting and wont output the context if not
argument is provided.
Change-Id: I37f69d14e7cf4f57b910b355d7ccd31c9cd73d10
Sometimes you'll get a string back from some action (like swift
get_object) and it will be in either a yaml or json format. These
functions will allow you to parse those into a useful object.
Change-Id: I375219f4b019319e1b3d756dca512f7f90cd097f
Currently we can only do a CURD action on a cron-trigger by name.
This patch refer to workflow implementation and re-encapsulate
DB API so that users can manage a cron-trigger by id or name.
Closes-Bug: 1684469
Change-Id: I9ff657b2604647e734b5539e9bd6a524a3a20efb
Update the Mistral docker image and tooling has been updated to
significantly ease the starting of a Mistral cluster. The setup
now supports all-in-one and multi-container deployments. Also,
the scripts were cleaned up and aligned with the Docker best
practice.
Change-Id: I803d69ee17e7f5ebc95ec2c81887c4f580d73715
AdHoc actions can be defined using YAQL and Jinja2 expressions in the
same way as Tasks, but they could not access the associated context
data because the context was not available when the expression is
evaluated. This patchset passes the task and workflow context into
the AdHocAction object so that the inputs can be evaluated using the
available context, and the context data will be available for
reference.
Added a test to verify that the env() works in AdHoc Actions.
Change-Id: Ib95604d3d494a443e852bc7f5eee24f398b1648c
Closes-Bug: 1690158
Release note and command line parameter added.
From now it is optional to list openstack modules in mapping file which
you would not include into supported action set.
Change-Id: I5ab01395c507fc857dca7cf08ab344a07def0dcf
https://review.openstack.org/#/c/383617/ updates the retry policy
and is a huge change for some of the workflows. Hence, adding a
releasenote.
Change-Id: I86d88d80c3fbcba098d41671f3131f68d10fac03
Due to how microversioning works in the Ironic client, it is not possible
to use API features introduced in API version 1.10 and later from Mistral,
as the default version is 1.9 (mid-Liberty). This change bumps the required
API version to 1.22 (Newton final).
See the following link for the full API version history:
http://docs.openstack.org/developer/ironic/dev/webapi-version-history.html
Change-Id: I1c605fc00efe5fe8956d6547ea5e85e6e1172c9b
User now could define the region for the openstack actions.
It could be done via API in X-Region-Name and X-Target-Region-Name
in case of multi-vim feature is used.
*API change*
X-Region-Name: Header added to execution create
X-Target-Region-Name: Header added to execution create
Change-Id: Icbf63962a481c1282b95359894fa6245e0e97bac
Related-Bug: #1633345
Add an API that gets an ad-hoc action DSL and validates it.
This is done in the same way workflows are validated today.
Change-Id: Ibbb949ef38befae1ef83a2a56cda4c817ceb41d4
Implements: blueprint validate-ad-hoc-action-api
- New service actions support, remove the separated ones.
- Workflow sharing feature.
- Usage of workflow UUID.
Change-Id: Ia082fc0b70dbad62e1224e8ebe252677d5372c3a
Release note has been added for pre-installed
mistral docker image.
Change-Id: Iaaeb381e515c0ed8cd45efad245dde257731ce05
Partially-implements: blueprint mistral-docker-image
The state of a workflow execution was not updated even when all task
executions were completed if some tasks finished at the same time as
other tasks.
Because we were using our connections with transaction isolation
level = REPEATABLE_READ - Each process was using a snapshot of the DB
created at the first read statement in that transaction.
When a task finished and evaluated the state of all the other tasks
it did not see the up-to-date state of those tasks - and so, because
not all tasks were completed - the task did not change the workflow
execution state.
Similar behavior happened with multiple action executions under same
task. On completion, each action execution checked the status of the
other action executions and did not see the up-to-date state of these
action execution - causing task execution to stay in RUNNING state.
Change-Id: I12f66134d92b8ed39df9d6128d7de5ee49aa8623
Closes-Bug: #1518012
Closes-Bug: #1513456