“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.