Deprecation warnings from Ansible if running Ansible 2.4+

[geerlingguy]

Issue Type

• Bug Report

Full console output

[DEPRECATION WARNING]: The use of 'include' for tasks has been deprecated. Use 
'import_tasks' for static inclusions or 'include_tasks' for dynamic inclusions.
 This feature will be removed in a future release. Deprecation warnings can be 
disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: include is kept for backwards compatibility but usage is
 discouraged. The module documentation details page may explain more about this
 rationale.. This feature will be removed in a future release. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: The use of 'static' has been deprecated. Use 
'import_tasks' for static inclusion, or 'include_tasks' for dynamic inclusion. 
This feature will be removed in a future release. Deprecation warnings can be 
disabled by setting deprecation_warnings=False in ansible.cfg.
 [WARNING]: file /Users/jeff.geerling/Dropbox/Development/GitHub/drupal-
vm/provisioning/roles/geerlingguy.apache-php-fpm/tasks/configure-RedHat.yml is
empty and had no tasks to include

Summary

There are a few warnings that occur when running Drupal VM's playbook under Ansible 2.4.0+ (released today):

• [defaults]hostfile option, The key is misleading as it can also be a list of hosts, a directory or a list of paths . This feature will be removed in version 2.8. (This was from my own ansible.cfg file, not Drupal VM's—fix is to switch hostfile to inventory under the [defaults] section in ansible.cfg.)
• The use of 'include' for tasks has been deprecated. Use 'import_tasks' for static inclusions or 'include_tasks' for dynamic inclusions. This feature will be removed in a future release. (same with 'static)
• (And in Ansible 2.5+) [DEPRECATION WARNING]: State 'installed' is deprecated. Using state 'present' instead.. This feature will be removed in version 2.9. Fixed.

It looks like we're hitting a chicken-and-egg issue again (like with 2.0->2.2) where something is deprecated, but if I fix it, then anyone using < 2.4.0 will not be able to run the playbook. So do I force everyone everywhere to upgrade to 2.4.0 now, or do I wait and live with the deprecation warnings... And the inevitable slew of issues people will report saying "Drupal VM is broken, it is scary, make these warnings go away!"

Roles to update for include deprecation

• franklinkim.newrelic (need to submit a PR upstream)
• geerlingguy.varnish
• geerlingguy.apache
• geerlingguy.mysql
• geerlingguy.php
• geerlingguy.postgresql
• geerlingguy.blackfire
• geerlingguy.composer
• geerlingguy.elasticsearch
• geerlingguy.java
• geerlingguy.drupal
• geerlingguy.drush
• geerlingguy.firewall
• geerlingguy.nodejs
• geerlingguy.php-redis
• geerlingguy.php-tideways
• geerlingguy.php-versions
• geerlingguy.php-xhprof
• geerlingguy.redis
• geerlingguy.ruby
• geerlingguy.security

[oxyc]

Auch. Are you considering making 2.4.0 a requirements in all your roles? If not, maybe just hide those deprecation warnings for users running the playbook through Vagrant (meaning travis still logs them at least).

diff --git a/Vagrantfile b/Vagrantfile
index 774121e..bb20d7b 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -29,9 +29,11 @@ vconfig = load_config([

 provisioner = vconfig['force_ansible_local'] ? :ansible_local : vagrant_provisioner
 if provisioner == :ansible
+  ansible_config_file = "#{host_drupalvm_dir}/provisioning/ansible.cfg"
   playbook = "#{host_drupalvm_dir}/provisioning/playbook.yml"
   config_dir = host_config_dir
 else
+  ansible_config_file = "#{guest_drupalvm_dir}/provisioning/ansible.cfg"
   playbook = "#{guest_drupalvm_dir}/provisioning/playbook.yml"
   config_dir = guest_config_dir
 end
@@ -103,6 +105,8 @@ Vagrant.configure('2') do |config|
   end

   config.vm.provision provisioner do |ansible|
+    ansible.config_file = ansible_config_file unless ENV['DRUPALVM_DEBUG']
+    ansible.verbose = ENV['DRUPALVM_DEBUG']
     ansible.playbook = playbook
     ansible.extra_vars = {
       config_dir: config_dir,
diff --git a/provisioning/ansible.cfg b/provisioning/ansible.cfg
index 4b1740e..a43fedc 100644
--- a/provisioning/ansible.cfg
+++ b/provisioning/ansible.cfg
@@ -1,5 +1,6 @@
 [defaults]
 roles_path = ./roles
+deprecation_warnings = False

 [ssh_connection]
 pipelining = True

Then you would enable debug mode with DRUPALVM_DEBUG=1 vagrant provision or verbose ansible output with DRUPALVM_DEBUG=vvv vagrant-provision

[fubarhouse]

So when Ansible 2.8 hits, include will be removed from Ansible.

Is there a task to at least migrate associated tasks and roles to the new standard - so nothing is forgotten?

I know this will impact me quite a lot, though because the new pieces of functionality didn't exist in 2.3, making 2.4 mandatory would be dangerous.

[oxyc]

Ansible is developed and released on a flexible 4 months release cycle.

So that means 2.8 will be released early 2019.

[dixhuit]

I'm curious as to what the exact fix is for the first warning (I'm experiencing this same warning in other playbooks besides DVM):

[DEPRECATION WARNING]: [defaults]hostfile option, The key is misleading as it 
can also be a list of hosts, a directory or a list of paths . This feature will
 be removed in version 2.8. Deprecation warnings can be disabled by setting 
deprecation_warnings=False in ansible.cfg.

At least with the other warnings it gives you some suggestions as to how you might go about addressing the issue.

[iAugur]

In most cases simply change it from hostfile to inventory

[default]
#hostfile = ./inventory/common/allhosts
inventory = ./inventory/common/allhosts

[dixhuit]

@iAugur Yeah, I've already done exactly that in a few playbooks but my linter is still complaining - I'm gonna put that down to a shortcoming of the linter for now.

[wturrell]

For the benefit of others, especially if you don't edit your ansible.cfg very often, it may be hidden, named as .ansible.cfg (in your home directory).

[ElijahLynn]

Also for the benefit of others, if you have a closer ansible.cfg in your directory hierarchy, it will choose that one and NOT merge the two together. So if you have an ansible.cfg in your playbook directory, setting deprecation_warnings=false in /etc/ansible/ansible.cfg will do nothing even if that setting isn't specified in your ansible.cfg in the playbook dir. I know this is obvious to some but hey, here I am.

[geerlingguy]

@danbohea also related: ansible/ansible#25160

[dixhuit]

Also, also, for the benefit of others, the source of my particular issue was that I was still exporting ANSIBLE_HOSTS in my .bash_profile e.g:

# This is now deprecated.
export ANSIBLE_HOSTS=$HOME/some/path

[geerlingguy]

See #1701 as well—we've bumped the version to 2.4, so I feel like I might start bumping a few more of my roles too. But until all are updated (that will take a while...) the deprecation warnings will persist for those who don't disable them.