0.8 halifax-2026 2026-09-29 2026-09-29 1 00:05 https://talks.devopsdays.org America/Halifax Volta HQ Regular Talk 2026-09-29T09:30:00-03:00 09:30 01:00 As adoption of the Model Context Protocol (MCP) accelerates, many teams are building MCP servers using familiar API design patterns - CRUD-style tools, exposed resources, and thin wrappers over existing APIs. While this approach can function, it does not maximize the value MCP is designed to unlock. MCP is not an API replacement; it introduces a different model built around capabilities, constraints, and agent-driven orchestration. This talk explains why API-oriented designs limit MCP’s effectiveness, even when they “work”. We’ll contrast traditional API principles, where deterministic clients orchestrate workflows with MCP design principles, where autonomous agents reason over narrowly scoped capabilities. Using vendor-neutral examples from deployment and operations workflows, I’ll show how to design MCP tools that are minimal, safe, and agent-native, and clarify when MCP provides more value than an API. halifax-2026-6477-design-principles-api-vs-mcp Artificial intelligence (AI) and Machine Learning (ML) RobBarnes en 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. false https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/ https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/feedback/ Volta HQ Regular Talk 2026-09-29T10:30:00-03:00 10:30 00:30 It’s been 14 years since the 12-Factor App methodology emerged to meet the needs of developers and operation teams alike, and yet unlike many other things in our industry, it’s still relevant!. In fact, it’s so fundamental to the “cloud-native” paradigm, you probably don’t even notice your level of adherence on a regular basis. The flip side to this however, is that you also don’t notice how much is skipped over―the realm of Platform Engineering is no exception to this matter. This talk demonstrates embedding 12-Factor design principles into a command line interface (CLI) tool used for Platform Engineering―written in pure Go. We’ll also highlight some imperfections of this strategy. halifax-2026-6680-building-a-platform-engineering-cli-tool-with-12-factor-principles Open source tools and technologies Ruckus Voxi en 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). false https://talks.devopsdays.org/halifax-2026/talk/RJFCGA/ https://talks.devopsdays.org/halifax-2026/talk/RJFCGA/feedback/ Volta HQ Regular Talk 2026-09-29T11:00:00-03:00 11:00 00:30 As CI/CD adoption grows, so does complexity. As companies grow, developers who don't stop to think about managing complexity eventually hit the wall: CI/CD pipelines that support dozens of use cases have become so intricate that changing them without breaking something turns into trial and error. Pipelines must be run to be tested. With enough conditional logic, exhaustively testing every path becomes impossible. In an industry experience, one team I worked with maintained ~1,000 test projects they ran on a 24-runner farm that took a full day to execute, limiting them to one pipeline change per day. This is not the velocity DevOps has promised. This talk introduces a different model: generating pipelines programmatically. By treating pipelines as a software engineering problem rather than YAML files, you can unit test pipeline logic, apply TDD, and use regression testing, all without running the CI engine. I'll explore how we can implement pipeline generators on GitHub and GitLab, and explore "YAML-less" pipelines that drop the CI-engine dependency entirely, and connect this to the broader shift seen in tools like Pulumi and Dagger. halifax-2026-6746-beyond-configuration-rethinking-ci-cd-with-code-generated-pipelines Automation Alexandre-Xavier Labonté-Lamoureux en 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. false https://talks.devopsdays.org/halifax-2026/talk/CPDUYE/ https://talks.devopsdays.org/halifax-2026/talk/CPDUYE/feedback/ Volta HQ Regular Talk 2026-09-29T11:30:00-03:00 11:30 00:30 Container images ship with hundreds of packages you didn't choose, each one a potential vulnerability. When AI-assisted security research began surfacing real CVEs at an unprecedented rate, we had to rethink how our supply chain worked from the ground up. This talk is the story of building a fully autonomous container supply chain that monitors upstream releases, detects vulnerabilities before CVEs are published, generates package updates, builds across architectures, runs tests, and ships patched images — processing roughly 1,000 merge requests per week without a human clicking approve. I'll share the architecture decisions that worked, the ones that didn't, and the surprising non-technical problems we had to solve along the way. You'll leave with practical patterns you can apply to your own pipelines: RPM lockfiles for deterministic builds, reproducible builds that let anyone verify your output, policy-driven automation boundaries that separate "the machine handles this" from "a human needs to look," and the guardrails that make autonomous merging safe rather than reckless. halifax-2026-6759-1-000-merge-requests-a-week-and-nobody-clicked-approve Security Scott Hebert en 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. false https://talks.devopsdays.org/halifax-2026/talk/U3QTY3/ https://talks.devopsdays.org/halifax-2026/talk/U3QTY3/feedback/ Volta HQ Open Spaces 2026-09-29T13:00:00-03:00 13:00 00:30 Incorporating accessibility into your code and designs? Make it easy. The W3C has released the Accessibility Roles and Responsibility Mapping (ARRM) framework for WCAG 2.2. ARRM breaks down the WCAG success criteria list into individual, plain-language tasks ("checkpoints") for Front-end Developers, UX and Visual Designers and Content Authors to do. It help teams identify the primary, secondary and contributor owners of web accessibility requirements and best practices by role. It's an official, ready-made, go-to resource your team can start using tomorrow. halifax-2026-6749-w3c-arrm-a-ready-made-accessibility-roles-responsibilities-map-for-developers Collaboration Jennifer Chadwick, CPACC en 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. false https://talks.devopsdays.org/halifax-2026/talk/AZJZR8/ https://talks.devopsdays.org/halifax-2026/talk/AZJZR8/feedback/ Volta HQ Regular Talk 2026-09-29T13:30:00-03:00 13:30 00:30 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. halifax-2026-7223-building-effective-sandboxes-for-running-untrusted-llm-generated-code Artificial intelligence (AI) and Machine Learning (ML) Vagmi Mudumbai en 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. false https://talks.devopsdays.org/halifax-2026/talk/ZLMDAB/ https://talks.devopsdays.org/halifax-2026/talk/ZLMDAB/feedback/ Volta HQ Regular Talk 2026-09-29T14:00:00-03:00 14:00 00:30 [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. halifax-2026-7225-developing-security-systems-using-network-programmability Security Dr. Israat Haque en [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. false https://talks.devopsdays.org/halifax-2026/talk/TULQWP/ https://talks.devopsdays.org/halifax-2026/talk/TULQWP/feedback/ Volta HQ Regular Talk 2026-09-29T14:30:00-03:00 14:30 00:30 Your scanner found multiple vulnerabilities in your base image this morning, and your release is blocked until every one of them is triaged out of the queue. Most of them will never be fixed, and for most of them that is the correct outcome. The catch: you work on government code, so you can't hand the problem to the tools built to solve it. The agentic CVE-analysis platforms want to embed your source. The good commercial suites cost real money and still phone home. And the rules about AI and sensitive code are only getting tighter. So this talk is about a question I had to actually answer on a live government program: how do you supercharge vulnerability triage using the most powerful tools available, without a single byte of privileged code or infrastructure leaving your boundary? halifax-2026-6650-the-audit-proof-way-to-ignore-a-cve Security Charl Cilliers en 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. false https://talks.devopsdays.org/halifax-2026/talk/98ZJQE/ https://talks.devopsdays.org/halifax-2026/talk/98ZJQE/feedback/ Volta HQ Open Spaces 2026-09-29T15:30:00-03:00 15:30 01:00 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/ halifax-2026-7224-open-space Open Spaces Everyone en 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/ false https://talks.devopsdays.org/halifax-2026/talk/UARNZ3/ https://talks.devopsdays.org/halifax-2026/talk/UARNZ3/feedback/ Volta HQ Regular Talk 2026-09-29T16:30:00-03:00 16:30 00:30 AI agents are non-deterministic. They hallucinate, vary every run, and surprise you. The industry keeps trying to constrain them. I take the opposite approach: let agents run fully autonomous inside deterministic durable function workflows that guarantee the pipeline always completes. You already know how to operate deterministic workflows. Now use that skill to tame AI. halifax-2026-6324-let-agents-run-wild-inside-deterministic-guardrails Serverless Computing Eric D Johnson en 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. false https://talks.devopsdays.org/halifax-2026/talk/SKDQMM/ https://talks.devopsdays.org/halifax-2026/talk/SKDQMM/feedback/ Volta HQ Regular Talk 2026-09-29T17:00:00-03:00 17:00 00:30 Alert Fatigue is real, and it impacts your team's ability to make decisions about the information they are seeing about your environment. Too many alerts, false positives, alerts that have been over-prioritized, all accumulate and overwhelm already busy teams. Improving your alerts and employing better methods for dealing with real-time information will spare your team and improve customer experience. halifax-2026-6692-tackling-alert-fatigue-with-slos-automation-and-machine-learning Other Kat Gaines en 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. false https://talks.devopsdays.org/halifax-2026/talk/T9KEY3/ https://talks.devopsdays.org/halifax-2026/talk/T9KEY3/feedback/