AnsibleIL June 2023

Chris Nicholson, AHEAD

We enjoyed a conversation led by Chris Nicholson around Event-Driven Ansible and Ansible Lightspeed. Thank you, Chris! I have requested an Ansible meetup presenter badge for you, so watch for that in your inbox!

The following are my personal notes from the conversation. Please feel free to respond to the group to question, correct, or clarify any point. Chris provided context and detail around two of Ansible's newest features:

Event Driven Ansible (EDA)

• Event Driven Ansible is recommended to be installed on its own server as a component of the Ansible Automation Platform, although it can live on the Controller server or the Private Automation Hub server.
• Event listeners, called plugins, run in Java JVMs, watch for triggers to occur based on the defined Ansible rulebooks.
• Defined events trigger execution of a workflow or playbook on the controller, which executes tasks as needed (remediation, logging, notification, etc).
• There are several configurable listeners - kafka, web url, web hook, Dynatrace, grafana, and more.
• One caveat that was mentioned is if you lose the EDA server (eg, due to OOM), you lose all your event listeners. So monitor that Java! ... and put it on a separate server.
• EDA is reactive, rather than proactive. Start with what wakes you up at night.
• An example of how Chris has used EDA: listen to kafka stream for a k8s namespace creation, then apply SSL cert to the new namespace.
• ISU team experienced an issue that EDA doesn't pass host limit (--limit) or extra vars (--extra-vars) correctly to the controller when triggering a playbook.

Ansible Lightspeed (previously Project Wisdom)

• Ansible Lightspeed is the recently announced code-generation AI engine for writing playbooks. It is powered by IBM Watson and trained on Red Hat curated and certified content.
• Chris gave a demo of Lightspeed, which helped us see how effective (and currently limited) it is at interpreting intent and writing complete tasks. Overall, it will be a significant time-saver for someone experienced in their field to write a new playbook, but it will require someone with field experience to review and tweak code. When you opt in to the Lightspeed preview, it is as easy to use as checking a box in the config panel for the Ansible extension for VS Code.
• Once you set up Lightspeed in VS Code, it is always listening and interpreting for files of the Ansible type. It's not snappy, but using only the task name as input, it recommends an on-topic full-fledged task with arguments faster than I can google the module docs. It's pretty cool!
• Lightspeed has limited intelligence about task flow, such as reusing registered variables in new tasks.
• I do not recall how to provide feedback to help train the model. I am not sure that was in VS Code. Maybe Chris or the ISU team can provide context there.
• Ansible Lightspeed does give attribution for where its content recommendations are sourced from.
• Caveat: There is not yet a clear way to isolate your data from being contributed back to the model. I will touch base with the IBM Research team and see if I can get more information to share with the group.
• Steampunk Spotter is another Ansible Playbook Scanning tool that Chris may demo for us at another event.

We also had an impromptu conversation around linting and code standardization, since AI code generation will help people produce more code, faster.

• Linting, naming conventions, spacing need to be used consistently.
• Code validation needs to be done before merging.
• Automate linting and testing with something like GitHub Actions running Molecule.

Thanks again, Chris!