"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, 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. 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. 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 > <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]. > 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 > <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]. 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.
