* play, block, task: New attribute forks
With this it is possible to limit the number of concurrent task runs.
forks can now be used in play, block and task. If forks is set in different
levels in the chain, then the smallest value will be used for the task.
The attribute has been added to the Base class as a list to easily provide
all the values that have been set in the different levels of the chain.
A warning has been added because of the conflict with run_once. forks will
be ignored in this case.
The forks limitation in StrategyBase._queue_task is not used for the free
strategy.
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
* Handle forks in free strategy
The forks attribute for the free strategy is handled in run in the free
StrategyModule. This is dony by counting the amount of tasks where the uuid
is the same as the current task, that should be queued next. If this amount
is bigger or equal to the forks attribute from the chain (task, block,
play), then it will be skipped to the next host. Like it is also done with
blocked_hosts.
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
* Test cases for forks with linear and free strategy
With ansible_python_interpreter defined in inventory file using
ansible_playbook_python.
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
* Changing forks keyword to throttle and adding some more docs
* remove support from Windows pages, add Windows Server 2019
* jborean feedback
* Removed CBT info
Removed the CBT note about what transports Ansible actually supports. We've worked with both NTLM and Kerberos for a while now.
* Fix notifying handlers by using an exact match rather than a string subset if listen is text rather than a list
* Enforce better type checking for listeners
* Share code for validating handler listeners
* Add test for handlers without names
* Add test for templating in handlers
* Add test for include_role
* Add a couple notes about 'listen' for handlers
* changelog
* Add a test for handlers without names
* Test templating in handlers
* changelog
* Add some tests for include_role
* Add a couple notes about 'listen' for handlers
* make more sense
* move local function into a class method
* Update playbooks_strategies.rst
##### SUMMARY
This page is very confusing and may suggest, that there is still a `serial` strategy (like it used to), but now it is just a directive of `linear` strategy. Multiple people reported this to me and it needs change.
##### ISSUE TYPE
- Docs Pull Request
+label: docsite_pr
* Update docs/docsite/rst/user_guide/playbooks_strategies.rst
Co-Authored-By: Sam Doran <sdoran@redhat.com>
* Update docs/docsite/rst/user_guide/playbooks_strategies.rst
Co-Authored-By: Sam Doran <sdoran@redhat.com>
* Updates strategies page more broadly
* incorporate samdoran feedback
* fixes broken link
* new page title, focus on user intent
* more sdoran feedback
* adds details on setting the number of forks
* Remove lexers which have been fixed in Pygments 2.4.0.
* Add Pygments >= 2.4.0 to test runner.
* Fix pages that triggered lexer errors.
Co-Authored-By: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>
* Updated the section under "Aborting the play"
Updated "Aborting the play" section in the Error Handling In Playbooks page. Removed the reference to marking all hosts as failed.
+label: docsite_pr
* Update docs/docsite/rst/user_guide/playbooks_error_handling.rst
Co-Authored-By: Sandra McCann <samccann@redhat.com>
* Add a few examples of how to correctly use `regex_replace` filter
because it behaves differently on different Python versions when using
regex qualifiers that can match an empty string (e.g. '*', '?', etc).
Often when I am helping others learn Ansible, they are using nodes spun up on Amazon/Google/etc. where private key files (pem) are needed. Mentioning just a bit more on how to handle those private key files on the intro_getting_started page will help more folks get started faster.
I even reviewed the changes with my learning team and they all agreed this helped clarify immediately for them how to really get started with Ansible from a practical perspective.