Name space collision for the `state` default variable?

[ringods]

I have an Ansible role in which I include your role a number of times to have long running containers on a dedicated machine. I developed everything against Vagrant + the Ansible provisioner. Everything works like a charm.

Then came the time I had to roll it out on the AWS EC2 production machine. Bam, it broke on setting up the first docker systemd service with this error (when running Ansible with -vvv):

fatal: [10.130.20.211]: FAILED! => {
    "changed": false,
    "invocation": {
        "module_args": {
            "daemon_reload": true,
            "enabled": true,
            "masked": false,
            "name": "elasticsearch_container.service",
            "no_block": false,
            "state": "{'code': 16, 'name': 'running'}",
            "user": false
        }
    },
    "msg": "value of state must be one of: reloaded, restarted, started, stopped, got: {'code': 16, 'name': 'running'}"
}

So the given state became {'code': 16, 'name': 'running'}. Googling this type of message structure always directs me to the boto Python AWS SDK library. While not really knowing how Ansible internals work, my assumption is that something of the boto usage leaks down in the namespace of the Ansible role variables. The value given above could easily be the state of the VM being checked first.

To test this, I renamed the default variable state in this role to service_state and updated the usages in install.yml. Executed my playbook again and with good results.

As I don't know Ansible well enough, I first created this ticket here. It might be the case that this is a valid case of Variable Precedence, but it might be that this collision is a core Ansible bug. In this case, I hope we can work together in the investigation before we file a bug in the Ansible core project.

[mhutter]

Hi @ringods, thank you for reporting this issue!

This is very interesting indeed! According to the Variable Precedence docs, there is almost nothing that should overwrite vars set on an include_role.

Can you provide me some details about the Ansible version you use? Am I correct when I assume you use the ec2_... module in Ansible to set up your infrastructure?

I'll check if there is another solution to this. In hindsight it would have been much more sensible to prefix all variable names, but now this would be a breaking change...

[ringods]

@mhutter,

Until yesterday noon, I ran Ansible 2.5.4. One of the things I tried to resolve or workaround this issue was upgrading to v2.6.1. So both versions had this problem.

I did not use ec2_... modules to setup the infrastructure. I am using Terraform for this. But I do use the aws_ec2 inventory plugin introduced in Ansible 2.5. This is where boto comes into the picture.

Here is my inventory config file:

plugin: aws_ec2
regions: # populate inventory with instances in these regions
  - us-east-1
filters:
  tag:Environment: development
# ignores 403 errors rather than failing
strict_permissions: False
hostnames:
  - private-ip-address
strict: False
# keyed_groups may be used to create custom groups
keyed_groups:
  - key: tags.Role
    separator: ''
  - key: tags.Service
    separator: ''

Via this method, I map the hosts from my playbook to dynamically created EC2 instances.

Note: you can test this inventory file by running:

$ ansible-inventory --list --inventory development.aws_ec2.yml > aws_hosts.json

Don't forget to set the valid AWS_... credentials as environment variables first.

[mhutter]

Okay, one more question: When you use the docker-systemd-service role in your role, do you explicitly set the state variable, or is the default value used?

If you rely on the default value, can you try explicitly set it to started? Having another look at variable precedence I noticed that role defaults have the lowest priority possible, so they get overwritten by everything... :-(

[mhutter]

@ringods can you give the code in #3 a try?

[ringods]

@mhutter see comments in the PR.