One of the major networking features in Red Hat Ansible Engine 2.4 was the addition of aggregate resources to the networking modules. The Ansible networking team recently talked about this at the Ask an Expert webinar in November.
What are Aggregate Resources?
Simply put, aggregate resources are a better way to iterate (or loop) without the need to execute each task one by one. That is, you can now “aggregate” a collection as a single task instead of a collection of discrete loops.
Loop Method
Aggregate Method
Loop Method (with_items:) |
Aggregate Method (aggregate:) |
---|---|
|
|
503 steps |
4 steps |
Based on feedback from customers, partners and community members, this post provides more examples and more detail of this important new feature. The simplest way to showcase this is to compare the old way and the new way, and highlight the differences between each.
For this scenario we assume a network operator wants to configure 500 VLANs on a Arista EOS device. We can use the eos_vlan Ansible module to easily accomplish this. Refer to the following Ansible Playbook snippet.
Ansible 2.3 and older
The vlan_id parameter is where the actual 802.1q VLAN number is specified. The name parameter is a description that helps identify what this VLAN is for (i.e. printers, laptops, etc). Finally, the state parameter describes what the intended or expected state should be, which can be present, absent, active or suspend.
- eos_vlan:
vlan_id: "{{ item.vlan_id }}"
name: "{{ item.name | default('VLAN' + item.vlan_id|string) }}"
state: "{{ item.state | default('active') }}"
with_items:
- { vlan_id: 1, name: default }
- { vlan_id: 2, name: Vl2 }
- { vlan_id: 3, state: suspend }
View the full playbook: oldway.yml
Prior to integrating the aggregate resources feature, with_items was used as a loop and passed this criteria for multiple VLANs. Loops are very useful within Ansible, however in this particular example loops can have serious performance impacts. To highlight the execution time differences, we can use the Linux time command.
sean@rhel7 ~]$ time ansible-playbook oldway.yml
This particular playbook with just the one task took 18 minutes and 52 seconds to run over 500 VLANs. Ansible still provides parallelism across many different network switches, but this is far too slow for many large scale production environments!
Red Hat Ansible Engine 2.4 and newer
The new aggregate method allows us to pass the entire list of VLAN information without looping. The exact same list of VLANs shown in oldway.yml can be reused easily. Simply moving every line of the VLAN data from the task level to the module level (two spaces in) under the aggregate section (replacing with_items previously). Instead of looping each VLAN one at a time, we can send all the information at once. Keep in mind this example is only showing the first three VLANs, the full example contains 500 VLANs. This is what the updated task in the playbook looks like:
- eos_vlan:
state: active
aggregate:
- { vlan_id: 1, name: default }
- { vlan_id: 2, name: Vl2 }
- { vlan_id: 3, state: suspend }
The modified task with aggregate resources is also timed to compare:
sean@rhel7 ~]$ time ansible-playbook newway.yml
View the full playbook: newway.yml
This took 10 seconds to complete, which is significantly faster than the previous ~19 minute method. Another advantage is that you will also see all VLANs as either changed or OK at the task level (referring to Ansible’s ability to keep track of state) rather than VLAN by VLAN as with the loop method.
The Purge Ability
In conjunction with the aggregate feature, there is a purge parameter. The purge knob is defined as “Purge VLANs not defined in the aggregate parameter.” This means that VLANs not defined in the aggregate will be removed from the switch. So when the aggregate in this example is used all other VLANs will be deleted.
- eos_vlan:
state: active
purge: yes
aggregate:
- { vlan_id: 1, name: default }
- { vlan_id: 2, name: Vl2 }
- { vlan_id: 3, state: suspend }
View the full playbook: purge.yml
When it is not used, it only enforced that the VLANs exist in the state the aggregate sends them. What are potential use-cases for each?
purge: yes |
In this particular eos_vlan example turning the purge ability on allows us to enforce configuration policy. What that means is if another user or process adds a VLAN, we will revert the configuration to only contain the VLANs we provide in the aggregate parameter. |
---|---|
purge: no |
If the user running the playbook doesn’t care about the state of any VLANs not provided (i.e. he is working on VLAN10-50 and doesn’t care about VLAN200 which also happens to be configured). This allows playbooks to be written in a way where a temporary configuration could be supplied without affecting ongoing configuration. |
Going Further
Where else can I use aggregate? Other Arista examples include those such as the eos_user module and the eos_vrf module. Users and VRFs can be handled in a single aggregate rather than a collection of looped tasks. Instead of sending configuration user by user, or VRF by VRF with a loop it is now possible to use the aggregate. This will speed up configurations and give an alternative to using os_config modules with Jinja templating.
The aggregate feature is not limited to just the Arista EOS platform. Other networking platforms such as Cisco IOS, Cisco NX-OS and Juniper JunOS also have aggregate enabled in those respective modules. The Red Hat Ansible Engine Networking Add-on includes full support for use of aggregate in the supported platform modules. |
Ansible network modules that are capable of the aggregate feature are listed on their respective module documentation page. The aggregate keyword will appear under the parameter heading in the Options table. Click here for a complete list of modules.
All scenarios in this blog post are stored in a GitHub repo in our network automation community.
Follow the aggregate resources repository here.
To become a member of the growing community email us with your GitHub ID.
Have more questions? Join our next regularly scheduled Ask an Expert: Networking Webinar.
About the author
Sean is a Principal Technical Marketing Manager, Ansible, where he brings over 10 years of experience building and automating computer networks. Sean previously worked for both Cumulus Networks (acquired by Nvidia) and Cisco Systems where he helped customers deploy, manage and automate their network infrastructure. He resides in Chapel Hill, NC with his wife and children and tweets from @IPvSean.
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit