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 <[email protected]> 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 >> <[email protected]> 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]> 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]. >>> 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/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 [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/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 [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/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 > [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. -- 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/CA%2BSnNS-Exrj%2B0akAOXycZKrdauXvej4uK4wZKRkoHTz0SMLLEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
