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] > <mailto:[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] >> <mailto:[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] >> <mailto:[email protected]>. >> To post to this group, send email to >> [email protected] >> <mailto:[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] > <mailto:[email protected]>. > To post to this group, send email to > [email protected] > <mailto:[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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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 > <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/53AD840F.4080807%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
