OSS + ELC EU 2026

Declarative infrastructure promises reproducibility: desired state is defined, controllers reconcile drift, and redeployments should behave predictably.

Except they often don’t.

This talk explores the hidden operational state declarative systems quietly depend on: webhook certificates cached in cluster resources, infrastructure dependencies that survive deletion, controller ordering assumptions, persistent node state, and lifecycle coupling reconciliation engines cannot see.

These problems become especially visible when infrastructure spans multiple systems or workloads take minutes rather than seconds to initialize.

Using real operational examples from Kubernetes and GitOps environments, this lightning talk examines why “delete and redeploy” frequently fails to produce clean state and why many reliability problems are actually hidden state-management problems.

The core lesson: declarative systems still depend on operational history, even when the infrastructure appears fully declarative.

A pull_request_target trigger plus ref: ${{ github.event.pull_request.head.sha }} in a checkout step. That combination lets any external contributor run arbitrary code with your repository's secrets and write token. This is the "pwn request" pattern, and it's in production workflows across some of the most popular open-source projects on GitHub.

I'll use a real finding (a CRITICAL-severity pwn request I discovered and privately disclosed in an Apache project) to explain how the attack works: what pull_request_target does differently from pull_request, why adding permissions: read-all doesn't protect you, and why the attacker needs nothing beyond opening a pull request.

Then I'll show the three mitigations that work: splitting into unprivileged build and privileged post-processing steps, using persist-credentials: false, and gating on the head repo matching the base.

Cluster API (CAPI) is by now a relatively mature project with many adopters using it in production already for years. Despite this, or perhaps rather thanks to it, CAPI keeps evolving, growing and adding new features. In this session, I'll present one of the most recent features: in-place updates.

In-place updates marks an important change to a fundamental assumption in CAPI. Traditionally, the Machines were considered mostly immutable. Any change required a replacement where new Machines were created and old Machines deleted. This method of operation has served CAPI well, and continues to do so, but it is not without pain points. With in-place updates, it is now finally possible to avoid replacement. This opens the door for unique use-cases and solutions, such as Talos, where each node's lifecycle can be managed through a built-in controller in the node itself.

Come learn about this new feature in CAPI, and how to make use of it!

Everyone claims their app is cloud-native. But how to prove it?

CNTi Testsuite, an open-source Linux Foundation project, provides automated tests that validate cloud-native best practices such as security, scalability, and upgradability. While designed for telecom CNFs, it works for any Kubernetes application.

In this lightning talk, I’ll show how you can run CNTi Testsuite in minutes to objectively measure cloud-native maturity and uncover hidden gaps in Kubernetes workloads.

The GenAI observability space is fragmented right now. OpenInference, OpenLLMetry, framework-specific conventions are all solving the same problems with incompatible attribute names. That made sense when OTel’s GenAI support was thin. It makes less sense today.

OTel is where this converges. Getting there from where most teams actually are isn’t obvious. Kasper and Adriana cover the current landscape, how the genainormalizer processor bridges the gap at the collector layer, and what a realistic path to OTel-native GenAI observability looks like.

Then the harder question: your agent just deleted a database. What does your telemetry actually tell you? Non-deterministic systems don’t leave obvious footprints, and most teams discover that at the worst possible time.

Uber runs about 4 million containers on over 150,000 hosts. Our fleet includes a mix of cgroupv1 and v2 hosts, multiple cloud providers, and multiple Linux kernel versions. Tracking container performance at this massive scale is a difficult engineering challenge, including the cost of storing them. We currently process 60 million data points every second to keep everything running smoothly.

We run Cadvisor and open-source Nvidia and AMD GPU metrics exporters to reliably and affordably collect and store these metrics. This infrastructure is vital for our real-time autoscaling, which ensures our services stay online. We also use these metrics to track memory usage and keep costs low for our AI workloads. Despite maintaining all the critical use cases, we have saved around $ 4 million compared to last year by changing how we collect and store data.

We will share how we use these metrics to detect and prevent system failures before they affect users. Attendees will learn practical patterns for operating container metrics at scale. We will also discuss the hard lessons we learned while building a reliable metrics system for a complex global fleet.

The telco industry has been on a cloudification journey for over a decade. In the context of Radio Access Networks (RAN), this deep transformation is primarily driven by Open RAN initiatives. This talk illustrates how RAN is gradually embrassing cloud native benefits. Key synergies between Sylva and Duranta open-source projects are driving this transformation:
- Sylva provides a telco-grade cloud stack, enabling scalable and reliable cloud infrastructure.
- The Duranta project focuses on developing RAN network functions using cloud-native design patterns to promote innovation and interoperability.

A live demo will highlight the role of Open RAN interfaces in Duranta. It will showcase a FluxCD-based GitOps deployment of Duranta’s Open RAN Distributed Unit (O-DU), Centralized Unit Control Plane (O-CU-CP), and Centralized Unit User Plane (O-CU-UP) network functions on a Telco Cloud. The deployment will follow the Sylva GitOps approach. Sylva will orchestrate multiple Telco Clouds to showcase central, regional, and far-edge deployment scenarios across two labs located approximately 1,000 km apart.

Have you ever run a global pattern search or database scan across a large cluster, only to watch your application latency skyrocket and healthy nodes suddenly drop offline?

When applications outgrow a single instance, global data scanning becomes a major distributed systems bottleneck. High-level frameworks try to mask this complexity with simple abstractions, forcing the client driver to execute a "scatter-gather" pattern: fanning out parallel cursor queries to thousands of logical shards and merging the reactive results on the fly. If designed naively, a single slow shard or an unindexed query can exhaust the client's connection pool, leak memory, and starve production read/write traffic.

In this practical, code-focused session, we will open up the engine hood of high-performance drivers using live examples from the Valkey-Glide ecosystem. We will show you how to safely bridge high-level data abstractions down to sharded sockets without risking cascading timeouts.
Come Join us, to build Resilient Cluster Scans Without Starving Shards!