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 <
> [email protected] <javascript:>> 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 <
>> [email protected] <javascript:>> 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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxzeKsOvRPMMvbuaV72Cevm0-Nec0VFQedWLjBBU_UXNQ%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxzeKsOvRPMMvbuaV72Cevm0-Nec0VFQedWLjBBU_UXNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>
>>
>>
>> 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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/53AD22F8.5080101%40yahoo.gr
>>
>> <https://groups.google.com/d/msgid/ansible-project/53AD22F8.5080101%40yahoo.gr?utm_medium=email&utm_source=footer>.
>>
>>
>>
>> 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 [email protected] <javascript:>.
> To post to this group, send email to [email protected]
> <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgz%3DH1zun_xfbFCU0buvAzSQVDSm8a6hwxsLRCh8AH3cug%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgz%3DH1zun_xfbFCU0buvAzSQVDSm8a6hwxsLRCh8AH3cug%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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 [email protected].
To post to this group, send email to [email protected].
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.
