Is it possible to SKIP task programmatically? Using callback module?
131 views
Skip to first unread message
Luke C
Nov 2, 2020, 7:49:32 AM11/2/20
to Ansible Project
Hey guys
I would like to ask whether it's possible to SKIP task programmatically, using python & callback module?
I've been trying to do this for 3 days and I still don't know how.
Is there some special variable which I could use in v2_runner_on_start or v2_playbook_on_task_start methods?
I don't want to use ansible's when condition, task should be omitted dynamically basing on the results gathered earlier.
e.g.:
def v2_runner_on_start(self, host, task):
if self.checksomething():
print("Task should be omitted")
<OMIT TASK, DO NOT RUN IT>
else:
print("Yes, task should be executed, proceed")
print("Task should be omitted")
<OMIT TASK, DO NOT RUN IT>
else:
print("Yes, task should be executed, proceed")
Stefan Hornburg (Racke)
Nov 2, 2020, 7:57:43 AM11/2/20
to ansible...@googlegroups.com
On 11/2/20 1:49 PM, Luke C wrote:
> Hey guys
>
> I would like to ask whether it's possible to SKIP task programmatically, using python & callback module?
>
> I've been trying to do this for 3 days and I still don't know how.
> Is there some special variable which I could use in *v2_runner_on_start *or *v2_playbook_on_task_start* methods?
> Hey guys
>
> I would like to ask whether it's possible to SKIP task programmatically, using python & callback module?
>
> I've been trying to do this for 3 days and I still don't know how.
>
> I don't want to use ansible's when condition, task should be omitted dynamically basing on the results gathered earlier.
>
> e.g.:
> def v2_runner_on_start(self, host, task):
> if self.checksomething():
> print("Task should be omitted")
> <OMIT TASK, DO NOT RUN IT>
> else:
> print("Yes, task should be executed, proceed")
>
>
Do you know that Ansible's when conditions can be very well based on results gathered earlier?
> I don't want to use ansible's when condition, task should be omitted dynamically basing on the results gathered earlier.
>
> e.g.:
> def v2_runner_on_start(self, host, task):
> if self.checksomething():
> print("Task should be omitted")
> <OMIT TASK, DO NOT RUN IT>
> else:
> print("Yes, task should be executed, proceed")
>
>
Regards
Racke
>
>
> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> ansible-proje...@googlegroups.com <mailto:ansible-proje...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/34e2ed5a-2fad-40cf-a852-f94af07fd096n%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/34e2ed5a-2fad-40cf-a852-f94af07fd096n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.
Luke C
Nov 2, 2020, 8:08:26 AM11/2/20
to Ansible Project
Thanks for the reply.
Yes I know ... :)
The problem is that I want to have dynamic when conditions for huge amount of tasks.
With standard when condition I would have to provide a particular static condition for each task (which in fact are mostly external script executions).
I thought it would be just easier and faster with additional callback module.
Kind regards
Luke
Stefan Hornburg (Racke)
Nov 2, 2020, 8:20:02 AM11/2/20
to ansible...@googlegroups.com
On 11/2/20 2:08 PM, Luke C wrote:
> Thanks for the reply.
> Yes I know ... :)
>
> The problem is that I want to have dynamic when conditions for huge amount of tasks.
> With standard when condition I would have to provide a particular static condition for each task (which in fact are
> mostly external script executions).
> I thought it would be just easier and faster with additional callback module.
>
> Kind regards
> Luke
Can you give an example? Speed is probably not the issue with the when conditions if they rely on external scripts.
> Thanks for the reply.
> Yes I know ... :)
>
> The problem is that I want to have dynamic when conditions for huge amount of tasks.
> With standard when condition I would have to provide a particular static condition for each task (which in fact are
> mostly external script executions).
> I thought it would be just easier and faster with additional callback module.
>
> Kind regards
> Luke
Regards
Racke
> <https://groups.google.com/d/msgid/ansible-project/34e2ed5a-2fad-40cf-a852-f94af07fd096n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
>
> --
> Ecommerce and Linux consulting + Perl and web application programming.
> Debian and Sympa administration. Provisioning with Ansible.
>
>
>
>
> --
> Ecommerce and Linux consulting + Perl and web application programming.
> Debian and Sympa administration. Provisioning with Ansible.
>
> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> ansible-proje...@googlegroups.com <mailto:ansible-proje...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/f1b9d8c6-f367-4c75-b812-226a4eb7b82bn%40googlegroups.com
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> ansible-proje...@googlegroups.com <mailto:ansible-proje...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/ansible-project/f1b9d8c6-f367-4c75-b812-226a4eb7b82bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Mauricio Tavares
Nov 2, 2020, 8:40:14 AM11/2/20
to ansible...@googlegroups.com
On Mon, Nov 2, 2020 at 8:08 AM Luke C <lukash...@gmail.com> wrote:
>
> Thanks for the reply.
> Yes I know ... :)
>
> The problem is that I want to have dynamic when conditions for huge amount of tasks.
> With standard when condition I would have to provide a particular static condition for each task (which in fact are mostly external script executions).
> I thought it would be just easier and faster with additional callback module.
>
I too am confused. I use when() to include an entire task file
>
> Thanks for the reply.
> Yes I know ... :)
>
> The problem is that I want to have dynamic when conditions for huge amount of tasks.
> With standard when condition I would have to provide a particular static condition for each task (which in fact are mostly external script executions).
> I thought it would be just easier and faster with additional callback module.
>
or just do a task. And I could swear I have whens that looked like
when:
- variable-I-populated-or-registered-a-few-lines-ago.stdout ==
variable-I-populated-in-an-earlier-task-file-on-my-way-here.stdout
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f1b9d8c6-f367-4c75-b812-226a4eb7b82bn%40googlegroups.com.
Luke C
Nov 2, 2020, 9:30:33 AM11/2/20
to Ansible Project
All right, so I created a callback plugin which saves information automatically about each executed task to external database, to put it concisely it holds of lots of information about task execution (output, hostname etc) + other needed by users.
For each task unique identifier (not Anisble TASKUUID) is also generated - it is a combination of few fields.
That Custom UUID is being saved to that database as well.
The idea is to not execute any tasks in that playbook(s) more than once, for this purpose Custom UUID should be checked. Tasks shouldn't be executed more than once on a server because of irreversible actions done by those external legacy scripts. (no comments on that, can't be changed for now)
With when condition it would be problematic to check Custom_UUID for each task because it's not and can't be hardcoded (can differ).
So, my first thought was to create or rather enhance my callback plugin to GET data from DB to check whether this particular task has been already executed or not.
If yes, it should be omitted.
Stefan Hornburg (Racke)
Nov 2, 2020, 9:50:09 AM11/2/20
to ansible...@googlegroups.com
On 11/2/20 3:30 PM, Luke C wrote:
> All right, so I created a callback plugin which saves information automatically about each executed task to external
> database, to put it concisely it holds of lots of information about task execution (output, hostname etc) + other needed
> by users.
> For each task unique identifier (not Anisble TASKUUID) is also generated - it is a combination of few fields.
> That Custom UUID is being saved to that database as well.
>
> The idea is to not execute any tasks in that playbook(s) more than once, for this purpose Custom UUID should be checked.
> Tasks shouldn't be executed more than once on a server because of irreversible actions done by those external legacy
> scripts. (no comments on that, can't be changed for now)
>
> With when condition it would be problematic to check Custom_UUID for each task because it's not and can't be hardcoded
> (can differ).
> So, my first thought was to create or rather enhance my callback plugin to GET data from DB to check whether this
> particular task has been already executed or not.
> If yes, it should be omitted.
>
I'm not sure if your setup really makes sense ... it has a smell of overengineering. Ansible is suppose to at least
> All right, so I created a callback plugin which saves information automatically about each executed task to external
> database, to put it concisely it holds of lots of information about task execution (output, hostname etc) + other needed
> by users.
> For each task unique identifier (not Anisble TASKUUID) is also generated - it is a combination of few fields.
> That Custom UUID is being saved to that database as well.
>
> The idea is to not execute any tasks in that playbook(s) more than once, for this purpose Custom UUID should be checked.
> Tasks shouldn't be executed more than once on a server because of irreversible actions done by those external legacy
> scripts. (no comments on that, can't be changed for now)
>
> With when condition it would be problematic to check Custom_UUID for each task because it's not and can't be hardcoded
> (can differ).
> So, my first thought was to create or rather enhance my callback plugin to GET data from DB to check whether this
> particular task has been already executed or not.
> If yes, it should be omitted.
>
go through the tasks to ensure that to ascertain that the desired status has been reached.
Regards
Racke
> <https://groups.google.com/d/msgid/ansible-project/34e2ed5a-2fad-40cf-a852-f94af07fd096n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> >>
> >>
> >> --
> >> Ecommerce and Linux consulting + Perl and web application programming.
> >> Debian and Sympa administration. Provisioning with Ansible.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/f1b9d8c6-f367-4c75-b812-226a4eb7b82bn%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/f1b9d8c6-f367-4c75-b812-226a4eb7b82bn%40googlegroups.com>.
>
> >>
> >>
> >> --
> >> Ecommerce and Linux consulting + Perl and web application programming.
> >> Debian and Sympa administration. Provisioning with Ansible.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/f1b9d8c6-f367-4c75-b812-226a4eb7b82bn%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> ansible-proje...@googlegroups.com <mailto:ansible-proje...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/da81770a-1ca3-4211-8f4b-98184d55a404n%40googlegroups.com
> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> ansible-proje...@googlegroups.com <mailto:ansible-proje...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/ansible-project/da81770a-1ca3-4211-8f4b-98184d55a404n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Luke C
Nov 2, 2020, 10:15:26 AM11/2/20
to Ansible Project
Yes, that's true and I am aware of that. However, just like I said I though it would be quick and easy :)
Dan Linder
Nov 2, 2020, 5:27:37 PM11/2/20
to Ansible Project
What I've done for cases like this is use "when:" blocks on an include to pull in (or not) additional tasks.
From the 'include:' module:
```
- name: Include task list in play only if the condition is true
include: "{{ hostvar }}.yaml"
static: no
when: hostvar is defined
include: "{{ hostvar }}.yaml"
static: no
when: hostvar is defined
```
Or if you don't have them broken out well, you can use Ansible blocks with "when:" conditionals as shown in the block documentation.
I'm kind of an Ansible purist, so you mention of the callback updating/querying a database raised concerns.
Brian Coca
Nov 3, 2020, 10:39:37 AM11/3/20
to Ansible Project
short answer to subject: no, callbacks cannot influence play flow
As for your particular case i would argue that most modules are
designed to prevent doing the same action x2 on the target machines,
if using shell/command look at creates/removes checks on sideeffects.
I don't think this is something you want to build into the controller
but into each action as it is sometimes too hard for the controller to
verify such things.
For example, if the task succeeds but then the update to your database
fails, you will re-execute the task, while if the action itself
verifies 'do i need to execute' by examining the expected state, you
are always safe to run the play no matter what. What you are
attempting to do goes against the design of Ansible itself and it's
actions, so i expect it to be full of problems going forward.
jic you still insist on this direction, here are some tips:
possible solution: strategy plugin, these are the plugins designed to
control play/task flow.
other info: tasks already have a uuid but it is generated on task
definition, which might mean you will see it more than one time,
example: execute same role x2 (task definitions are the same).
--
----------
Brian Coca
As for your particular case i would argue that most modules are
designed to prevent doing the same action x2 on the target machines,
if using shell/command look at creates/removes checks on sideeffects.
I don't think this is something you want to build into the controller
but into each action as it is sometimes too hard for the controller to
verify such things.
For example, if the task succeeds but then the update to your database
fails, you will re-execute the task, while if the action itself
verifies 'do i need to execute' by examining the expected state, you
are always safe to run the play no matter what. What you are
attempting to do goes against the design of Ansible itself and it's
actions, so i expect it to be full of problems going forward.
jic you still insist on this direction, here are some tips:
possible solution: strategy plugin, these are the plugins designed to
control play/task flow.
other info: tasks already have a uuid but it is generated on task
definition, which might mean you will see it more than one time,
example: execute same role x2 (task definitions are the same).
--
----------
Brian Coca
Reply all
Reply to author
Forward
0 new messages