Issue 1:
Sorry if this is a repeat/duplicate/similar, there are tons of issues when using limit as the search term.

ISSUE TYPE

Feature Idea

COMPONENT NAME

limit

ANSIBLE VERSION

ansible-playbook 2.4.0.0
config file =
configured module search path = [u'/Users/lynchg/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /Users/lynchg/.virtualenvs/a2x/lib/python2.7/site-packages/ansible
executable location = /Users/lynchg/.virtualenvs/a2x/bin/ansible-playbook
python version = 2.7.13 (default, Dec 18 2016, 07:03:34) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]

CONFIGURATION

NA

OS / ENVIRONMENT

NA

SUMMARY

While it is possible to do delegate_facts with with_items to handle --limit being used, this has a very high performance impact, because it is single forked. So ideal option would be to add a play key, and exposed variable that can be used - so then limit would work similar to batch/serial.

STEPS TO REPRODUCE

NA

EXPECTED RESULTS

It should be possible to do e.g.

ansible-playbook webservers.yml -l 'foo.example.com'

- hosts: dbservers
limit: []
gather_facts: True

- hosts: webservers
limit: "{{ ansible_play_limit|default([]) }}"
tasks:
...

This would also align with the recent changes to expose ansible_play_hosts and ansible_play_batch

The logic I see working would be something similar to the pattern webservers:&limit, i.e. only hosts that are in the play group and are in the limit.

ACTUAL RESULTS

It's currently necessary to completely ignore the --limit functionality and use a workaround of targets, e.g.

ansible-playbook webservers.yml -e 'target=foo.example.com'

- hosts: dbservers
gather_facts: True

- hosts: "{{ target|default('webservers') }}"
tasks:
...

While this is nearly as easy, it can be confusing to people new to ansible, but ultimately it also makes --limit basically useless.

Issue 2:
Issue Type:

Bug Report

Ansible Version:

ansible 2.0.1.0
config file = /home/etienne/repo/ansible.cfg
configured module search path = Default w/o overrides

Ansible Configuration:

$ cat /home/etienne/repo/ansible.cfg
[defaults]
hostfile = /home/etienne/repo/config/inventory
display_skipped_hosts = False
nocows=1
vault_password_file = ./config/toto

[ssh_connection]
ssh_args = -F ./config/ssh_config -o ControlMaster=auto -o ControlPersist=60s

Environment:

Running from an up-to-date Archlinux

Managing a grape of LXC containers running Debian Wheezy inside Debian Wheezy hosts.

Summary:

Until ansible 2.0, I used to maintain a "global" handlers file, which contains very generic handlers like apache restart, monit restart etc. used in several of my roles. This file is not stored in any role, but "included" in my various playbooks. It used to work.

Since ansible 2.0, handlers are silently ignored. I think it is somehow related to #13507

Steps To Reproduce:

$ cd repo
$ cat roles/backjob/tasks/main.yml

---
- template: src=delayed_jobs_monit.j2
dest=/etc/monit/monitrc.d/delayed_jobs_toto
notify:
- Restart monit
tags:
- backjob
- monit
$ cat vendor_specific.yml

---
- hosts: sd-83787-dintec
roles:
- backjob
handlers:
- include: config/handlers.yml
$ cat config/handlers.yml

---
- name: Restart monit
service: name=monit state=restarted
$ ansible-playbook vendor_specific.yml

There is nothing special in the host_vars/sd-83787-dintec.yml file.

Expected Results:

When the template module execution push a new version of the file, the handler Restart monit must be executed.

Actual Results:

The playbook is successfully ran, but handler is silently ignored: nothing related to handler is output, even with -vvvv

However, if I directly add the handler in the playbook:

$ cat vendor_specific.yml

---
- hosts: sd-83787-dintec
roles:
- backjob
handlers:
- name: Restart monit
service: name=monit state=restarted
#- include: config/handlers.yml

handler is ran as expected.