← Back to all selected work
JavaQuarkusPostgreSQLAnsibleOpenSSHsystemdGSoC 2026

Host-Based Pipeline Deployment for the Debezium Platform

Extending change data capture to bare metal and cloud VMs through zero-touch host discovery, concurrent scheduling, and Quarkus CDI selection.

Organization Debezium (Red Hat)
Role Google Summer of Code 2026 Contributor
Timeline May 2026 - Sep 2026
10m 43s Pipeline Runtime
~500 MB Image Pre-pulled
7 Sub-issues Scoped Issues
24 Unit Tests SSH Parser Tests
6 REST Endpoints Daemon Endpoints

Provisioning Pipeline Flow

01

Edit ~/.ssh/config

Engineer declares target host IP, port, identity file, and SSH parameters.

02

Host Discovered

Java NIO WatchService detects file modification with debounce and triggers reconciliation.

03

Ansible Provisions

Isolated thread pool triggers idempotent Ansible playbook, verifies systemd daemon, and pre-pulls ~500MB image.

04

Host Marked READY

Health checks pass, bearer tokens exchange, and conductor marks pipeline node READY in 10m 43s.

Context & Engineering Challenge

Debezium is the leading open source distributed platform for Change Data Capture (CDC). Previously, Debezium Server pipelines could be orchestrated exclusively through its Kubernetes operator. This architectural constraint excluded engineering organizations operating high-throughput databases on bare-metal clusters, non-containerized private clouds, or dedicated virtual machines.

Hard Constraints

The host-based deployment path had to ship from the exact same compiled binary image as Kubernetes mode, requiring zero breaking configuration changes for existing enterprise users. Remote Ansible deployment tasks could not block conductor threads, and concurrent host provisioning required strict deadlock prevention.

System Architecture

DEBEZIUM PLATFORM CONDUCTOR ~/.ssh/config WatchService Java NIO debounced file events Sorted Pessimistic Lock Scheduler Prevents DB deadlocks & port collisions Isolated Ansible Thread Pool Idempotent provisioning execution REMOTE BARE METAL / VM HOST Host Agent Daemon (Quarkus) systemd unit · 6 REST endpoints • Returns 202 Accepted (Non-blocking) Debezium Server Container Pre-pulled image (~500 MB) Source DB WAL → Event Stream

Architecture Decisions & Trade-offs

Quarkus CDI Selection (@LookupIfProperty)

Leveraged Quarkus @LookupIfProperty to select deployment orchestrators at build/runtime without polluting the core engine with conditional runtime branches. This enables a unified container image with dead-code elimination.

Alternatives Evaluated: Considered runtime reflection and factory patterns; rejected due to increased startup overhead and loss of GraalVM native image compatibility.

Zero-Dependency OpenSSH Config Parser

Implemented a custom OpenSSH config parser fully covering the ssh_config(5) specification backed by 24 unit tests, paired with a Java NIO WatchService with debounce and scheduled reconciliation.

Alternatives Evaluated: Evaluated JSch and Apache MINA SSHD; rejected due to heavy transitive dependencies and incomplete handling of Host / Match blocks.

Deadlock-Safe Scheduling with Sorted Locks

Eliminated database deadlocks and port collisions in high-concurrency environments by implementing sorted PESSIMISTIC_WRITE locks combined with atomic file operations and Command-pattern Ansible runners.

Alternatives Evaluated: Considered optimistic locking with retry backoff; rejected because provisioning conflicts caused wasted compute and partial disk allocations.

Asynchronous Host Agent Daemon

Architected a lightweight Quarkus daemon deployed via systemd exposing 6 REST endpoints with bearer-token authorization. Endpoints return 202 Accepted immediately so slow multi-gigabyte remote deployments never block central conductor threads.

Alternatives Evaluated: Considered direct synchronous SSH command execution from the orchestrator; rejected because long-lived SSH connections dropped under network jitter.
RETROSPECTIVE & FUTURE DIRECTIONS

What I would do differently

TODO: Divyanshu to reflect on future enhancements (e.g. gRPC streaming telemetry vs REST polling, multi-tenant agent isolation).