From 378a6207337f8a3003025232024cd97373a2f01c Mon Sep 17 00:00:00 2001 From: Chris Meyers Date: Thu, 19 Jan 2017 11:10:16 -0500 Subject: [PATCH 1/5] add acceptance docs for set_stats --- docs/workflow.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/workflow.md b/docs/workflow.md index dee731264d..45856ec706 100644 --- a/docs/workflow.md +++ b/docs/workflow.md @@ -53,6 +53,9 @@ Workflow job templates can be copied by POSTing to endpoint `/workflow_job_templ Workflow jobs cannot be copied directly, instead a workflow job is implicitly copied when it needs to relaunch. Relaunching an existing workflow job is done by POSTing to endpoint `/workflow_jobs/\d+/relaunch/`. What happens next is the original workflow job is copied to create a new workflow job. The new workflow job then gets a copy of all nodes of the original as well as the topology they bear. Finally the full-fledged new workflow job is triggered to run, thus fulfilling the purpose of relaunch. Survey password-type answers should also be redacted in the relaunched version of the workflow job. +### Artifacts +Artifact support starts in Ansible and is carried through in Tower. Tower artifact support starts in Ansible with the `set_stats` module. The `set_stats` module is invoked by users to register or facts, passed in under the `data:` argument. Note that the default `set_stats` parameters are the correct ones to work with Tower (i.e. `per_host: no`). Now that facts are registered, we will describe how facts are used. In Ansible, registered facts are "returned" to the callback plugin(s) via the `playbook_on_stats` event. Ansible users can configure whether or not they wan't the facts displayed through the global `show_custom_stats` configuration. Tower uses a custom callback plugin that gathers the fact data set via `set_stats` in the `playbook_on_stats` handler and "ships" it back to Tower, saves it in the database, and makes it available on the job endpoint via the variable `artifact_data`. The semantics and usage of `artifact_data` throughout a workflow is described elsewhere in this document. + ## Test Coverage ### CRUD-related * Verify that CRUD operations on all workflow resources are working properly. Note workflow job nodes cannot be created or deleted independently, but verifications are needed to make sure when a workflow job is deleted, all its related workflow job nodes are deleted. @@ -71,6 +74,7 @@ Workflow jobs cannot be copied directly, instead a workflow job is implicitly co * Verify that workflow job template nodes are not allowed to have invalid association. Any attempt that causes invalidity will trigger 400-level response. The three types of invalid associations are cycle, convergence(multiple parent) and mutex('always' XOR the rest). * Verify that a workflow job template can be successfully copied and the created workflow job template does not miss any field that should be copied or intentionally modified. * Verify that if a user has no access to any of the related resources of a workflow job template node, that node will not be copied and will have `null` as placeholder. +* Verify that `artifact_data` is populated when `set_stats` is used. ### Task-related * Verify that workflow jobs can be launched by POSTing to endpoint `/workflow_job_templates/\d/launch/`. From 00f94098f5c2b9faec5de123d8f4942fdfd90c0d Mon Sep 17 00:00:00 2001 From: Chris Meyers Date: Thu, 19 Jan 2017 11:58:21 -0500 Subject: [PATCH 2/5] revisions --- docs/workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/workflow.md b/docs/workflow.md index 45856ec706..82e69c470a 100644 --- a/docs/workflow.md +++ b/docs/workflow.md @@ -54,7 +54,7 @@ Workflow job templates can be copied by POSTing to endpoint `/workflow_job_templ Workflow jobs cannot be copied directly, instead a workflow job is implicitly copied when it needs to relaunch. Relaunching an existing workflow job is done by POSTing to endpoint `/workflow_jobs/\d+/relaunch/`. What happens next is the original workflow job is copied to create a new workflow job. The new workflow job then gets a copy of all nodes of the original as well as the topology they bear. Finally the full-fledged new workflow job is triggered to run, thus fulfilling the purpose of relaunch. Survey password-type answers should also be redacted in the relaunched version of the workflow job. ### Artifacts -Artifact support starts in Ansible and is carried through in Tower. Tower artifact support starts in Ansible with the `set_stats` module. The `set_stats` module is invoked by users to register or facts, passed in under the `data:` argument. Note that the default `set_stats` parameters are the correct ones to work with Tower (i.e. `per_host: no`). Now that facts are registered, we will describe how facts are used. In Ansible, registered facts are "returned" to the callback plugin(s) via the `playbook_on_stats` event. Ansible users can configure whether or not they wan't the facts displayed through the global `show_custom_stats` configuration. Tower uses a custom callback plugin that gathers the fact data set via `set_stats` in the `playbook_on_stats` handler and "ships" it back to Tower, saves it in the database, and makes it available on the job endpoint via the variable `artifact_data`. The semantics and usage of `artifact_data` throughout a workflow is described elsewhere in this document. +Artifact support starts in Ansible and is carried through in Tower. The `set_stats` module is invoked by users, in a playbook, to register or facts. Facts are passed in via `data:` argument. Note that the default `set_stats` parameters are the correct ones to work with Tower (i.e. `per_host: no`). Now that facts are registered, we will describe how facts are used. In Ansible, registered facts are "returned" to the callback plugin(s) via the `playbook_on_stats` event. Ansible users can configure whether or not they want the facts displayed through the global `show_custom_stats` configuration. Note that the `show_custom_stats` does not effect the artifacting feature of Tower. This only controlls the displaying of `set_stats` fact data in Ansible output (also the output in Ansible playbooks ran in Tower). Tower uses a custom callback plugin that gathers the fact data set via `set_stats` in the `playbook_on_stats` handler and "ships" it back to Tower, saves it in the database, and makes it available on the job endpoint via the variable `artifacts`. The semantics and usage of `artifacts` throughout a workflow is described elsewhere in this document. ## Test Coverage ### CRUD-related From fcdb0ed2f288ca3e308934e654cbf28f30ce60b6 Mon Sep 17 00:00:00 2001 From: Chris Meyers Date: Thu, 19 Jan 2017 12:05:10 -0500 Subject: [PATCH 3/5] added ansible version note for set_stats --- docs/workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/workflow.md b/docs/workflow.md index 82e69c470a..a97b8dc663 100644 --- a/docs/workflow.md +++ b/docs/workflow.md @@ -74,7 +74,7 @@ Artifact support starts in Ansible and is carried through in Tower. The `set_sta * Verify that workflow job template nodes are not allowed to have invalid association. Any attempt that causes invalidity will trigger 400-level response. The three types of invalid associations are cycle, convergence(multiple parent) and mutex('always' XOR the rest). * Verify that a workflow job template can be successfully copied and the created workflow job template does not miss any field that should be copied or intentionally modified. * Verify that if a user has no access to any of the related resources of a workflow job template node, that node will not be copied and will have `null` as placeholder. -* Verify that `artifact_data` is populated when `set_stats` is used. +* Verify that `artifact_data` is populated when `set_stats` is used in Ansible >= v2.2.1.0-0.3.rc3. ### Task-related * Verify that workflow jobs can be launched by POSTing to endpoint `/workflow_job_templates/\d/launch/`. From e40d637e565410093789bcb826a0e66b4c5a5c2c Mon Sep 17 00:00:00 2001 From: Chris Meyers Date: Thu, 19 Jan 2017 12:05:46 -0500 Subject: [PATCH 4/5] fix --- docs/workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/workflow.md b/docs/workflow.md index a97b8dc663..080313d242 100644 --- a/docs/workflow.md +++ b/docs/workflow.md @@ -74,7 +74,7 @@ Artifact support starts in Ansible and is carried through in Tower. The `set_sta * Verify that workflow job template nodes are not allowed to have invalid association. Any attempt that causes invalidity will trigger 400-level response. The three types of invalid associations are cycle, convergence(multiple parent) and mutex('always' XOR the rest). * Verify that a workflow job template can be successfully copied and the created workflow job template does not miss any field that should be copied or intentionally modified. * Verify that if a user has no access to any of the related resources of a workflow job template node, that node will not be copied and will have `null` as placeholder. -* Verify that `artifact_data` is populated when `set_stats` is used in Ansible >= v2.2.1.0-0.3.rc3. +* Verify that `artifacts` is populated when `set_stats` is used in Ansible >= v2.2.1.0-0.3.rc3. ### Task-related * Verify that workflow jobs can be launched by POSTing to endpoint `/workflow_job_templates/\d/launch/`. From 627203a5ee7fa285e113e5ea11175b0f8de292ba Mon Sep 17 00:00:00 2001 From: Chris Meyers Date: Thu, 19 Jan 2017 12:13:48 -0500 Subject: [PATCH 5/5] spelling things --- docs/workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/workflow.md b/docs/workflow.md index 080313d242..94368fa22a 100644 --- a/docs/workflow.md +++ b/docs/workflow.md @@ -54,7 +54,7 @@ Workflow job templates can be copied by POSTing to endpoint `/workflow_job_templ Workflow jobs cannot be copied directly, instead a workflow job is implicitly copied when it needs to relaunch. Relaunching an existing workflow job is done by POSTing to endpoint `/workflow_jobs/\d+/relaunch/`. What happens next is the original workflow job is copied to create a new workflow job. The new workflow job then gets a copy of all nodes of the original as well as the topology they bear. Finally the full-fledged new workflow job is triggered to run, thus fulfilling the purpose of relaunch. Survey password-type answers should also be redacted in the relaunched version of the workflow job. ### Artifacts -Artifact support starts in Ansible and is carried through in Tower. The `set_stats` module is invoked by users, in a playbook, to register or facts. Facts are passed in via `data:` argument. Note that the default `set_stats` parameters are the correct ones to work with Tower (i.e. `per_host: no`). Now that facts are registered, we will describe how facts are used. In Ansible, registered facts are "returned" to the callback plugin(s) via the `playbook_on_stats` event. Ansible users can configure whether or not they want the facts displayed through the global `show_custom_stats` configuration. Note that the `show_custom_stats` does not effect the artifacting feature of Tower. This only controlls the displaying of `set_stats` fact data in Ansible output (also the output in Ansible playbooks ran in Tower). Tower uses a custom callback plugin that gathers the fact data set via `set_stats` in the `playbook_on_stats` handler and "ships" it back to Tower, saves it in the database, and makes it available on the job endpoint via the variable `artifacts`. The semantics and usage of `artifacts` throughout a workflow is described elsewhere in this document. +Artifact support starts in Ansible and is carried through in Tower. The `set_stats` module is invoked by users, in a playbook, to register facts. Facts are passed in via `data:` argument. Note that the default `set_stats` parameters are the correct ones to work with Tower (i.e. `per_host: no`). Now that facts are registered, we will describe how facts are used. In Ansible, registered facts are "returned" to the callback plugin(s) via the `playbook_on_stats` event. Ansible users can configure whether or not they want the facts displayed through the global `show_custom_stats` configuration. Note that the `show_custom_stats` does not effect the artifacting feature of Tower. This only controls the displaying of `set_stats` fact data in Ansible output (also the output in Ansible playbooks ran in Tower). Tower uses a custom callback plugin that gathers the fact data set via `set_stats` in the `playbook_on_stats` handler and "ships" it back to Tower, saves it in the database, and makes it available on the job endpoint via the variable `artifacts`. The semantics and usage of `artifacts` throughout a workflow is described elsewhere in this document. ## Test Coverage ### CRUD-related