2.0 -//Pentabarf//Schedule//EN PUBLISH HHRBLC@@talks.devopsdays.org -HHRBLC Design Principles: API vs MCP en en 20260929T093000 20260929T103000 010000

Design Principles: API vs MCP

Many organizations are approaching MCP server design by exposing existing APIs through MCP with minimal adaptation. The result is often a collection of CRUD tools, thin API wrappers, and overly broad capabilities that technically function but provide limited value to AI agents. This session examines the architectural differences between traditional APIs and MCP and explains why design approaches that work well for human-operated systems frequently become anti-patterns when applied to agent-driven workflows. The talk introduces four practical MCP design principles: - Capabilities, Not Primitives - Intent-Based Interfaces - Minimal Capability Surfaces - Observable Operational Intent Attendees will see how these principles influence tool design, authorization models, operational safety, and agent reasoning. The session also explores common MCP anti-patterns, including CRUD tools, thin API wrappers, and overexposed power, demonstrating how they increase complexity and reduce the effectiveness of AI agents. Rather than focusing on a specific vendor, framework, or implementation, the talk uses real-world deployment and operations scenarios to illustrate the concepts. Attendees will leave with a practical framework for deciding when MCP is appropriate, how to structure MCP tools effectively, and how to build systems that are both agent-friendly and operationally safe. This session is intended for platform engineers, API designers, infrastructure engineers, and developers who are building or evaluating MCP servers and want to move beyond simply exposing existing APIs to creating truly agent-native capabilities. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/ Volta HQ RobBarnes PUBLISH RJFCGA@@talks.devopsdays.org -RJFCGA Building a Platform Engineering CLI Tool with 12-Factor Principles en en 20260929T103000 20260929T110000 003000

Building a Platform Engineering CLI Tool with 12-Factor Principles

Demonstration and building patterns for scalable, production-grade CLI tools with 12-factor app methodology―the demo relates it to cloud-native Platform Engineering. Tooling used (Golang) includes Cobra for the CLI library, Viper as a decoupled configuration solution, and oapi-codegen for generating a client library from OpenAPI 3.0 spec, as to demonstrate some fruits of spec-driven design that don't require LLMs (or even GPUs for that matter). PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/RJFCGA/ Volta HQ Ruckus Voxi PUBLISH CPDUYE@@talks.devopsdays.org -CPDUYE Beyond Configuration: Rethinking CI/CD With Code-Generated Pipelines en en 20260929T110000 20260929T113000 003000

Beyond Configuration: Rethinking CI/CD With Code-Generated Pipelines

CI/CD pipelines start simple, but as organizations scale, they become sprawling YAML configurations. They become brittle, hard to test, and even harder to change. This is even the case in organizations when templates are used to manage complexity. This talk introduces a different approach: generating pipelines programmatically using a general-purpose programming language. Rather than maintaining hand-written YAML files, a pipeline generator produces CI/CD configurations as an output, the same way a compiler translates source code to machine code. This makes pipeline logic unit-testable, enables Test-Driven Development and opens the door to regression testing without ever running the CI engine. The pipeline generator produces a CI/CD configurations solely from analyzing a software project. For example, the presence of a "pom.xml" file indicates the programming language, the build system and the presence of third-party dependencies. This approach is part of a broader industry shift already visible in tools like Pulumi (infrastructure as code), Dagger (container builds without Dockerfiles) and Paketo Buildpacks. Real-world adoption in 2018 in a music streaming company has shown up to 2x gains in developer efficiency, with teams better equipped to respond to incidents like Log4Shell through enforced golden paths. This approach has been kept under wraps until now. Attendees will leave with a concrete mental model and techniques for implementing pipeline generators on GitHub and GitLab, and their own system which doesn't use YAML at all. Attendees will be left with a new perspective where CI/CD is treated as a software engineering discipline. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/CPDUYE/ Volta HQ Alexandre-Xavier Labonté-Lamoureux PUBLISH U3QTY3@@talks.devopsdays.org -U3QTY3 1,000 Merge Requests a Week and Nobody Clicked Approve en en 20260929T113000 20260929T120000 003000

1,000 Merge Requests a Week and Nobody Clicked Approve

The CVE landscape is changing fast. AI-assisted vulnerability discovery is pushing annual **CVE counts** past **60,000** and accelerating. Firefox fixed 423 security bugs in April 2026 alone — more than the previous 15 months combined. Traditional approaches to container patching — wait for a scanner report, open a ticket, assign someone, review, merge, release — **cannot keep up with this volume**. **Project Hummingbird** is **Red Hat's** answer to this problem: minimal, distroless container images with a fully autonomous supply chain. As the Builds and Releases workstream lead, I've spent the past year building the pipeline that makes near-zero CVE images possible at scale. This talk is not a product pitch — it's the engineering story behind the automation, told through the failures and surprises we encountered. I'll cover four main areas: **1. Why autonomous?** The math that convinced us humans-in-the-loop wouldn't scale. How we quantified the gap between CVE discovery rate and our team's patch throughput, and why "hire more people" wasn't a viable answer. **2. The architecture.** Hermetic builds with pinned RPM lockfiles (think Cargo.lock for containers). Two parallel upstream monitoring systems — dist-git sync and direct release watching — that create auto-merge merge requests. A dual-pipeline design where RPM builds feed container builds, each with their own test and validation gates. **3. What went wrong.** Reproducible builds sound simple until you discover RPM database journal modes, non-deterministic package installation ordering, OCI annotation sorting, and a dozen other sources of non-determinism that took months to solve. Policy boundaries that were too loose and too tight before we found the right line. The day we learned why you need a modification_status field on every package. **4. Patterns you can steal.** Lockfile-based dependency pinning for containers. Policy-driven auto-merge with explicit "clean" vs. "modified" classification. Reproducible build verification in CI (rebuild and compare on every merge request). SBOM generation as a build artifact, not an afterthought. This talk is for anyone running containers in production who's tired of triaging base image CVEs. You don't need to adopt our exact toolchain — the patterns are portable to any CI/CD system. First-time attendees and experienced practitioners will both find actionable takeaways. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/U3QTY3/ Volta HQ Scott Hebert PUBLISH AZJZR8@@talks.devopsdays.org -AZJZR8 W3C ARRM: A Ready-made Accessibility Roles & Responsibilities Map for Developers en en 20260929T130000 20260929T133000 003000

W3C ARRM: A Ready-made Accessibility Roles & Responsibilities Map for Developers

Join me, a former UX Designer-turned-Accessibility Strategist, as I host a fun, interactive workshop to: 1) introduce the ARRM Checkpoint List and identify the primary, secondary and contributor responsibilities for Front-end Developers (and the others). 2) share examples of the ARRM checkpoints and how a Primary owner might work with a Secondary owner to ensure an accessibility fix gets done. 3) show you how to conduct the "Role-based Decision Tree" exercise (together or in teams), if an accessibility issue needs to be fixed, but there's no owner yet. Together we'll review some Issue examples, how to fix them, prioritize the fixes and who should own it (primary, secondary, contributor). I'll provide an ARRM Spreadsheet Template to take away. Build capacity, ownership and clarity about who's doing what, when and how. Build a cultural comfort level around accessibility and inclusive design. Meet the WCAG 2.2 guidelines. PUBLIC CONFIRMED Open Spaces https://talks.devopsdays.org/halifax-2026/talk/AZJZR8/ Volta HQ Jennifer Chadwick, CPACC PUBLISH ZLMDAB@@talks.devopsdays.org -ZLMDAB Building Effective Sandboxes for Running Untrusted LLM-Generated Code en en 20260929T133000 20260929T140000 003000

Building Effective Sandboxes for Running Untrusted LLM-Generated Code

As AI code-generation tools shift from auto-complete to autonomous code execution (code mode agents), platform engineers face a critical challenge: How do you safely execute arbitrary, untrusted code on your infrastructure? In this talk, we will analyze the trade-offs of modern sandboxing mechanisms. - Containers vs. MicroVMs vs. V8 Isolates: Performance, boot times, memory footprint, and security boundaries. - Deep Isolation:* Exploring Linux security primitives like* seccomp, eBPF, and ptrace-based sandboxes (sydbox). - Commercial & Open Source Ecosystem: A quick survey of tools like Docker Sandboxes, Apple Containers, E2B, and Daytona. - Decision Framework: A practical rubric to help platform teams choose the right isolation boundary for their specific latency and security profile. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/ZLMDAB/ Volta HQ Vagmi Mudumbai PUBLISH TULQWP@@talks.devopsdays.org -TULQWP Developing security systems using network programmability. en en 20260929T140000 20260929T143000 003000

Developing security systems using network programmability.

[Placeholder abstract] Traditional network security relies on static, perimeter-based controls that struggle to keep pace with dynamic threats and increasingly fluid infrastructure. This talk explores how network programmability — through SDN controllers, programmable data planes (P4), and APIs exposed by modern network fabric — enables security teams to build systems that detect and respond in real time rather than relying on periodic rule updates. We'll walk through practical patterns: using SDN control planes to dynamically reroute or quarantine suspicious traffic, leveraging P4-programmable switches for line-rate anomaly detection without offloading to slower control-plane processing, and building intent-based security policies that compile down to enforceable network state. A live demo will show an automated pipeline that ingests threat signals, computes a network-level response, and pushes updated flow rules to programmable switches in under a second — no manual firewall ticket required. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/TULQWP/ Volta HQ Dr. Israat Haque PUBLISH 98ZJQE@@talks.devopsdays.org -98ZJQE The Audit-Proof Way to Ignore a CVE en en 20260929T143000 20260929T150000 003000

The Audit-Proof Way to Ignore a CVE

Most container CVEs on a Debian base aren't scanner errors. Modern scanners already consume the distribution's advisories and map backported fixes correctly. What they faithfully report is a long tail of vulnerabilities Debian has assessed and marked no-dsa: a documented decision not to issue a stable fix. Dismissing those is defensible, but only if you ground it in that decision rather than your gut, and re-check it when the decision changes, because no-dsa doesn't mean safe, it means someone accountable decided it was minor, and that can lag upstream or be wrong. The catch on government code is doing all this without sending your images or source to a cloud model. The agentic CVE platforms reason brilliantly about whether your code reaches a flaw, by embedding your code. The good commercial suites cost real money and still phone home. And the rules on AI and sensitive code keep tightening. The insight that makes the problem tractable is knowing what's actually secret. A CVE, its package, and Debian's ruling are all public, so the most powerful tools available can synthesize them freely. What's privileged is the join: the fact that your specific protected image, in your protected GitLab instance, behind your gate, contains that package. That mapping never leaves the boundary. You assemble the affected list locally from data only you can see, enrich each public CVE with the best tooling you have, and stitch the result back onto your private findings at home. The model never sees your image, your repo, or the fact that you're the one affected, and it never makes the call. The output is a work order, not a verdict, and it has two halves on purpose. The top half is settled fact: Debian's status with the link, the installed version versus the fixed version, and any place GitLab's stored guidance disagrees with the live source. Every line is independently verifiable, which is what grounds the decision. The bottom half is a tailored exploitability checklist, the right questions to ask before dismissing on exploitability grounds, generated from the public CVE and the generic app context, this is a .NET service on Debian, never from your source. The machine poses the questions; the human answers them inside the boundary. The result is faster triage that never pretends the model determined exploitability, and a structured record that keeps a distribution-grounded dismissal distinct from an internal-judgment one, because an auditor treats those very differently. The reasoning is written back into GitLab alongside the human-readable comment, so the same artifact is both the human's prompt and the auditor's record. Then, on a schedule, every past disposition is re-checked against the current decision and the current image, so a finding you dismissed last spring resurfaces the day its basis changes. The dangerous findings aren't the ones in your queue, they're the ones you already cleared and stopped looking at. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/98ZJQE/ Volta HQ Charl Cilliers PUBLISH UARNZ3@@talks.devopsdays.org -UARNZ3 Open Space en en 20260929T153000 20260929T163000 010000

Open Space

Most devopsdays events are a combination of curated talks and self organized conversations. The self organized content is known as “open spaces”. Open Spaces give attendees the opportunity to talk about anything they’d like. A person might suggest a topic they want to learn about, or one they feel like they can help others with. The topics range widely, from highly technical, to pure culture, to board games for networking. Open space is the simplest meeting format that could possibly work. It is based on (un)common sense of what people do naturally in productive meetings. https://devopsdays.org/open-space-format/ PUBLIC CONFIRMED Open Spaces https://talks.devopsdays.org/halifax-2026/talk/UARNZ3/ Volta HQ Everyone PUBLISH SKDQMM@@talks.devopsdays.org -SKDQMM Let Agents Run Wild — Inside Deterministic Guardrails en en 20260929T163000 20260929T170000 003000

Let Agents Run Wild — Inside Deterministic Guardrails

AI agents in production will hallucinate, take paths you didn't plan for, timeout, contradict themselves, and occasionally return poetry when you asked for JSON. And that's fine. As long as your orchestration is deterministic. We stopped fighting non-determinism and started embracing it. We took our AI agents off the leash and wrapped them in durable function workflows that provide the guardrails: checkpoints, retries, timeouts, exactly-once execution. The agent can go wild inside each step. The orchestrator guarantees the pipeline completes. I walk through a real system where multiple AI agents reason and act autonomously. They take unexpected paths. They fail in creative ways. But the durable function workflow keeps the train on the tracks. It checkpoints state, fans out for parallel work, reconciles results, and recovers from failures automatically. AI in production is not a new operational paradigm. It's a non-deterministic step inside a deterministic workflow. And you already know how to operate deterministic workflows. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/SKDQMM/ Volta HQ Eric D Johnson PUBLISH T9KEY3@@talks.devopsdays.org -T9KEY3 Tackling Alert Fatigue with SLOs, Automation, and Machine Learning en en 20260929T170000 20260929T173000 003000

Tackling Alert Fatigue with SLOs, Automation, and Machine Learning

SLOs allow teams to prioritize the more impactful or important aspects of their services. Metrics that center the user experience gives teams focus and goals. Highlighting the metrics that matter most gives teams space to disable alerts that contribute nothing to overall customer happiness. Automation gives us more hands to deal with more issues without taking time away from more interesting work. Machine Learning tools group alerts together and help add context when things are noisy and distracting. These tools combined help teams tackle a common incident response problem - alert fatigue. Full Service Ownership teams looking to improve the quality of their services can experiment with their SLIs and SLOs to find the work that will benefit their systems the most while also preserving their own sanity. Prevent the stress and anxiety that can arise from unexpected system failures by setting clear expectations and allowing for planned responses to potential issues based on pre-agreed norms. PUBLIC CONFIRMED Regular Talk https://talks.devopsdays.org/halifax-2026/talk/T9KEY3/ Volta HQ Kat Gaines