We want to hear from you! Help us gain insights into the state of the Ansible ecosystem.
Take the Ansible Project Survey 2024

Customer Spotlights at AnsibleFest 2020

Customer Spotlights at AnsibleFest 2020

AnsibleFest 2020 will be here before we know it, and we cannot wait to connect with everyone in October. We have some great content lined up for this year's virtual experience and that includes some amazing customer spotlights. This year you will get to hear from CarMax, Blue Cross Blue Shield of NC, T-Mobile, and Cepsa. These customers are using Ansible in a variety of ways, and we hope you connect to their incredible stories of teamwork and transformative automation.

Customer Spotlights

Benjamin Blizard, a Network Engineer at T-Mobile, will explore how T-Mobile transformed from a disparate organization with difficulty enforcing standards to a collaborative group of engineers working from repeatable templates and processes. T-Mobile, a major telecommunications provider, uses Ansible Automation Platform to standardize processes across their organization. Ben will show how automation supports T-Mobile's compliance standards, data integrity, and produces speed and efficiency for network teams. 

Peter Bojovic, Director of Systems Engineering at Blue Cross Blue Shield of North Carolina, will talk about how they used automation to drive down costs in managed service costs while increasing productivity. Blue Cross NC, a leading health insurance provider, recently implemented a new tool to automate provisioning of their virtual machines for critical on-premise applications.

Members of Blue Cross NC's deployment team will also speak on a panel interview setup, featuring: Tobin Shay, Alex Devirgilis and Pavan Mutyala. They will discuss their recent experiences using automation to handle a large-scale migration and the future of automation at Blue Cross NC. The interview will also touch on how a large organization works to decrease a reliance on managed services, and the planning and processes that lead to a projected 16-week project being completed in just three business days.




Introducing the VMware REST Ansible Content Collection

Introducing the VMware REST Ansible Content Collection

The VMware Ansible modules as part of the current community.vmware Collection are extremely popular. According to GitHub, it's the second most forked Collection, just after community.general. The VMware modules and plugins for Ansible have benefited from a stream of contributions from dozens of users. Many IT infrastructure engineers rely on managing their VMware infrastructure by means of a simple Ansible Playbook. The vast majority of the current VMware modules are built on top of a dependent python library called pyVmomi, also known as vSphere Automation SDK for Python.

Why a new VMware Ansible Content Collection?

VMware has recently introduced the vSphere REST API for vSphere 6.0 and later, which will likely replace the existing SOAP SDK used in the community.vmware Collection.

Since the REST API's initial release, vSphere support for the REST API has only improved. Furthermore, there is no longer a need for any dependent python packages. In order to maintain the existing VMware modules in the community.vmware Collection, a set of modules specifically for interacting with the VMware REST API is now available in the newly created vmware.vmware_rest Collection.

If you compare modules used with the VMware vSphere API (SOAP) to the ones using the REST API, you'll notice the REST API modules are not yet feature complete, as this is an early release of the Collection. For example, there currently is no way to create a cluster or a folder using the modules in the vmware.vmware_rest Collection, but the API provides all you need for a VMware guest for future Collection enablement and much more.

Using the VMware REST API

In order to understand how the new modules function against the new REST API, let's take a look at the REST API itself first. For example, the com.vmware.vcenter.vm.power API endpoint changes the power state of a VM. It's equivalent to the following sample URL:

https://vcenter.test/rest/vcenter/vm/\$vm/power

With the vCenter 7.0 release, 723 total REST endpoints are exposed, which can be discovered using the following curl command:

$ curl -k https://vcenter.test/rest/com/vmware/vapi/metadata/cli/command|jq -r ".[][].path"|uniq|wc -l
723

The VMware REST APIs are documented in the Swagger 2.0 format. You can find the JSON files on your vCenter node in the following directory path:

root@vcenter [ /etc/vmware-vapi/apiexplorer/json ]# ls -lh
total 3.3M
-rw-r--r-- 1 vapiEndpoint users  145 Aug 31 15:37 api.json
-rw-r--r-- 1 vapiEndpoint users 396K Aug 31 15:36 appliance.json
-rw-r--r-- 1 vapiEndpoint users 153K Aug 31 15:36 cis.json
-rw-r--r-- 1 vapiEndpoint users 272K Aug 31 15:37 content.json
-rw-r--r-- 1 vapiEndpoint users 395K Aug 31 15:36 esx.json
-rw-r--r-- 1 vapiEndpoint users 153K Aug 31 15:36 stats.json
-rw-r--r-- 1 vapiEndpoint users 176K Aug 31 15:37 vapi.json
-rw-r--r-- 1 vapiEndpoint users 1.8M Aug 31 15:36 vcenter.json

To summarize, the vmware.vmware_rest Collection has all these REST endpoints ready to be consumed with the descriptions in a well documented format.

Building the vmware_rest Collection

The modules contained in this Collection are generated using a tool called  vmware_rest_code_generator, which was developed and open sourced by the Ansible team. It loads the Swagger files and then auto-generates a module per each resource, generating more than 300 modules this way. You'll notice that not every module has been released to the Collection. For purposes of starting small, we are only generating modules against a subset of the endpoints exposed, only those associated with guest management use cases. We may expand and extend the number of modules over time.

Using the vmware_rest Collection

The following tasks retrieve a list of the VM, shuts them down, and then deletes them:

- name: Collect the list of the existing VM
  vcenter_vm_info:
  register: existing_vms
  until: existing_vms is not failed

- name: Turn off the VM
  vcenter_vm_power:
    state: stop
    vm: '{{ item.vm }}'
  with_items: "{{ existing_vms.value }}"
  ignore_errors: yes

- name: Delete some VM
  vcenter_vm:
    state: absent
    vm: '{{ item.vm }}'
  with_items: "{{ existing_vms.value }}"

Refer to the following gist file for more information: https://gist.github.com/goneri/6afd05397390cf5a0976f3611814949a

Downloading the vmware_rest Collection

The goal of this early release is to get as much community feedback as possible.

The Collection is available on Ansible Galaxy, and requires the following:

  • Ansible 2.9 or later 
  • Python 3.6 or later
  • The aiohttp package

Use the ansible-galaxy command to retrieve the Collection:

# ansible-galaxy collection install vmware.vmware_rest

If you use a virtualenv, you can install aiohttp with following command:

# pip install aiohttp

Else, you will need to download and install the python3-aiohttp package.

To read the module documentation, use the ansible-doc command. For example, to read documentation for the vcenter_cluster_info module, refer to the following command:

# ansible-doc -t module vmware.vmware_rest.vcenter_cluster_info

vCenter-Managed Object Reference ID

If you are already using the community.vmware Collection, the main difference is that the newer modules rely on the MORef ID to identify the elements instead of the name of the object. For example, if the user creates a datacenter called dc1, the MORef ID using the new modules will be datacenter-2. The community.vmware Collection uses the name and the folder instead.

By using the MORef ID directly, the module is able to interact with the resource without any time consuming preliminary look up.

How can I contribute?

Because the modules are auto-generated, it GitHub pull requests should be raised against the code generator itself, and not the resulting Collection contents.

Don't hesitate to report any issues on the GitHub project at https://github.com/ansible-collections/vmware_rest/issues.

Reference:

The forks per collection can be found programmatically by accessing the Github API: https://api.github.com/orgs/ansible-collections/repos 

This can be sorted, for example:

method: curl -s https://api.github.com/orgs/ansible-collections/repos|jq -r -c --sort-keys '.|sort_by(.forks)|reverse|.[]|[.name, .forks]'



Developing and Testing Ansible Roles with Molecule and Podman - Part 2

Developing and Testing Ansible Roles with Molecule and Podman - Part 2

Molecule is a complete testing framework that helps you develop and test Ansible roles, which allows you to focus on role content instead of focusing on managing testing infrastructure. In the first part of this series, we've successfully installed, configured and used Molecule to set up new testing instances.

Now that the instances are running, let's start developing the new role and apply Molecule to ensure it runs according to the specifications.

This basic role deploys a web application supported by the Apache web server. It must support Red Hat Enterprise Linux (RHEL) 8 and Ubuntu 20.04.

Developing the Ansible Role with Molecule

Molecule helps in the development stage by allowing you to "converge" the instances with the role content. You can test each step without worrying about managing the instances and test environment. It provides quick feedback, allowing you to focus on the role content, ensuring it works in all platforms.

In the first part of this series, we initialized a new role "mywebapp". If you're not there yet, switch to the role directory "mywebapp" and add the first task, installing the Apache package "httpd" using the "package" Ansible module. Edit the file "tasks/main.yaml" and include this task:

$ vi tasks/main.yml
---
# tasks file for mywebapp
- name: Ensure httpd installed
  package:
    name: "httpd"
    state: present

Save the file and "converge" the instances by running "molecule converge". The "converge" command applies the current version of the role to all the running container instances. Molecule "converge" does not restart the instances if they are already running. It tries to converge those instances by making their configuration match the desired state described by the role currently testing.

$ molecule converge
... TRUNCATED OUTPUT ...
   TASK [mywebapp : Ensure httpd installed] ***************************************
    Saturday 27 June 2020  08:45:01 -0400 (0:00:00.060)       0:00:04.277 *********
fatal: [ubuntu]: FAILED! => {"changed": false, "msg": "No package matching 'httpd' is available"}
    changed: [rhel8]
... TRUNCATED OUTPUT ...

Notice that the current version worked well on the RHEL8 instance, but failed for the Ubuntu instance. By using Molecule, you can quickly evaluate the result of your tasks in all platforms and verify if the role works according to the requirements! In this example however, the tasks failed because Ubuntu does not have a package named "httpd". For that platform, the package name is "apache2".

So let's modify the role to include variables with the correct package name for each platform. Start with RHEL8 by adding a file "RedHat.yaml" under the "vars" sub-directory with this content:

$ vi vars/RedHat.yaml
---
httpd_package: httpd

Save this file and add the corresponding file "vars/Debian.yaml" for Ubuntu:

$ vi vars/Debian.yaml
---
httpd_package: apache2

Save this file and modify the "tasks/main.yaml" file to include these variable files according to the OS family identified by Ansible via the system fact variable "ansible_os_family". We also have to include a task to update the package cache for systems in the "Debian" family since their package manager caches results otherwise. Last, we update the install task to use the variable "httpd_package" that you defined in the variables files:

$ vi tasks/main.yml
- name: Include OS-specific variables.
  include_vars: "{{ ansible_os_family }}.yaml"

- name: Ensure package cache up-to-date
  apt:
    update_cache: yes
    cache_valid_time: 3600
  when: ansible_os_family == "Debian"

- name: Ensure httpd installed
  package:
    name: "{{ httpd_package }}"
    state: present

Save this file, and "converge" the instances again to ensure it works this time:

$ molecule converge
... TRUNCATED OUTPUT ...
   TASK [mywebapp : Ensure httpd installed] ***************************************
    Saturday 27 June 2020  08:59:13 -0400 (0:00:07.338)       0:00:12.925 *********
    ok: [rhel8]
    changed: [ubuntu]
... TRUNCATED OUTPUT ...

Because the package was already installed in the RHEL8 instance, Ansible returned the status "OK" and it did not make any changes. It installed the package correctly in the Ubuntu instance this time.

We have installed the package - but the naming problem also exists with the service itself: they are named differently in RHEL and Ubuntu. So we add service name variables to the playbooks and variable files. Start with RHEL8:

$ vi vars/RedHat.yaml
---
httpd_package: httpd
httpd_service: httpd

Save this file and then edit the file "vars/Debian.yaml" for Ubuntu:

$ vi vars/Debian.yaml
---
httpd_package: apache2
httpd_service: apache2

Save the file and add the new task at the end of the "tasks/main.yml" file:

$ vi tasks/main.yml
- name: Ensure httpd svc started
  service:
    name: "{{ httpd_service }}"
    state: started
    enabled: yes

Save the file and "converge" the instances again to start the Apache httpd service:

$ molecule converge
... TRUNCATED OUTPUT ...
   TASK [mywebapp : Ensure httpd svc started] *************************************
    Saturday 27 June 2020  09:34:38 -0400 (0:00:06.776)       0:00:17.233 *********
    changed: [ubuntu]
    changed: [rhel8]
... TRUNCATED OUTPUT ...

Let's add a final task to create some content for the web application. Each platform requires the HTML files owned by different groups. Add new variables to each variable file to define the group name:

$ vi vars/RedHat.yaml
---
httpd_package: httpd
httpd_service: httpd
httpd_group: apache

Save this file then edit the file "vars/Debian.yaml" for Ubuntu:

$ vi vars/Debian.yaml
---
httpd_package: apache2
httpd_service: apache2
httpd_group: www-data

Save the file and add the new task at the end of the "tasks/main.yml" file:

$ vi tasks/main.yml
- name: Ensure HTML Index
  copy:
    dest: /var/www/html/index.html
    mode: 0644
    owner: root
    group: "{{ httpd_group }}"
    content: "{{ web_content }}"

This task allows the role user to specify the content by using the variable "web_content" when calling the role. Add a default value to this variable in case the user does not specify it:

$ vi defaults/main.yml
---
# defaults file for mywebapp
web_content: There's a web server here

Save this file and "converge" the instances one more time to add the content:

$ molecule converge
... TRUNCATED OUTPUT ...
   TASK [mywebapp : Ensure HTML Index] ********************************************
    Saturday 27 June 2020  09:50:11 -0400 (0:00:03.261)       0:00:17.753 *********
    changed: [rhel8]
    changed: [ubuntu]
... TRUNCATED OUTPUT ...

At this time, both instances are converged. Manually verify that the role worked by using the molecule login command to log into one of the instances and running the "curl" command to get the content:

$ molecule login -h rhel8
[root@2ce0a0ea8692 /]# curl http://localhost
There's a web server here
[root@2ce0a0ea8692 /]# exit

You used Molecule to aid with the role development by ensuring that it is working properly across multiple platforms for each step of the way.

Next, let's automate the verification process.

Verifying the Role with Molecule

In addition to helping you converge the instance to aid with the role development, Molecule can also automate the testing process by executing a verification task. To verify the results of your playbook, Molecule can use either the "testinfra" framework or it can use Ansible itself. 

Let's use an Ansible Playbook to verify the results of this new role. By default, Molecule provides a basic verifier playbook "molecule/default/verify.yml" as a starting point. This playbook contains the basic required structure but does not do any useful verification. Update this playbook to test this role result by using the Ansible's "uri" module to obtain the content from the running web server and the "assert" module to ensure it's the correct content:

$ vi molecule/default/verify.yml
---
# This is an example playbook to execute Ansible tests.

- name: Verify
  hosts: all
  vars:
    expected_content: "There's a web server here"
  tasks:
  - name: Get index.html
    uri:
      url: http://localhost
      return_content: yes
    register: this
    failed_when: "expected_content not in this.content"

  - name: Ensure content type is text/html
    assert:
      that:
      - "'text/html' in this.content_type"

  - name: Debug results
    debug:
      var: this.content

Save and close this file. Verify the results by running "molecule verify":

$ molecule verify
... TRUNCATED OUTPUT ...
   TASK [Ensure content type is text/html] ****************************************
    Saturday 27 June 2020  10:03:18 -0400 (0:00:03.131)       0:00:07.255 *********
    ok: [rhel8] => {
        "changed": false,
        "msg": "All assertions passed"
    }
    ok: [ubuntu] => {
        "changed": false,
        "msg": "All assertions passed"
    }
... TRUNCATED OUTPUT ...
Verifier completed successfully.

Molecule runs the verifier playbook against all instances ensuring the results match the expected values.

You can change the default values for the test by editing the converge playbook to update the "web_content" variable:

$ vi molecule/default/converge.yml
---
- name: Converge
  hosts: all
  tasks:
    - name: "Include mywebapp"
      include_role:
        name: "mywebapp"
      vars:
         web_content: "New content for testing only"

Then, update the "expected_content" variable in the verifier playbook:

$ vi molecule/default/verify.yml
---
# This is an example playbook to execute Ansible tests.

- name: Verify
  hosts: all
  vars:
    expected_content: "New content for testing only"
  tasks:

Converge the instances one more time to update the web server content, then verify the results:

$ molecule converge
... TRUNCATED OUTPUT ...
   TASK [mywebapp : Ensure HTML Index] ********************************************
    Saturday 27 June 2020  10:09:34 -0400 (0:00:03.331)       0:00:19.607 *********
    changed: [rhel8]
    changed: [ubuntu]
... TRUNCATED OUTPUT ...
$ molecule verify
... TRUNCATED OUTPUT ...
   TASK [Debug results] ***********************************************************
    Saturday 27 June 2020  10:10:15 -0400 (0:00:00.299)       0:00:10.142 *********
    ok: [rhel8] => {
        "this.content": "New content for testing only"
    }
    ok: [ubuntu] => {
        "this.content": "New content for testing only"
    }
... TRUNCATED OUTPUT ...
Verifier completed successfully.

Using the verifier, you can define a playbook to execute checks and ensure the role produces the required results.

In the final step, let's put it all together with automated tests.

Automating the Complete Test Workflow

Now that all of the pieces are together, automate the complete testing process workflow using the command "molecule test".

Unlike the "molecule converge", which aided with role development, the goal with "molecule test" is to provide an automated and repeatable environment to ensure the role works according to its specifications. Therefore, the test process destroys and re-creates the instances for every test.

By default, "molecule test" executes these steps in order:

  1. Install required dependencies
  2. Lint the project
  3. Destroy existing instances
  4. Run a syntax check
  5. Create instances
  6. Prepare instances (if required)
  7. Converge instances by applying the role tasks
  8. Check the role for idempotence
  9. Verify the results using the defined verifier
  10. Destroy the instances

You can change these steps by adding the "test_sequence" dictionary with the required steps to the Molecule configuration file. For additional information, consult the official documentation.

Execute the test scenario:

$ molecule test
... TRUNCATED OUTPUT ...
--> Test matrix

└── default
    ├── dependency
    ├── lint
    ├── cleanup
    ├── destroy
    ├── syntax
    ├── create
    ├── prepare
    ├── converge
    ├── idempotence
    ├── side_effect
    ├── verify
    ├── cleanup
    └── destroy

--> Scenario: 'default'
... TRUNCATED OUTPUT ...

If the test workflow fails at any point, the command returns a status code different than zero. You can use that return code to automate the process or integrate Molecule with CI/CD workflows.

Conclusion

Now that you've successfully applied Molecule to develop and test a role that is well written and works reliably across different environments, you can integrate it into your development cycle to produce high standard roles consistently without worrying about the testing infrastructure.

Molecule helps during the role development process by providing constant feedback, which ensures your role works as designed each step of the way.

For more advanced scenarios, Molecule supports additional drivers that allow you to test roles with different platforms, virtualization and cloud providers.

Finally, you can integrate Molecule with CI/CD workflows to automate the complete testing process for your Ansible roles.




Bullhorn #10

Ansible Bullhorn banner

The Bullhorn

A Newsletter for the Ansible Developer Community
Issue #10, 2020-09-16


Welcome to The Bullhorn, our newsletter for the Ansible developer community. If you have any questions or content you’d like to share, please reach out to us at the-bullhorn@redhat.com, or comment on this GitHub issue.
 

KEY DATES

  • 2020-09-15: ansible-2.10.0 rc1 (moved from 10-Sep)
  • 2020-09-17: community IRC meeting (any blockers for release should be proposed and discussed here)
  • 2020-09-22: ansible-2.10 GA release date
 

ANSIBLE 2.10.0 RC1 NOW AVAILABLE

The Ansible Community team announced the availability of Ansible 2.10.0 release candidate 1 on September 15th. This new Ansible package should be a drop-in replacement for Ansible 2.9; the roles and playbooks that you currently use should work out of the box with ansible-2.10.0 rc1. For more information on how to download, test, and report issues, read Toshio Kuratomi’s announcement to the ansible-devel mailing list.

The ansible-2.10.0 prereleases continue to be updated for testing purposes. Ansible 2.10.0 beta 2 was uploaded to pypi last week, and Ansible 2.10.0 rc1 is now available on pypi as mentioned above.

For more release details, please take a look at:  

ANSIBLE-BASE 2.10.1 NOW GENERALLY AVAILABLE

The Ansible Base team announced the general release of Ansible 2.10.1 on September 14th. This ansible-base package consists of only the Ansible execution engine, related tools (e.g. ansible-galaxy, ansible-test), and a very small set of built-in plugins, and is also bundled with the larger Ansible distribution. For more information on how to download, test, and report issues, read Rick Elrod’s announcement to the ansible-devel mailing list.
 

ROLE/COLLECTION PUBLISHERS: CHANGES TO ANSIBLE-GALAXY LOGIN

If you use the ansible-galaxy CLI to publish roles or collections to Galaxy, you may care about this. The GitHub API that underlies the ansible-galaxy login command is being removed in November. Without it, users doing role or collection publishing operations via the Galaxy CLI will need to find their Galaxy token interactively in a browser and pass it using a config file (as the ability to generate a token from the CLI will no longer function). We're not sure what people do today or how much this option is used out in the world, so please read and weigh in here in the next few days if you have an opinion.
 

NEW/UPDATED COMMUNITY COLLECTIONS

The Ansible Podman collection has a new module podman_network for the management of Podman networking.
 

THE ANSIBLE TEAM IS HIRING

The Ansible Community Team is hiring engineers to help with onboarding Ansible contributors. For more info, please see the following job descriptions:  

CONTENT FROM THE ANSIBLE COMMUNITY

 

ANSIBLE CONTRIBUTOR SUMMIT - PART OF ANSIBLEFEST 2020

Due to overwhelming interest in the AnsibleFest 2020 edition of the Ansible Contributor Summit, we are planning 2 days of program for you, depending on where you are in your contribution journey. These will be held on October 12 and 15, 2020.

Take a look at the wiki page to find out how the two days will be structured, and register via the corresponding links. We look forward to your participation at the Contributor Summit!
 

OPEN SOURCE AUTOMATION DAYS

We will be a part of Open Source Automation Days, which will be an online event from October 19-21, 2020. Check out the speakers and topics, as well as workshops, and get tickets here if you’re interested.
 

ANSIBLE VIRTUAL MEETUPS

The following virtual meetups are being held in the Ansible community over the next month: Note: For these virtual meetups, the links to participate will be visible once you RSVP to attend. If you’re interested in the topics presented, you can join from anywhere in the world as long as the time zone and language works for you!
 

FEEDBACK

Have any questions you’d like to ask, or issues you’d like to see covered? Please send us an email at the-bullhorn@redhat.com.

 

 




Bullhorn #9

Ansible Bullhorn banner

The Bullhorn

A Newsletter for the Ansible Developer Community

Welcome to The Bullhorn, our newsletter for the Ansible developer community. If you have any questions or content you’d like to share, please reach out to us at the-bullhorn@redhat.com, or comment on this GitHub issue.
 

ANSIBLE 2.10.0 BETA 1 NOW AVAILABLE

The Ansible Community team announced the availability of Ansible 2.10.0 beta 1 on September 1st. This new Ansible package should be a drop-in replacement for Ansible 2.9; the roles and playbooks that you currently use should work out of the box with ansible-2.10.0 beta1. For more information on how to download, test, and report issues, read Toshio Kuratomi’s announcement to the ansible-devel mailing list.
 

ANSIBLE-BASE 2.10.1 RC2 NOW AVAILABLE

The Ansible Base team announced a release candidate of Ansible 2.10.1 on August 31st. This ansible-base package consists of only the Ansible execution engine, related tools (e.g. ansible-galaxy, ansible-test), and a very small set of built-in plugins, and is also bundled with the larger Ansible distribution. For more information on how to download, test, and report issues, read Rick Elrod’s announcement to the ansible-devel mailing list.
 

ANSIBLE 2.9.13 AND 2.8.15 RELEASED

The Ansible Core team announced the availability of Ansible 2.9.13 and Ansible 2.8.15 on August 31st, both of which are maintenance releases. Follow this link for Rick Elrod’s email to the ansible-devel mailing list, to obtain details on what’s new, installation instructions, and links to the full changelogs.
 

COLLECTION OWNERS: CHANGELOGS FOR ANSIBLE 2.10

Reminder for collection owners: please update your collections with appropriate changelogs by Monday, September 7. See Generating Changelogs for a collection for details on using the Ansible-provided tool. You can also link directly to your own changelogs or release notes by adding the link to an issue here by that same date.
 

NEW/UPDATED COMMUNITY COLLECTIONS

vmware.vmware_rest collection 0.1.0 has been released. It's a new VMware collection that is built on top of the vSphere REST API. The modules focus on guest management and can be mixed with the modules from community.vmware collection.
 

THE ANSIBLE TEAM IS HIRING

The Ansible Community Team is hiring engineers to help with onboarding Ansible contributors. For more info, please see the following job descriptions: The Ansible Documentation Team is hiring a technical writer. The job is listed in Raleigh, NC, but we will consider remote applicants. If you're interested or have any questions, reach out to us on the #ansible-docs channel on freenode IRC. We've had a lot of applicants already, so act fast!  

CONTENT FROM THE ANSIBLE COMMUNITY

 

ANSIBLEFEST VIRTUAL EXPERIENCE 2020

This year’s AnsibleFest will be a virtual experience! Find out the latest details about the event in this blog post, and register here. We are also having our Ansible Contributor Summit alongside AnsibleFest. More details will be shared soon!
 

ANSIBLE VIRTUAL MEETUPS

The following virtual meetups are being held in the Ansible community over the next month: Note: For these virtual meetups, the links to participate will be visible once you RSVP to attend. If you’re interested in the topics presented, you can join from anywhere in the world as long as the time zone and language works for you!
 

FEEDBACK

Have any questions you’d like to ask, or issues you’d like to see covered? Please send us an email at the-bullhorn@redhat.com.