Issue 1:
Issue Type:

Feature Idea

Ansible Version:

ansible 1.8 (or greater)

Environment:

N/A

Summary:

A special tag all matching all possible tags might make working with tags easier and less error-prone.

Motivation:

It's useful to organize larger playbooks by assigning tags to tasks. This allows to run only a subset of a playbook's tasks.

However, in some cases it might make sense to always run a task. Controlling monitoring comes to mind:

- nagios: action=downtime minutes=10 service=some_service host=some.host
tags:
- foo
- bar

- command: /usr/bin/foo
tags: foo

- command: /usr/bin/bar
tags: bar

If later on a new task with tag baz is introduced into this playbook, baz has to be added to the tags of the nagios task as well.

This is no problem in small playbooks, but once several roles are used in combination with pre_tasks/post_tasks, keeping track of all tags involved may become cumbersome.

Rationale:

The current system requires a certain amount of bookkeeping, often spanning several different files, in order to achieve something that can be explained easily in natural language: "make sure this task always runs"

If this bookkeeping is not kept up, when calling ansible-playbook with the --tags option, running playbooks might fail (because some essential initial task did not run), or unwanted side effects may occur (monitoring alerts because no downtime was scheduled for example)

For these cases it might make sense to have a special tag matching every possible tag (therefore meaning "all tags") instead of listing all those tags explicitly.

There is a tag that currently makes no sense to assign to any task: the tag all.

This is because all has a special meaning for ansible-playbook: rather than "execute only tasks with a tag called all", providing --tags all (the default) to ansible-playbook means "execute all tasks".

In other words, a task tagged (only) with all is run under the exact same conditions as an untagged task.

There seems currently no reason whatsoever to tag a task with all, and it is to be expected that not many (if any) existing playbooks do this. If there are playbooks out there doing so, they can be converted into equivalent playbooks by simply omitting the all tag in it's current form.

Proposal:

If the currently meaningless tag all were to gain the semantic "match every possible tag" the abovementioned difficulties could be tackled easily and without losing much (if anything).

The monitoring example from above would then look like this:

- nagios: action=downtime minutes=10 service=some_service host=some.host
tags: all

- command: /usr/bin/foo
tags: foo

- command: /usr/bin/bar
tags: bar

Adding a task tagged baz later on does not require any changes whatsoever to the nagios task.

The name all should hint to the fact that all tags are meant.

And finally, this would also mirror the host group all which in turn includes every possible host.

Related:

Issue #9010 seems to discuss things that might overlap with this proposal.

Issue 2:
Issue Type:

Bug Report

Ansible Version:

ansible devel, commit f488de8

Ansible Configuration:

no changes

Environment:

ansible on Mac OS X 10.11.1

managing docker container with CentOS 6 (docker image "centos:centos6")

Summary:

Running ansible-playbook, a task executing on "docker" connection makes ansible-playbook process hang. The issue occurs since commit f488de8.

Steps To Reproduce:

I created a bash script to reproduce this issue:

#!/bin/bash

# start docker container
CONTAINER_ID="$(docker run -d -t -h testhost centos:centos6)"

# create ansible inventory
echo "testhost ansible_connection=docker ansible_host=${CONTAINER_ID}" > inventory

# create ansible playbook
echo "- hosts: testhost" > playbook.yml
echo " tasks:" >> playbook.yml
echo " - name: host is reachable" >> playbook.yml
echo " ping:" >> playbook.yml

# run ansible playbook
ansible-playbook -i inventory playbook.yml

# remove docker container
docker rm -f "${CONTAINER_ID}"

This fails since commit f488de8.

Expected Results:

Run the minimal playbook without hanging indefinitely.

Actual Results:

Minimal playbook hangs indefinitely.