Porting Guide for Ansible AVD 4.x.x¶
Major releases of AVD can contain breaking changes. The porting guide addresses how to update your inventory and playbooks to be compatible with new default behaviors and changed data models, when upgrading from AVD 3.x.x versions.
Users of eos_designs do not have to consider the changes in eos_cli_config_gen, since those adaptions are
built in to eos_designs.
Changes to role arista.avd.eos_config_deploy_cvp¶
Inventory to CloudVision containers¶
In AVD v4.0.0 the role get support for dynamic Ansible inventories. This means that the basis for CloudVision
containers will no longer be the inventory.yml file, but instead the role reads the loaded Ansible inventory. This inventory can be loaded from dynamic inventory plugins like Ansible Automation Platform, AWX etc.
The new inventory parsing is stricter than the previous method, so all Ansible inventory groups must be laid
out as a regular tree structure starting from the container_root.
Old behavior can be retained by adding the variable avd_inventory_to_container_file: "{{ inventory_file }}" to the playbook task
for arista.avd.eos_config_deploy_cvp like this example:
- name: Configuration deployment with CVP
hosts: cv_servers
connection: local
gather_facts: false
collections:
- arista.avd
tasks:
- name: Provision CVP
import_role:
name: eos_config_deploy_cvp
vars:
container_root: 'DC1_FABRIC'
configlets_prefix: 'AVD'
state: present
avd_inventory_to_container_file: "{{ inventory_file }}" # <--- Retain old behavior from AVD v3.x.x
Supported group structure¶
In this example the container_root is set to DC1_FABRIC. This means that this, and all groups below will be created
as containers on CloudVision. Devices can be a member of multiple group hierarchies like DC1_FABRIC and DC1_TENANT_NETWORKS,
as long as the other hierarchies are not below group set as container_root.
---
all:
children:
DC1:
children:
DC1_FABRIC:
children:
DC1_SPINES:
hosts:
DC1-SPINE1:
DC1-SPINE2:
DC1_L3LEAFS:
children:
DC1_LEAF1:
hosts:
DC1-LEAF1A:
DC1-LEAF1B:
DC1_LEAF2:
hosts:
DC1-LEAF2A:
DC1-LEAF2B:
DC1_TENANTS_NETWORKS: # <--- This group is under DC1, but it is NOT under DC1_FABRIC, so this inventory is supported
children:
DC1_L3LEAFS:
Not supported group structure¶
---
all:
children:
DC1:
children:
DC1_FABRIC:
children:
DC1_SPINES:
hosts:
DC1-SPINE1:
DC1-SPINE2:
DC1_L3LEAFS:
children:
DC1_LEAF1:
hosts:
DC1-LEAF1A:
DC1-LEAF1B:
DC1_LEAF2:
hosts:
DC1-LEAF2A:
DC1-LEAF2B:
DC1_TENANTS_NETWORKS: # <--- This group is under DC1_FABRIC, making DC1_L3LEAFS two "parents",
children: # so this inventory is *not* supported with the new inventory parser
DC1_L3LEAFS: