Ansible Community Steering Committee

As we all know, Ansible is a well-adapted tool for the end-to-end automation of IT infrastructures. At the same time, due to the addition of new features and developments within the project, the Ansible community is growing at an accelerated rate. To help structure the project and also to facilitate the change in direction, we are launching a Steering Committee for the Ansible Community Project.

The Steering Committee's role is to provide guidance, suggestions, and ensure delivery of the Ansible Community package. The committee shall be broadly representative of the planning and approval areas.

The initial Steering Committee members, selected based on their wide knowledge of and active contributions to the Ansible project, are:

• Toshio Kuratomi (abadger1999)
• Felix Fontein (felixfontein)
• Tadej Borovšak (tadeboro)
• James Cassell (cyberpear)
• John Barker (gundalow)
• Andrew Klychkov (andersson007_)
• Alicia Cozine (acozine)
• Sorin Sbarnea (zbr)
• Jill Rouleau (jillr)
• Brad Thornton (cidrblock)
• Dylan Silva (thaumos)

Members of the committee will work with community users plus Ansible teams within Red Hat to assist in the composition of idea proposals/new collection inclusion requests. Rather than advocating on behalf of particular interests or perspectives, the job of the Steering Committee members is to listen carefully to their fellow community members, discuss, train, guide, and help them shape the Ansible Upstream Project in the best possible direction for the community.

Here are the current responsibilities of Ansible Community Steering Committee members:

• Design policies and procedures for the collection world.
• Review content (collections for now) for compliance with the policies.
• Help create the community deliverables (community.general collection, community.network collection, the ansible-tarball, community documentation website).
• Ballot on approval of new proposals and changes to policies.
• Identify and train individuals from the community who are interested in contributing to Ansible.

Be a catalyst for the Ansible Community

We encourage all Ansible users to participate in the public Ansible Community Meeting that occurs weekly in the #ansible-community IRC channel on libera.chat every Wednesday at 18:00 UTC. 

In addition, we used a GitHub issue - Community Working Group Meeting Agenda - earlier on to track agenda topics for discussions in the weekly Ansible Community IRC meetings Going forward, to track and categorize each topic separately, we've created a new GitHub repository community-topics. To discuss an idea, suggest improvements, or submit new Policies/Proposals and New Collection Inclusion Requests, you will create a new issue in the repo as a topic, and it'll be discussed publicly in the weekly IRC meeting. After every meeting, the meeting minutes/summaries and meeting logs will be posted to the original issue.

The Steering Committee will afford all interested persons an opportunity to contribute and review, and will also afford all interested persons an opportunity to speak on any idea during the meeting.

Ansible Network Resource Purge parameter

Red Hat Ansible Network Automation continues to be a popular domain for Red Hat Ansible Automation Platform. We have continually developed additional resource modules to make automating network appliances easier, and more approachable, for novices and experts alike. These resource modules provide a consistent experience across multiple network vendors. There are seven main state parameters for resource modules: merged, replaced, overridden, deleted, gathered, rendered and parsed. The Ansible network team is adding one more parameter, purged, to this tool chest for resource modules. This blog will cover the purged parameter and show use-cases through a practical example.

For this example, we will be using two BGP resource modules to configure a Cisco network device. We will be using the bgp_global module and the bgp_address_family module. The BGP configuration is split between these two separate modules to simplify configuration and data models associated with them.

Let's start with a data model:

bgp_global:
    as_number: '65000'
    bgp:
        log_neighbor_changes: true
        router_id:
            address: 192.168.1.1
    neighbor:
    -   activate: true
        address: 10.200.200.2
        remote_as: 65001
bgp_address_family:
    address_family:
    -   afi: ipv4
        neighbor:
        -   activate: true
            address: 10.200.200.2
        network:
        -   address: 10.25.25.0
            mask: 255.255.255.0
        -   address: 10.25.26.0
            mask: 255.255.255.0
        -   address: 10.100.100.0
            mask: 255.255.255.0
        -   address: 10.200.200.0
            mask: 255.255.255.0
        -   address: 172.16.0.0
        -   address: 192.168.1.1
            mask: 255.255.255.255
    as_number: '65000’

NOTE: If you are new to resource modules, you can quickly create these data models by using the state: gathered parameter to read in a brown-field (already configured) network devices and save that configuration to structured data (e.g. YAML) 

We can push this data model configuration to our Cisco network device very easily with a simple Ansible Playbook:

---
- name: configure BGP for blog
  hosts: cisco
  gather_facts: false
  tasks:
  - name: Use the bgp_global resource module
    cisco.ios.ios_bgp_global:
      config: "{{ bgp_global }}"

  - name: Use the bgp_address_family
    cisco.ios.ios_bgp_address_family:
      config: "{{ bgp_address_family }}

You can copy this playbook directly from Github 

To execute the playbook:

ansible-playbook merge_ios_bgp.yaml

The output will look similar to the following:

Finally let's look at the generated configuration on our Cisco IOS network device:

rtr1#sh run | s router bgp
router bgp 65000
 bgp router-id 192.168.1.1
 bgp log-neighbor-changes
 neighbor 10.200.200.2 remote-as 65001
 !
 address-family ipv4
  network 10.25.25.0 mask 255.255.255.0
  network 10.25.26.0 mask 255.255.255.0
  network 10.100.100.0 mask 255.255.255.0
  network 10.200.200.0 mask 255.255.255.0
  network 172.16.0.0
  network 192.168.1.1 mask 255.255.255.255
  neighbor 10.200.200.2 activate
 exit-address-family

So finally here is the easy part, using our new state: purged parameter: you can delete the entire bgp configuration on a device using one task. This might be often relevant on lab networks or when you want to start with a clean-state configuration.

- name: Use the bgp_global resource module
  cisco.ios.ios_bgp_global:
    state: purged

Difference between purged and deleted

The state: deleted parameter is very similar, however it has two primary purposes different than purged. Deleted has the ability to remove the specified configuration with the config parameter. If no configuration is specified it will delete that entire resource (e.g. all address family configuration if using the bgp_address_family module). However, there are multiple resource modules that make up BGP configuration. This means you would need multiple modules running state: deleted to remove all the BGP configuration. The state: purged parameter allows you to use bgp_global resource module to remove all BGP configuration simplifying your Ansible Playbooks.

Now we can execute the playbook and manually check the configuration to see what it did:

In the above screenshot (from the Ansible Automation Platform Web UI) you can see that the playbook ran successfully and the BGP configuration is now removed.

Checking the running configuration on the Cisco router will reflect the change:

rtr1#sh run | s router bgp
rtr1#

Why would I use one over the other?

Many people are automating brownfield networks, or even networks where a mix of manual changes and automated changes are taking place. You might want to remove all BGP configuration from multiple devices where you have no SoT (Source of Truth) setup. This allows a playbook writer to use one task to destroy just BGP configuration versus a multiple-module method. This is just another tool in your resource module toolbelt!

Where do I go next?

All the examples in this blog post are on Github here.