ansible / proposals

Repository for sharing and tracking progress on enhancement proposals for Ansible.
Creative Commons Zero v1.0 Universal
92 stars 19 forks source link

Add automated playbook updater tool that implements the Porting Guide #175

Open gundalow opened 4 years ago

gundalow commented 4 years ago

Proposal:

Author: John Barker <@gundalow>

Date: 2019-11-04

Motivation

Currently, each version of Ansible includes a Porting Guide containing manual steps that users are required to look at and manually update their Playbooks, or just keep on running ansible-playbook till the deprecation notices go away.

A Porting Guide

This can include things like:

Size of Porting Guide

Rounded number of lines porting_guide_2.x.rst:

Partly the size is increasing as we get better at including things in the porting guide, partly as we are forcing users to change more per release.

This could be done in a way so Porting Guide fragments could be contained in Collections and pulled together to go alongside Ansible releases.

Solution proposal

Create a tool to "upgrade" Playbooks from one version of Ansible to the next, similar to:

Some of this could be automated, ie:

porting_data_2.9.yml (Steps needed to go from Ansible 2.8 to Ansible 2.9)

renames:
  modules:
    - ec2_ami_find:
      new_module: ec2_ami_facts 
    - kubernetes:
      new_module: k8s_raw 
    - cs_instance_facts:
      new_module: cs_instance_info 
    - net_banner: # Script can't fix this for you.
      manual_message: Use the platform-specific [netos]_banner modules instead
   lookup:
     - redis_kv:
       new_plugin: redism
module_changes:
  - win_firewall_rule:
    arg: force
    removed: true

Example upgrade

New tool ansible-update (or could be related to ansible-lint)

Think it terms of

$ ansible-update  -v .
Upgrading playbooks to Ansible 2.9 format
[I] roles/setup/tasks/main.yml:1 ec2_ami_find -> ec2_ami_facts
[E] roles/switch_basic/tasks/main.yaml:4  Manual update needed for `net_banner` Use the platform-specific [netos]_banner modules instead
$ git diff
diff --git a/roles/setup/tasks/main.yml b/roles/setup/tasks/main.yml
index 49111d4..c0fbfca 100644
--- a/roles/setup/tasks/main.yml
+++ b/roles/setup/tasks/main.yml
@@ -1,3 +1,3 @@
 - name: gather information about an AMI using ami-id
-  ec2_ami_facts:
+  ec2_ami_info:
     image_ids: ami-5b488823

Generating Docs

This, along with https://github.com/ansible/ansible/blob/816e194e375913537b31c2c8e2bd5baa6fdfb308/lib/ansible/modules/network/vyos/_vyos_interface.py#L36-L39 could be used to generate the Porting Guides.

Rather than a list, this could be used to generate a table like debops do, thanks drybjed for the suggestion.

Dependencies (optional)

Explain any dependencies. This section is optional but could be helpful.

Testing (optional)

Documentation (optional)

Anything else?

tremble commented 4 years ago

The deprecation example you give is deprecating a whole module. There are also cases where we want to deprecate options/defaults. It might be worth adding a something similar for options.

gundalow commented 2 years ago

I still think this is a useful thing. I know it can't ever do everything. I feel like this plus linter would be good for Devtools, thiugh needs to be part of a wider plan, rather than piecemeal.