Ansible Automates London 2023: Lightspeed and EDA

On 13 July 2023 I spent the day at Ansible Automates London 2023, a one-day Red Hat event co-branded with Intel and held at CodeNode in London. I didn’t speak; I attended as an Ansible author and as the person behind Ansible Pilot. The day covered where Red Hat was taking Ansible Automation Platform (AAP), and it included a live demo of Ansible Lightspeed. This post is a throwback written in 2026 from the photos I took that day, plus a short section at the end on what has shipped since.

The main hall just before the morning keynote, with the “Welcome to Ansible Automates London” slide already up.

The format: three tracks, three questions

Before the event I published a preview of Ansible Automates London 2023 on Ansible Pilot with the three tracks. The room signs at CodeNode matched them:

• Room CMD: “Enterprise automation strategy – Why automate?”, for architects and business stakeholders.
• Room CTRL: “The outcome of automation – What to automate?”, with customer stories. The CTRL agenda listed sessions from M&G and DWP Digital.
• Room TAB/ALT: “Ansible Automation Platform – How to automate?”, the product track for teams already running AAP.

The opening keynote ran from 10:00 to 11:00 in CTRL, on the main stage with the big “Ansible Automates” letters. After that the day split into the three rooms. Most of my afternoon photos are from the product sessions.

Morning keynote: the business case

The keynote opened with “Three emerging things to consider”: how enterprises will align IT spending with business conditions, filling the IT skills gap, and accelerating the digital transformation. The main message came next: “Collaboration is the key to automation”, with the subtitle “Unlocking potential, accelerating adoption, and preparing for the next wave of automation with Red Hat Ansible”.

The ROI slide, “…and automation is the key to acceleration”, put a number next to each persona:

• Line of business: $1.13M in new revenue per year
• IT leadership: 498% five-year ROI with 5 months to payback
• Network: 53% reduction in unplanned downtime
• Security: 25% more efficient IT security teams
• Developers: 135% more applications developed per year
• A last line about more productive infrastructure management teams, whose figure the speaker was standing in front of in my photo

The keynote’s ROI slide. The arrow ran from developers at the bottom to the line of business at the top.

The slide didn’t show a source. As far as I can tell the figures come from an IDC study, not a Forrester one. Red Hat’s brief 3 ways Ansible Automation Platform accelerates innovation quotes the same 498% five-year ROI, payback in 5 months, US$1.13 million in additional new revenue and 135% more applications developed per year. Its footnote credits them to “Red Hat Ansible Automation Improves IT Agility and Time to Market”, an IDC White Paper sponsored by Red Hat (Mary Johnston Turner and Harsh Singh, June 2019). So these are vendor-sponsored numbers from a 2019 study, shown on stage in 2023. Treat them as a starting point for your own business case, not as a benchmark.

The Automation Maturity Curve and “Operations as Code”

Two slides from the keynote have stayed with me. The Automation Maturity Curve drew effort per change falling as maturity rises, across three stages:

• Crawl: simplify a task. Speed, scale and reliability, then standard onboarding and a reliable release process.
• Walk: centralise domain automation. Team autonomy, testing frameworks, expanded external integrations and governance-driven RBAC.
• Run: orchestrate across domains. Cross-team workflows, end-to-end automation provisioning, automation first across silos, and at the top event-driven automation, self-healing infrastructure and AIOps.

The next slide, “Where we see the market going”, split the lifecycle into Day 0 + Day 1 (Infrastructure as Code: build, provision, configure and deploy with an automation-first mindset, extended to more IT domains such as network, edge and cloud) and Day 2 (Operations as Code). The Day 2 box had three bullets: “Standardize operations processes IT-wide”, “Observability is easy, remediation is hard” and “A skills vacuum is coming soon”. The arrow along the bottom ended in “end-to-end automation across the entire lifecycle”.

Left: the Automation Maturity Curve. Right: Day 2 “Operations as Code”.

My take: “Observability is easy, remediation is hard” was the line of the day for me. In my view, most organisations already have more dashboards and alerts than they can act on. What they lack is a safe, reviewed path from an alert to a fix. That is the gap Event-Driven Ansible was built for. I’ve written about how I approach it in Event-Driven Ansible: reactive automation and Event-Driven Ansible for automated incident response.

Content you can trust: Certified, Validated and signed

The keynote then moved to content. One slide set Red Hat Ansible Certified Content (“What do I want to automate?”) against Ansible Validated Content (“How should I automate it?”). Validated content was described as an opinionated path for performing operations on Red Hat and third-party platforms, from Red Hat and trusted industry partners, tested for security, quality and reliability, and “now preloaded in private automation hub”.

The next slide, “The end-to-end trusted automation supply chain”, showed signed and certified Ansible content collections flowing from automation hub to private automation hub, alongside execution environments and Ansible content collections. From there they went to automation controller, which enforces signed content, and out through automation mesh via a hop node to the execution nodes.

Certified versus Validated content, and the signed supply chain from hub to execution node.

The keynote also claimed a place in the analyst rankings. A slide read “Red Hat is a leader in the 2023 Forrester Wave™: Infrastructure Automation”, citing The Forrester Wave™: Infrastructure Automation, Q1 2023, with the quote “Red Hat leverages its strong open source community to power innovation.” Red Hat’s own write-up is A deeper look: Red Hat named a Leader in the Forrester Wave.

Because Intel co-hosted the event, there was a partner slot too. “Intel Cloud Optimizer by Densify” described ML-based analysis of workload patterns and configurations that generates recommendations to optimise the size and type of infrastructure in use. According to the slide, Densify gives visibility into VMs or OpenShift containers and recommends resource selection for “improved performance, stability, and lower cloud spend”.

Ansible Lightspeed: from the keynote roadmap to a live demo

In July 2023 Ansible Lightspeed with IBM Watson Code Assistant was still a technical preview. The keynote slide “The Ansible Lightspeed experience: Enhancing Playbook creation” described it as “a generative AI service accessed via the Ansible VSCode extension” and said a tech preview was “now available to all Ansible users”. The stack on the right ran from Ansible Lightspeed to watsonx.ai and Watson Code Assistant, then Red Hat OpenShift AI, then Red Hat OpenShift.

A second slide, “Ansible Lightspeed brings generative AI to Playbook development”, showed four capabilities under the banner “Features on roadmap for upcoming commercial offering”: generating playbook content from a natural language request, content discovery (“Find me a playbook or role similar to what I’m writing”), content optimisation (“Review my playbook and help make it better”) and content explanation (“Tell me what this playbook is doing – and its impact”).

The keynote’s Lightspeed architecture and the roadmap toward a commercial offering.

The afternoon session and live demo

The full Lightspeed session came later, in one of the breakout rooms. It opened with “The AI revolution has come to automation”: better code, efficient coding, more focus on automation outcomes, bridging skills gaps, expanding into new automation domains and being “accessible with natural language”. The slide ended with “Improved overall efficiency of an organization’s automation efforts, improving ROI and time to value.”

The “Generating Ansible Lightspeed suggestions” slide walked through the workflow with a firewall example (- name: Permit HTTPS through firewall):

1. Write the prompt in the Ansible task description.
2. Press Enter at the end of the task description line to request a suggestion.
3. Press Tab to accept it, and the playbook task is generated automatically.
4. Press Esc to reject it. Rejected suggestions feed analytics that train the model.
5. Modified suggestions are also used to train the model.

The suggested task used ansible.posix.firewalld with service: https, permanent: true and state: enabled.

The suggestion lifecycle: prompt, accept or reject, then generate or modify.

The demo itself, “Lightspeed demo overview: Deploy monitoring software”, followed a simple flow: create playbooks with Ansible Lightspeed, commit them to a Git repo, run the automation from automation controller and deploy RHEL monitoring. The presenters wrote a playbook to install Cockpit on RHEL hosts, copy cockpit.conf into /etc/cockpit/, start and enable the service, and wait for port 9090.

Some details from the recording I made in the room:

• Setup is just the Ansible extension for VS Code: enable Ansible Lightspeed in the extension settings and log in. During the preview, access worked through a GitHub account. When someone asked about cost, the presenters said there was no pricing at that stage and that the goal was to keep the community version free for Ansible users.
• Natural-language task names drive the suggestions. Changing the task name to “Install cockpit package on RHEL” produced a when: ansible_distribution == 'RedHat' condition, which shows up in the screenshot below.
• Context awareness. After a module_defaults section was uncommented at the top of the play, the next ansible.builtin.service suggestion dropped state: started and enabled: true, because the play already set them as defaults.
• Best-practice post-processing. The generated tasks used fully qualified collection names, and the ansible.builtin.copy task included mode: '0644', which the presenters called out as a best practice for file operations.
• ansible-lint in the editor. The same extension ran ansible-lint as real-time feedback. One warning on screen explained that a missing or unsupported mode parameter can cause unexpected file permissions.

The Cockpit demo playbook in VS Code, built task by task from natural-language names.

The feature I found most important was content source matching, which the session described as “Transparency, collaboration, and trust”. Beside a suggestion, the extension’s “Ansible Lightspeed Training Matches” panel listed the potential source URL, author, type and licence of similar content from the training data. In the session’s example, the match pointed to RedHatOfficial rhel8_pci_dss content on Ansible Galaxy.

My take: Lightspeed’s design fits the way good playbooks are already written: name the task in plain language first, then pick the module. The two things I’d tell any team adopting an AI assistant for Ansible are the same ones the demo hinted at. First, keep ansible-lint in the loop, because generated code is still code you have to review. Second, care about provenance. Content source matching was the right instinct in 2023 and it still is. My Ansible Lightspeed tutorial covers the current setup, and Ansible Lightspeed Enterprise covers the watsonx Code Assistant side.

At the event I also recorded two short interviews for Ansible Pilot: Craig Brandt of Red Hat on Ansible Lightspeed, and Mark Bolwell of MindPoint Group on Ansible Lockdown.

Event-Driven Ansible: rulebooks, a live remediation and the roadmap

The Event-Driven Ansible (EDA) session was the most hands-on of the day. The demo used a rulebook called london-automates-dynatrace.yml. It normalised the incoming event keys with the ansible.eda.normalize_keys filter and then defined OS service monitoring rules. The Windows rule fired when a Dynatrace problem was open and its ranked events matched “Auto-start Windows OS Services”:

rules:
  - name: Windows OS Service Monitoring
    condition: event.payload.State == "OPEN" and event.payload.ProblemDetails.rankedEvents is search("Auto-start Windows OS Services")
    action:
      run_job_template:
        name: Windows EDA Dynatrace Service Restart
        organization: Default

A matching Linux rule called a Linux restart job template. In the EDA controller UI, projects were described as “a logical collection of rulebooks”, and the rulebook activation was shown running. The job output then showed tasks to restart the Windows service and to move the incident to “in progress”. That is the keynote’s loop from observability to remediation, done live.

The demo rulebook: a Dynatrace event condition mapped to a job template that restarts the service.

The “Event-Driven Ansible integrations and roadmap” slide listed certified and validated content expected in Q2 and Q3 2023: Cisco NX-OS, Cisco ThousandEyes, CrowdStrike, CyberArk, Dynatrace, F5, IBM Instana and IBM Turbonomic, Palo Alto Networks, Red Hat Insights, Red Hat OpenShift, ServiceNow and Zabbix. The same box listed event sources for AWS SQS, Azure Service Bus, GCP Pub/Sub, Kafka (AMQ Streams), Prometheus/Alertmanager, webhooks, watchdog (file system watcher), url_check, range and file. Community content listed Arista. The roadmap for integrations promised additional ITSM solutions and additional observability and monitoring tools.

EDA integrations as of mid-2023.

The session closed with three key technical learning resources: the Event-Driven Ansible interactive labs, technical blogs (one example was a post on creating custom Event-Driven Ansible source plugins) and the Ansible Rulebook documentation.

Platform track: Builder 3.0, Private Automation Hub and automation mesh

The platform track filled in the “how” behind the keynote’s supply-chain diagram.

How you build. A slide titled “How You Build: Using Execution Environments, Collections” summarised the pipeline:

• Build execution environments with Builder 3.0. “CLI updated, new Hub wizard coming in AAP 2.5”.
• Build collections with ansible-galaxy collection build.
• Publish to Private Hub, described as secure storage for collections, images and signatures.

A related slide covered partners. Under “When we share the same customer”, a Private Partner Hub can replicate its content to the customer’s existing AAP private automation hubs. The example repositories showed per-partner staging, published and rejected states.

Builder 3.0 and Private Hub, then automation mesh.

Automation mesh got its own explainer: “Simple, flexible and reliable scaling of execution capacity”. It covered automating at a global scale across large inventories and diverse network topologies, a distributed overlay network with peer-to-peer connections between execution nodes across existing networks, and a flexible architecture with more design choices than isolated nodes. The diagram put automation controller on top of the mesh, with a hop node and execution nodes in a remote office, the cloud and a data centre.

The track ended with “Automation Analytics – Embedded Analytics Within Controller UX”, a mock-up of a dashboard inside the AAP navigation with job status, recent jobs, recent templates and reports tabs, and a featured report charting jobs across organisations over time.

Automation Analytics embedded in the controller UI, as previewed in 2023.

My take: The “new Hub wizard coming in AAP 2.5” line is a good reminder that execution environments were the hardest part of AAP 2.x for many teams. Packaging Python and system dependencies, signing and publishing them, and keeping them in sync across hubs is real platform work. The building blocks shown in London (Builder, private hub, signatures, mesh) are still at the core of AAP today. See Ansible collections best practices and my notes on the AAP 2.7 automation portal and Execution Environment Builder.

Looking back from 2026: what shipped

Much of what was “roadmap” in that room has since shipped. Official sources:

• Event-Driven Ansible was already announced as generally available as part of AAP 2.4 (Red Hat press release, 23 May 2023), with availability slated for June 2023. So the London EDA sessions were already about adoption, integrations and roadmap.
• Ansible Lightspeed went from technical preview to general availability. Red Hat’s 1 November 2023 press release says Red Hat Ansible Lightspeed “is now generally available with your Ansible Automation Platform subscription, with IBM watsonx Code Assistant available for purchase separately”.
• AAP 2.5 became generally available on 30 September 2024 (Red Hat blog). It brought a unified UI that gives “a consistent and centralized WebUI, API, authentication, authorization and role based access controls (RBAC)”, plus event streams for routing events to rulebook activations.

If you’re still on an older release, my AAP 2.6+ upgrade and EOL guide covers the path, and Event-Driven Ansible: 12 new collections in 2026 shows how far the integration list on that 2023 slide has grown.

Me next to the Ansible “A” at CodeNode, late in the afternoon.

Two months later I was on stage myself at Ansible Community Day Berlin 2023. If your team is planning an AAP upgrade, an EDA rollout or a Lightspeed pilot, that is the kind of work I help with.

Related

• Event-Driven Ansible: Reactive Automation
• Ansible Lightspeed Tutorial
• Upgrading to Ansible Automation Platform 2.6+ (EOL Guide)
• Ansible Community Day Berlin 2023