FAQ
Or is this a role for include + with_items that will be available in 2.0?

Regards,
Daniel

On 17 April 2015 at 15:08, Daniel Siechniewicz wrote:
Hi,

Sorry to reanimate this, but I think I have a "legit" use case for looping
over multiple tasks:

This is what I've got:

- name: install cq packages
local_action: cqpkg name={{ item.pkg }}
path={{ item.file }}
state=present
admin_user={{ admin_user }}
admin_password={{ admin_pass }}
host={{ ansible_eth1.ipv4.address }}
port={{ listen_port }}
with_items: cq_packages

But really I need (pretend syntax of course):

- name: install cq packages
# Install package
- local_action: cqpkg name={{ item.pkg }}
path={{ item.file }}
state=present
admin_user={{ admin_user }}
admin_password={{ admin_pass }}
host={{ ansible_eth1.ipv4.address }}
port={{ listen_port }}
# Restart service if package requires it to be done immediately
- service: name={{ service_name }} enabled=yes state=started
when: {{ item.cqrestart }} == immediate
# Wait for the port to come up (this can happen a while after restart)
- wait_for: port={{ listen_port }} delay=1
# Wait for the darned thing to come back, and this can take AGES
- shell: "{{ aem_check }}"
until: result.stdout.find("200 OK") != -1
retries: 180
delay: 10
register: result
changed_when: False
# Rinse, repeat

with_items: cq_packages

Because I'm using an ansible module to do actual installation (cqpkg) doing
it as a script would require some serious rewriting OR doing all the
restarts and waiting and checking within the module. Waiting and checking
I'd be reasonably OK with, but not service restart, to be honest. The
restart cannot be a handler either, because some packages require immediate
restart (application can break beyond recovery if cq is not restarted there
and then). As far as I managed to understand flush_handlers this won't work
in a loop either, not to mention unintended consequences, as it's all or
nothing.

This can, and most likely will be, separated out into a parameterised role,
but it'll force fairly non-intuitive "flow.

This really seems to be a simple example of why loop over multiple tasks
makes sense: I want to install a package, restart a service and wait for
things to settle down before proceeding with installation of next package.

I'll need to come up with a solution pretty much today, so this is just for
general discussion.


Regards,
Daniel


On Friday, June 27, 2014 at 3:47:52 PM UTC+1, Ernest0x wrote:

On 06/27/14 15:42, Michael DeHaan wrote:

"It seems that you are not interested in going that direction with the
excuse that more flexible loops are for programming languages."

These are project directions, not excuses, and we're mincing at words
here.

Just so this isn't misinterpreted, Ansible already provides the ability to
write custom iterators, we have things like "with_nested", "with_sequence",
etc. It already can loop over single tasks quite fine,


This is true about custom iterators, though not all people can write
custom iterators and I have personally witnessed some unjustified negativism
for accepting in core small improvements for available iterators for
everyone's benefit.

So what you are asking about is the ability to loop over more than one set
of tasks - I would not implement this as a "goback" even if we did this, it
would be a higher level language construct, more akin to a block with
control structures. Gotos are a gross construct nearly everywhere we are
found.


To be more specific, I was thinking of a "goback" feature as a very
restricted 'goto'. It would allow to move only backwards and only in the
same play and same file. That way all problems of 'goto' are gone.

That said, now I am thinking of another possible implementation:

- name: Repeat a group of tasks 5 times to warm up my servers
repeat: tags="warmup" times=5

- name: Repeat a group of tasks to warm up my servers until a condition is
true
repeat: tags="warmup" times=0
until: somecondition

By default 'times' would be 1. If times == 0 it would check that an
'until' condition has been set and repeat tagged tasks until that condition
becomes true.


In most cases it's not needed - Modules already take care of most of the
provisioning needs, for instance, "exact_count" on provisioning modules
allow spinning up an arbitrary number of images, and then you can apply
tasks to images using the host loop. Thus we can ALREADY do all of that
cluster spinup, and do that every day.

While looping over multiple tasks in a common loop could be something
Ansible does in the future, we have a lot of more important things to chase
first in the PR queue before we would consider such complexity when so few
things need it. So far the only example we have that we "can't" do is
"warm up group of servers A from load of B until servers A reach threshold
X", which strikes me as very arbitrary.


Other cases:
- Stress testing a group of hosts by repeating a group of tasks X times
- Run a time-dependent port knocking scheme X times to pass through a
firewall
- Run X passes of a series of data-destructive tasks on some disk
containing your secrets

And generally repeating any couple of "run task & check for output" tasks.

We've suggested a simple compromise of generating a set load, and that was
ruled insufficient, or even calling out to a simple script - I see no point
to going on about this infinitely given there are solutions. It's a very
niche scenario and I'm ok with not having a clear way to do *EXACTLY* that,
when there are other ways to achieve the same ends, just not with the
technical criteria stated about exactly how it should be implemented.

As long as there's one possible way, that's enough for me - we don't have
to implement exactly this proposed way, especially when we think it would
reduce the readability of the Ansible playbook language and encourage more
complicated playbooks when Ansible's goal is encouraging simplicity and
elegant playbook design.







On Fri, Jun 27, 2014 at 3:53 AM, 'Petros Moisiadis' via Ansible Project
wrote:
On 06/26/2014 10:22 PM, Michael DeHaan wrote:




On Thu, Jun 26, 2014 at 3:10 PM, 'Petros Moisiadis' via Ansible Project
wrote:
On 06/26/14 21:06, Michael DeHaan wrote:

"Ansible can do this kind of loops, but only for a single task. It does
not offer a way to repeat a number of different tasks as a group."

Agreed, we really aren't trying to create a programming language.


When a need to support a common task execution scenario arises and
Ansible cannot handle it, I consider it a limitation. We are not trying to
create a programming language, but we are all using Ansible to script task
execution scenarios. I expect to be able to tell my machines "repeat that
group of tasks until something becomes ready or reaches some limit". This
is speaking to my machines and telling them what to do, it's not
programming. I think Ansible can be improved on that aspect.


I think you're picking at words a bit - it's programming computers to do
things. There are going to be cases where something like the script module
are going to apply.

Having ansible evolve entirely into a general purpose programming
language would make a very very bad programming language.

I'm ok if that's something we can't do, because it's going to be
impossible to do /everything/.

Ansible is already more flexible than any other config system out there,
because it's more stepwise, versus compiled-model based (even the coded ones
use DSLs still compile down).


Ansible is powerful as a configuration system for bringing systems in a
desired state and flexible for deploying software, but it could be more
flexible as a task execution engine for things such as feedback-based
repeated execution and bootstrapping of custom clustering environments (not
using ready-made amazon's or google's or rackspace's cloud engine
products/services) based on complex nested data. This flexibility could come
from increasing flexibility in creating task loops.

It seems that you are not interested in going that direction with the
excuse that more flexible loops are for programming languages. However, the
fact that programming languages are very flexible in creating loops does not
mean that other languages/systems (including Ansible) will automatically
turn into programming languages if they become more flexible in that. Loops
are natural. They are a very basic concept. They are everywhere in life, not
only in programming, and people start learning about and using them from the
very beginning. We have all played "Snakes and Ladders" as kids, which is
exactly a loop of repeating steps until you reach a goal. So, having a
'goback' feature, for example, would be like being swallowed by a snake and
going to repeat your previous steps :D. Nothing to worry about programming
languages and other monsters...

--
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 post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxzeKsOvRPMMvbuaV72Cevm0-Nec0VFQedWLjBBU_UXNQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/53AD22F8.5080101%40yahoo.gr.

For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgz%3DH1zun_xfbFCU0buvAzSQVDSm8a6hwxsLRCh8AH3cug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ansible-project/tisr0c8eovc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/8cc731d9-bbc6-49b4-97c6-4afd568c1939%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BSnNS-Exrj%2B0akAOXycZKrdauXvej4uK4wZKRkoHTz0SMLLEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
groupansible-project @
postedApr 17, '15 at 2:09p
activeApr 17, '15 at 2:37p
posts3
users2

2 users in discussion

Daniel Siechniewicz: 2 posts Brian Coca: 1 post

People

Translate

site design / logo © 2021 Grokbase