On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.6.1 has been released and is now available from Maven Central 🎉.

This marks the sixth minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Kubernetes 1.35 support (Timbernetes)
• New Vert.x 5 HTTP client implementation
• OkHttp upgraded to version 5
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Kubernetes 1.35 support (Timbernetes)

This release adds support for Kubernetes v1.35 (Timbernetes), ensuring you have access to the latest API resources and CRDs.

New Vert.x 5 HTTP client implementation

A new Vert.x 5 HTTP client implementation has been added with improved async handling and WebSocket separation. The kubernetes-httpclient-vertx-5 module includes a runtime check for Vert.x 5 classes to provide a clear error message when a Vert.x 4/5 conflict occurs.

The HTTP client factory priority has also been fixed: VertxHttpClientFactory (the default) now has priority -1, while OkHttpClientFactory is restored to priority 0.

Note that the kubernetes-httpclient-vertx (Vert.x 4.x) and kubernetes-httpclient-vertx-5 (Vert.x 5.x) modules are mutually exclusive and must not be included together in your project dependencies. When using Vert.x 5, exclude the default Vert.x 4 client and add the Vert.x 5 module:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <exclusions>
    <exclusion>
      <groupId>io.fabric8</groupId>
      <artifactId>kubernetes-httpclient-vertx</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-httpclient-vertx-5</artifactId>
</dependency>

OkHttp upgraded to version 5

OkHttp has been upgraded from version 4.12.0 to 5.3.2. This update removes internal API usage and fixes deprecated OkHttp 5 calls. While the versions are binary compatible, the major version upgrade might cause side effects in some projects.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.6.1</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.6.1"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

Introduction

In December 2025 I wrote about becoming a coding orchestrator, shifting my role from implementer to someone who directs multiple AI coding agents working in parallel. The productivity gains were real, but so was the chaos.

Running 5 to 10 Claude Code sessions across multiple machines, different projects, and various git branches quickly became unmanageable. I'd forget about sessions, lose track of what was running where, and sometimes only rediscover abandoned work hours or days later.

Terminal tabs and tmux solve local organization. They do not solve cross-device visibility. I needed a single view of everything, so I built a dashboard.

The Problem: Orchestrating Without Visibility

My daily setup involves a MacBook for on-the-go work and a Linux workstation for heavier tasks. On any given day, I might have Claude Code sessions running across both machines, each tackling different tasks in different projects and branches.

The cognitive overhead of tracking which agent is doing what, on which machine, adds up fast. You have to remember which terminal window maps to which project, which branch each agent is working on, whether a session is still active or has stalled, and whether the agent is waiting for permission or has already finished.

Without a centralized view, the orchestrator workflow I described in my productivity post breaks down. You lose the parallelism advantage that makes AI-assisted development so powerful.

Existing tools only solve parts of this problem. Tmux and terminal multiplexers work great on a single machine, but they don't span devices. IDE-based solutions are tied to a specific editor. What I needed was a tool that could aggregate information from all my machines and present it in a single, real-time view.

As I discussed in The Future of Developer Tools, our tools need to adapt to AI-agent workflows. This dashboard is one example of what that adaptation looks like in practice.

The Real Challenge: Context Switching and Cognitive Load

One thing that doesn't get discussed enough is that the biggest bottleneck in AI-assisted parallel development isn't the AI itself. It's the human.

When you're orchestrating multiple agents, the cognitive load of context switching between sessions becomes the primary constraint. Which agent was working on what? Did that session finish or stall? Is the agent waiting for my input? Every time you have to answer these questions by opening terminals and inspecting state manually, you pay a context-switching tax that eats into the productivity gains you're trying to achieve.

This is the core challenge of the orchestrator era: managing the mental overhead of parallel work. Any tool that claims to support AI-assisted development needs to address this head-on.

The Dashboard: What It Does

The dashboard provides a real-time overview of all my active coding agent sessions across every device and project.

Sessions are organized by device, so I can immediately see what's running on my MacBook versus my workstation. Each session is represented by a card that displays key information at a glance:

• Project and git branch: Which repository and branch the agent is working on.
• Pull Request link: If the agent has created or is working on a PR, a direct link is shown.
• Model and context usage: Which LLM model the session is using and how much of the context window has been consumed.
• Status: Whether the agent is actively working, idle, or waiting for user permission.
• Task description: A summary of what the agent is currently doing.
• MCP servers: Which Model Context Protocol servers are connected to the session.

The dashboard updates in real time as agents report their state. It uses this stream of information to detect stale or crashed sessions automatically. If an agent stops reporting for too long, the session card reflects that something may have gone wrong.

By externalizing this state, the dashboard directly attacks the context-switching problem I described above. Instead of cycling through terminal windows to reconstruct what's happening, I can glance at the dashboard and know the state of every agent instantly.

Remote Terminal Attachment

The feature that changed everything for me is the ability to connect to any agent session directly from the browser.

I've seen developers set up elaborate solutions to achieve cross-device terminal access: Tailscale VPNs, SSH tunneling from their phones, complex tmux configurations with nested sessions, and custom scripts to keep everything in sync. These approaches work, but they add layers of friction and configuration that become their own maintenance burden.

The dashboard takes a different approach. When I click on a session, I get a live terminal embedded right in the browser, attached to that agent's session. I can read the output, provide input, approve permissions, or intervene if the agent goes off track. No SSH setup, no VPN, no terminal app on my phone. Just a browser and the same interface everywhere.

This works from any device: my laptop, my phone, a tablet, or any machine with a web browser. During lunch, I can check on a long-running session from my phone. On the couch in the evening, I can review what an agent produced during the day from a tablet. The UX is the same everywhere because the interface is always the same web application.

Security was a primary design concern from the start. This runs in my own environment with authenticated device registration and scoped access, so the goal is convenience without exposing raw terminal access publicly.

Spawning Sessions Remotely

If remote terminal attachment is the feature that keeps me connected, remote spawning is the one that keeps me productive from anywhere.

From the dashboard, I can start a new Claude Code session on any of my registered devices. I pick a device, select a project from its available repositories, and a fresh agent session spins up in a new tmux window on that machine. The dashboard picks it up immediately and starts tracking it.

This means I can kick off agent sessions while commuting, then sit down later to review the results. I can distribute work across machines based on what each one is best suited for, sending resource-intensive tasks to the workstation and lighter ones to the laptop.

The ability to start work from anywhere and review it from anywhere else has fundamentally changed when and where I can be productive.

How It Works: Architecture Overview

Rather than walking through every implementation detail, I want to highlight the high-level architecture and the design decisions that make this system flexible.

The system follows a heartbeat model. Each coding agent session reports its state to the dashboard backend at regular intervals. This report includes project information, git status, context usage, active MCP servers, and the agent's current task.

The heartbeat data is gathered through coding agent hooks. In the case of Claude Code, these are notification hooks that fire when the agent transitions between states (working, idle, awaiting permission). The hooks execute a lightweight script that posts the session state to the dashboard API.

For terminal attachment, the backend establishes a WebSocket relay between the browser and the remote machine's terminal session. Since the agent and the human connect to the same underlying session, they can interact with it simultaneously.

The design decision I'm happiest with is the enricher pattern. The raw data coming from agent hooks is passed through a chain of enrichers, each responsible for extracting or deriving specific information. For example, one enricher parses the agent's transcript to extract model name, token usage, and context percentage. Another enricher detects PR URLs from the git branch.

This pattern is what makes the system extensible and agent-agnostic in the core dashboard, with agent-specific hooks and enrichers handling the adaptation layer. The dashboard doesn't need to know the internals of any particular coding agent. It only needs a hook script that sends heartbeats and an enricher that knows how to interpret the raw data. Supporting a new CLI agent, whether Goose, Gemini CLI, or any future tool, is mostly a matter of writing a new hook and a new enricher. The rest of the system remains unchanged.

A quick note on scope: this is currently optimized for live orchestration and intervention, not long-term analytics. The focus is real-time visibility and control across devices. I can add historical views later, but the immediate win was reducing the cost of checking and steering active sessions.

What I've Learned Running This

After several weeks of daily use, a few insights stand out.

Visibility reduces cognitive load dramatically. The single biggest improvement isn't any specific feature. It's simply being able to see everything at once. Before the dashboard, I spent mental energy tracking session states in my head. Now that state is externalized, I can focus on higher-level decisions like what to assign next and which results to review first.

Context percentage is the most actionable metric. Of all the fields on the dashboard, context usage has been the best predictor of where I should look next. When an agent is running high on context, it usually means I need to review progress, reset with a fresh session, or prepare for handoff.

PR awareness shortens the review loop. Seeing which sessions have produced pull requests, with direct links, lets me move from orchestration to review immediately instead of hunting through GitHub notifications.

Remote access changes when and where you can be productive. This sounds obvious in retrospect, but actually experiencing it is different from theorizing about it. Being able to start a session from my phone during a coffee break and review the results from my workstation an hour later has added genuinely productive moments to parts of the day that were previously dead time.

What's Next

The dashboard is functional and I use it daily, but the roadmap is driven by a clear goal: reducing the need to leave the dashboard for anything.

In the short term, I'm focused on features that eliminate round-trips to other tools:

• Coding agent settings management: Configure agent behavior directly from the dashboard instead of editing configuration files on each machine.
• File attachment: Send files, context documents, or reference material to an agent session without switching to a terminal.
• Code diff viewer: Review the changes an agent has made without opening an IDE, closing a major gap in the orchestration workflow.

On the extensibility front, support for additional coding agents is a natural next step. The enricher pattern I described above was designed with this in mind. As more CLI-based coding agents emerge, the dashboard should be able to aggregate sessions from all of them into the same unified view, regardless of which agent is running underneath.

Most importantly, I'm seriously considering open-sourcing the dashboard, or at least the key components: the hook scripts, the heartbeat protocol, and the enricher framework. These pieces could be useful to anyone building similar orchestration workflows, and I'd love to see what others do with them.

If you're running parallel coding agents and have thoughts on what would make a tool like this more useful, I'd genuinely love to hear from you. Whether it's a feature idea, a different approach to the same problem, or just your experience managing multiple agents, reach out.

Conclusion

The shift from implementer to orchestrator that I described in my productivity post requires different tools. Standard terminals and IDEs were not built for one developer managing a fleet of AI agents across multiple machines.

This dashboard is my current answer to that gap. It gives me visibility, control, and a consistent way to monitor, intervene, and start work from anywhere.

Developers who learn to orchestrate AI agents effectively will have a real advantage in the next era of software engineering. And the tools we build today to support that orchestration, however rough around the edges, will shape what that era looks like.

I'm still iterating on this, and I'd welcome feedback, feature suggestions, and stories from anyone tackling similar challenges.

On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.19.0 has been released and is now available from Maven Central 🎉.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Improved Spring Boot health probes configuration
• ECR registry authentication with AWS SDK v2
• IngressClassName support for Ingress resources
• Updated base images from UBI 8 to UBI 9
• Reduced dependencies (Guava removal)
• 🐛 Many other bug-fixes and minor improvements

Improved Spring Boot health probes configuration

This release brings several improvements for the Spring Boot health probes configuration:

• JKube now uses the correct management.endpoint.health.probes.enabled property. The previous property (management.health.probes.enabled) was deprecated in Spring Boot 2.3.2.
• Added support for server.ssl.enabled and management.server.ssl.enabled properties to enable liveness/readiness probes for Spring Boot Actuator. This allows for easier environment-specific SSL configuration.

ECR registry authentication with AWS SDK v2

JKube now supports Amazon ECR registry authentication using AWS SDK Java v2. This update ensures compatibility with the latest AWS SDK and provides a more robust authentication mechanism when pushing images to Amazon Elastic Container Registry.

IngressClassName support for Ingress resources

The IngressClassName field is now supported in the NetworkingV1IngressGenerator. This is essential for Kubernetes environments with multiple ingress controllers, allowing you to specify which ingress controller should handle your Ingress resources.

Using this release

If your project is based on Maven, you just need to add the Kubernetes Maven plugin or the OpenShift Maven plugin to your plugin dependencies:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>kubernetes-maven-plugin</artifactId>
  <version>1.19.0</version>
</plugin>

If your project is based on Gradle, you just need to add the Kubernetes Gradle plugin or the OpenShift Gradle plugin to your plugin dependencies:

plugins {
  id 'org.eclipse.jkube.kubernetes' version '1.19.0'
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "first-timers-only" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source and the Eclipse organization.

If you are a more experienced developer or have already contributed to JKube, check the "help wanted" tag.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Feedback is the only way to improve.

Project Page | GitHub | Issues | Gitter | Mailing list | Stack Overflow

2025 was a turning point. It was the year artificial intelligence fundamentally transformed how I work, think, and build software.

This is my sixth Red Hat anniversary post, but I'm reframing the series. Rather than focusing solely on my work anniversary in late October, I want to reflect on the entire year and the profound changes it brought.

You can catch up on my previous years as a Red Hatter in these posts:

• My first year at Red Hat
• Two years of Open Source at Red Hat
• Reflecting on three years at Red Hat
• Four years of Free Software at Red Hat
• Five years at Red Hat

📷 Featured photo by Julia (El Arte de Julieta)

A pivotal year

If I had to choose one word to describe 2025, it would be pivotal.

On one hand, this was the year I fully embraced AI-assisted development. I restructured my workflows around AI agents, achieved significant productivity gains, and created tooling that bridges the gap between AI systems and cloud-native infrastructure.

On the other hand, it was also a year of uncertainty. In February 2025, Red Hat announced changes to its middleware strategy, transferring key teams to IBM. These were the teams that relied most heavily on Fabric8 Kubernetes Client and Eclipse JKube, the projects I've poured years of effort into.

Despite my respect for IBM, it weighed on me. Being a Red Hatter isn't just a job title for me; it's an identity I've cherished since my teenage years when I first discovered Red Hat Linux.

But here I am, still doing what I love: building free open source tools that help developers. And this year, that mission expanded in unexpected directions.

This year's highlights

Now let me share some of the highlights from 2025.

Projects

Kubernetes MCP Server

If there's one project that defined 2025 for me, it's the Kubernetes MCP Server.

It started as a proof of concept in late January 2025, originally built around the Fabric8 Kubernetes Client. When I first ran the MCP server, the results surprised me. It was the first time I truly realized the potential of AI. Until then, AI was cool but not that much of a game changer. Seeing an AI agent autonomously deploy and manage applications on Kubernetes was a revelation.

I sent a few demos to internal mailing lists at Red Hat, and they were a great success. Seeing the potential, I decided to port the project to Go. Most of the Kubernetes ecosystem is built in Go, and Kubernetes developers are far more familiar with it than Java. This turned out to be the right call. Adoption started to increase, and so did interest from across Red Hat. People from other business units reached out to learn more and explore how they could use it.

I put a lot of effort into promoting the project and making it stable enough to be embedded in real products. The Model Context Protocol (MCP) provided the perfect bridge between AI agents and Kubernetes clusters, allowing AI systems to deploy, manage, and troubleshoot applications autonomously.

The project's growth speaks for itself: over 1,050 stars and 232 forks on GitHub, reflecting both its adoption by the AI developer community and the growing number of contributors.

The peak came when the project joined the Containers organization on GitHub, alongside industry-standard tools like Podman and Buildah. This gave the project a neutral space for collaboration and validated its importance. At this point, teams from OpenShift are actively contributing features on top of it.

This is one of the biggest successes of my career at Red Hat. Taking a proof of concept from my laptop to an organization-level project with cross-team contributions in less than a year is something I'm incredibly proud of.

Along the way, I documented my learnings on this blog. From giving superpowers to small language models to connecting MCP servers with various AI frameworks, these posts capture the evolution of my thinking about the future of developer tools and how they need to evolve for AI-augmented development.

Fabric8 Kubernetes Client

The Fabric8 Kubernetes Client saw 7 releases this year, including the new 7.x line. We released versions 7.1.0 through 7.4.0, plus maintenance releases for the 6.x branch.

Community contributions remain strong, and the project continues to be a foundation for countless Kubernetes tools in the Java ecosystem. While my personal focus shifted toward MCP tooling, the project remains healthy and actively maintained.

I'm happy that Ashish Thakur joined the team this year to help with the maintenance of both Fabric8 and JKube. His involvement ensures these projects continue to thrive.

Eclipse JKube

Eclipse JKube had 3 releases this year (1.18.0, 1.18.1, 1.18.2). The project now has 846 stars and 551 forks.

With the middleware team changes, the immediate future of JKube felt uncertain at times. But with Ashish on board and continued community growth, the project remains valuable for Java developers deploying to Kubernetes.

The AI Transformation

Beyond building MCP servers, 2025 was the year I transformed my own development practices.

After my summer break, I went all-in on AI tooling. I wrote about this extensively in Boosting My Developer Productivity with AI in 2025, but the short version is: my productivity more than doubled.

The key insight isn't about any single tool, but about parallelism. Using CLI agents like Claude Code and GitHub's Copilot Coding Agent, I can orchestrate multiple AI systems working on different tasks simultaneously. My role has shifted from implementer to orchestrator. I've since taken this further by building a dashboard to monitor and orchestrate these agent sessions across all my devices in real-time.

This shift had uncomfortable implications too. The nature of the job is changing. Coding is no longer the job; orchestrating AI agents is. As someone who genuinely loves the craft of coding, this realization was bittersweet.

I'm confident that software engineers will still be needed, even if our roles evolve toward orchestration and architecture. This shift doesn't diminish the importance of engineering fundamentals; if anything, it amplifies them. What worries me is that decision-makers who don't understand the nuances might believe that engineering teams can be fully replaced by AI agents. That's a dangerous misconception, and one I hope the industry navigates carefully.

Public Speaking

This year I spoke at DevBcn 2025 in July, delivering a talk on "Model Context Protocol Servers 101: Unlocking the Power of AI". It was a comprehensive introduction to MCP and its implications for the future of developer tooling.

To my surprise, I received the "Most Original Speaker" award. Once again, I'm humbled by this recognition. There were many great talks at the conference, and in my opinion, several deserved the award more than I did. However, for an introvert like me, this is huge. It's a testament to the effort I put into each of my conference talks, and validation that stepping outside my comfort zone has been worth it.

Unfortunately, the talk wasn't officially recorded. I did record a version from home later that week, which you can watch below. It's not as engaging as the live presentation, but if you're curious about MCP, it covers the essentials:

Looking Forward

As I write this in early 2026, the trajectory is clear: AI will continue reshaping how we build software. The question isn't whether to embrace these changes, but how to do so thoughtfully.

I remain committed to building free open source tools that empower developers, whether those developers are humans, AI agents, or some combination of both. The Kubernetes MCP Server, Fabric8 Kubernetes Client, and Eclipse JKube will continue to evolve.

Despite the organizational uncertainties, I'm grateful to be doing what I love at Red Hat. I want to thank my managers, who have reassured me about my value during these times. Their support has meant a lot when things felt uncertain.

Six years in, and the mission remains the same: make developers' lives easier through free and open source software.

If you've followed my journey or used any of the tools I've worked on, I'd love to hear your thoughts.

At the end of the day, what drives me hasn't changed: the joy of building something useful, sharing it with the world, and seeing others build on top of it. That's the magic of open source, and it's why I'll keep doing this for as long as I can.

Introduction

The Synology DiskStation DS224+ is a compact 2-bay NAS designed for home users and small offices. It's powered by an Intel Celeron J4125 quad-core processor (2.0 GHz, burst up to 2.7 GHz), comes with 2GB of DDR4 RAM (expandable to 6GB), and consumes only around 15 watts under full operation. The DS224+ supports both Synology Hybrid RAID (SHR) and traditional RAID configurations (RAID 0/RAID 1), making it a versatile solution for centralized data storage and backup.

After some time using the NAS, I decided to upgrade the hard drives to increase the storage capacity. The great thing about RAID 1 (mirroring) is that you can replace the drives one at a time, allowing the array to rebuild between replacements, which means no data loss and no downtime during the upgrade process.

This post documents the step-by-step procedure I followed to upgrade from my original drives to 2x 16TB drives, effectively increasing my usable storage capacity.

Prerequisites

Before you begin, make sure you have:

• Backup your data: Even though RAID 1 provides redundancy, always have a backup before any hardware changes
• New drives: 2x Seagate IronWolf Pro 16TB (ST16000NT001) - 7200 RPM, CMR, 256MB cache
• Check drive compatibility: Verify your drives are on Synology's compatibility list
• Run data scrubbing: Perform a data scrubbing operation before starting (see below)
• Time: The rebuild process can take several hours per drive
• Access to DSM: Ensure you can access your NAS web interface

One of the prerequisites above deserves special attention: data scrubbing. If you're not familiar with this operation, here's what you need to know.

What is data scrubbing?

Data scrubbing is a maintenance operation that scans your storage pool to detect and repair data inconsistencies before they become a problem. It's essentially a health check for your drives and file system.

There are two types of scrubbing:

• RAID scrubbing: Verifies that all parity data is consistent across the array. This is only available for SHR (with 3+ drives), RAID 5, RAID 6, or RAID F1. For a 2-drive RAID 1 setup, this type of scrubbing is not available.
• File system scrubbing: Available for Btrfs volumes, this uses checksums to verify data integrity and can repair corrupted data using redundant copies.

Running data scrubbing before a drive upgrade ensures that your existing data is in a healthy state before you start replacing drives. If there are any issues, it's better to discover and fix them while you still have both original drives in place.

To run data scrubbing:

1. Open Storage Manager in DSM
2. Go to Storage Pool
3. Select your pool to expand its details
4. Under the Data Scrubbing section, click Run Now

Current setup

Before starting the upgrade, here's my current configuration:

• NAS Model: Synology DS224+
• Current drives: 2x Synology HAT3300-6T (6TB, 5400 RPM, SATA III)
• Storage pool type: SHR (Synology Hybrid RAID) / RAID 1
• File system: Btrfs
• Total raw capacity: 12TB (2x 6TB)
• Usable capacity: 5.4TB (mirrored)

The Synology HAT3300 Plus series drives are specifically designed for NAS use, featuring a 1 million hour MTTF and a workload rating of 180TB/year. They've been reliable drives, but it's time for more storage space.

Upgrade procedure

The upgrade process involves replacing one drive at a time. For each drive, you'll deactivate it, physically swap it, then repair and expand the storage pool. The DS224+ supports hot swapping, so you don't need to power off the NAS, though you can do so if you prefer.

Step 1: Identify the drive to replace

First, identify which drive you want to replace:

1. Open Storage Manager in DSM
2. Select Storage from the left menu
3. Under Drive Info, note which drive number corresponds to each drive

In my case, I'll start by replacing Drive 1 as shown in the screenshot below.

With the drive identified, the next step is to locate its physical position in the NAS.

Step 2: Locate the physical drive

Before removing anything, confirm which physical bay contains the drive:

1. Go to Storage Manager > HDD/SSD
2. Select the drive you want to replace (e.g., Drive 1)
3. Click Locate Drive

The drive bay LED will change from green to amber for about a minute, as shown below. This prevents accidentally removing the wrong drive.

Once you've confirmed which bay contains the drive, you can proceed to deactivate it.

Step 3: Deactivate the drive

Deactivating the drive before removal is the safest approach:

1. With the drive still selected in HDD/SSD
2. Click the Action menu
3. Select Deactivate Drive
4. Confirm when prompted

After confirmation, the storage pool will enter a degraded state and the NAS will start beeping. Don't worry - this is expected behavior and we'll address it in the next step.

Step 4: Mute the beep alert

To stop the beeping:

1. Open Control Panel
2. Go to Hardware & Power
3. Click the Mute button

The NAS is designed to alert you when the storage pool is degraded - this is expected behavior during the upgrade.

Step 5: Replace the physical drive

Now swap the drive:

1. The DS224+ supports hot swapping, so you can replace the drive without powering off
   • If you prefer, you can power off the NAS first via Control Panel > Hardware & Power > Shutdown
2. Remove the deactivated drive from its bay
3. Insert the new 16TB drive into the same bay
4. If you powered off, turn the NAS back on

Step 6: Repair the storage pool

Once the new drive is detected, you need to initiate the repair process to rebuild the RAID array:

1. Open Storage Manager > Storage
2. Click the three-dot menu (⋯) next to your storage pool
3. Select Repair
4. In the repair window, select the new drive you just installed
5. Click Next, confirm the settings, and click Apply

The screenshot below shows the repair dialog where you select the newly installed drive.

Once the repair starts, the system health will change from "Critical" to "Warning".

Step 7: Wait for the first repair to complete

The repair process will take several hours:

• Status: The storage pool will show as repairing
• Duration: In my case, about 10.5 hours for ~5.4TB of data
• Monitor progress in Storage Manager

Step 8: Replace the second drive

Once the first repair is complete and the storage pool shows Healthy, it's time to replace the second drive:

1. Repeat Steps 1-6 for the second drive (locate, deactivate, swap, repair)
2. During the repair process, you should now see the option to expand the capacity
3. Check the box to expand, as both drives will now be 16TB

As shown in the screenshot below, this time the repair dialog includes an option to expand the storage pool capacity. This is because both drives will now be 16TB, allowing the RAID to use the full capacity.

Step 9: Wait for the second repair and expansion

Wait for the second repair and expansion to complete:

• Repair duration: About 6-7 hours for the RAID rebuild
• Expansion duration: About 14-15 hours for the storage pool expansion
• Total duration: 21.5 hours
• Once complete, the storage pool will show Healthy with the new 14.5TB capacity

Interestingly, the repair phase was faster than the first drive (6-7 hours vs 10.5 hours), but the expansion phase added significant time to the process.

Verification

After completing the upgrade, verify that everything is working correctly:

• ✅ Storage pool shows Healthy
• ✅ Total capacity reflects the new drive sizes
• ✅ All shared folders are accessible
• ✅ Data integrity check (spot-check some files)

The screenshot below shows the final storage pool configuration with both 16TB drives healthy and the full capacity available.

Final configuration:

• New drives: 2x Seagate IronWolf Pro 16TB (ST16000NT001)
• Total raw capacity: 32TB (2x 16TB)
• Usable capacity with RAID 1: 14.5TB

Timeline summary

Conclusion

Upgrading the hard drives in my Synology DS224+ was a straightforward process that required minimal hands-on effort. Despite the total process taking about 41 hours, the actual work on my part was just a few minor operations: deactivate, swap, repair, and repeat. The NAS handled everything else autonomously, allowing me to focus on other tasks while it rebuilt and expanded the storage pool.

This experience reinforced why I chose a Synology NAS in the first place. The premium cost is justified by the polished software, reliable hardware, and well-documented procedures that save time and reduce the risk of errors. As a busy person, I value solutions that work reliably without requiring constant attention or troubleshooting.

Key takeaways:

• Minimal effort: Just a few clicks and physical drive swaps - the NAS handles the rest
• No data loss: RAID 1 allows replacing drives one at a time while maintaining redundancy
• Patience required: Plan for ~41 hours total (data scrubbing + two repair cycles + expansion)
• Nearly 3x capacity: Upgraded from 5.4TB to 14.5TB usable storage

The extra storage headroom should serve me well for the foreseeable future, and when it's time to upgrade again, I know the process will be just as painless.

References

• Synology DS224+ Specifications
• Synology HDD Compatibility List
• Replace a Drive - Synology Knowledge Center

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.5.2 has been released and is now available from Maven Central 🎉.

This marks the fifth minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Kubernetes 1.34 support with updated OpenShift 4.20 model
• Streaming list support via new Watchable.streamingList method
• CRD generator enhancements with SchemaCustomizer annotation
• Leader election and WebSocket stability fixes
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Kubernetes 1.34 support with updated OpenShift 4.20 model

This release adds support for Kubernetes v1.34 (Of Wind & Will) and updates the Fabric8 OpenShift Model as per OpenShift 4.20. The Gateway API has also been updated from 1.2.1 to 1.4.0, and Istio from 1.27 to 1.28, ensuring you have access to the latest CRDs and resources.

Note that ValidatingAdmissionPolicy and related classes have been removed from admissionregistration.v1beta1 as they graduated to GA. The openshift-model-installer module is now deprecated and will be removed in a future release.

Streaming list support via new Watchable.streamingList method

A highly requested feature has been added: streaming lists via the new Watchable.streamingList() method. This allows you to process large lists of resources incrementally without loading the entire list into memory, which is particularly useful when dealing with namespaces containing thousands of resources.

CRD generator enhancements with SchemaCustomizer annotation

The CRD generator continues to evolve with the addition of the @SchemaCustomizer annotation for advanced schema modification. This new annotation supports @Repeatable, allowing you to apply multiple customizations, and provides better exception messages when things go wrong.

Leader election and WebSocket stability fixes

Several important stability fixes have been implemented:

• Leader election callbacks are now called only once instead of twice, fixing duplicate execution issues
• The duration from the current leader record is now used instead of the config duration, ensuring proper leader election behavior
• Vert.x WebSockets now properly handle multiple frames
• Request configuration is preserved when adapting to OpenShiftClient

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.5.2</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.5.2"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

Introduction

I don't usually share my GitHub contributions graph. If anything, it's evidence of an unhealthy obsession with software development rather than something to brag about. This time I'm making an exception because it tells a short, useful story.

Look at the last three months. After my summer break I restructured my developer workflows and went all-in on AI tooling. The results speak for themselves, I went from 10-15 contributions per day to over 25 contributions per day on average.

I've used AI-assisted development ever since GitHub Copilot arrived. For my personal projects, at least, I've had the luxury of exploring these tools without restrictions.

But this year, I pushed harder. I integrated AI into every possible workflow and measured the outcomes. The productivity gains have been remarkable.

Throughout this post, I'll be using examples from my personal projects like ElectronIM, YAKD, and helm-java to illustrate these concepts. These projects aren't bound by corporate policies, allowing me to experiment freely with tools like GitHub Copilot and others. That said, the practices I describe here apply wherever your organization's policies permit.

How I measured impact

Before anything else: I tried to be concrete about "productivity". My measurements are approximate and meant to show direction rather than provide definitive benchmarks.

• Commit and Pull Request (PR) velocity (commits/day, PRs opened and merged).
• Time-to-merge for small, routine changes.
• Number of automated refactors completed without manual edits.
• Qualitative: how often I could review and merge from my phone or while away from the keyboard (AFK).

Thinking of trying this yourself? Run a small experiment: measure your current output for a month, then adopt AI tooling and quantify your gains.

These numbers reflect my experience as a senior maintainer working on mature projects with strong test coverage. I wouldn't expect the same gains in early-stage or poorly structured codebases, and that distinction matters.

The AI Tooling Landscape

Not all AI developer tools are created equal. After months of experimentation, I've found it useful to categorize them by how they fit into the development workflow:

Autocomplete: The Old Familiar

This is where most developers started their AI journey. Tools like GitHub Copilot's inline suggestions, IntelliJ's AI assistant, or Cursor's tab completion provide real-time code completion as you type.

I've been using autocomplete features for a couple of years now. It's convenient, saves keystrokes, and occasionally suggests something clever. Most importantly, it rarely changes the structure of your work. But here's the uncomfortable truth: on its own, it doesn't improve productivity by much.

Autocomplete is still synchronous work. You're still the one driving, line by line, waiting for suggestions. The cognitive load remains squarely on your shoulders, for bigger tasks, gains are modest.

AI-Enhanced IDEs

Tools like Cursor take things a step further by integrating AI more deeply into the IDE experience. Instead of just completing lines, they can refactor code, answer questions about your codebase, and generate entire functions.

This is a step up from autocomplete, but it still suffers from a fundamental limitation: it remains synchronous. You ask, you wait, you review. No matter how good the model is, the bottleneck is still you.

Chat-Based Interfaces

Chat UIs like ChatGPT, Claude, or Gemini excel at brainstorming, exploring approaches, and researching solutions. They are excellent for getting unstuck or exploring solutions before committing to code.

Their drawback is integration friction. Without tight project context, copy/paste and re-contextualization slow things down.

Command Line Interface (CLI) Agents

This is where things get interesting. CLI-first agents such as Claude Code, Gemini CLI, or Goose change the game by operating within your project context and invoking multi-step tasks from the terminal, often leveraging Model Context Protocol (MCP) for tool integration.

CLI agents can:

• Read and reason about the codebase.
• Make changes across multiple files.
• Run tests and iterate on failures.
• Commit changes with meaningful messages.

The key difference is that CLI agents can work semi-autonomously. You give them a task, they execute, you review. This opens the door to parallelism.

GitHub Issues and Pull Requests

This is probably the most underrated category. AI-powered issue-to-PR workflows, like those enabled by GitHub Copilot Coding Agent or similar tools, let you describe work in prose and receive a ready-to-review pull request.

This workflow resonates deeply with me as a professional open source maintainer. It mirrors the asynchronous collaboration model I've used for years: someone opens an issue, proposes changes in a PR, we iterate through comments, and eventually merge.

The critical difference? It's completely asynchronous. You don't need to be at your computer. I've literally reviewed and approved AI-generated PRs from my phone.

That said, this workflow has rough edges. When the model misses the point, iterations become frustrating. You end up writing correction after correction, wishing you could just edit that one line yourself, but you're locked into the async loop. I see this as the future of async development, but current implementations need refinement.

When it does work, though, it's remarkable. For example, I described a Task Manager feature for ElectronIM with clear acceptance criteria and a UI reference, assigned it to Copilot, and reviewed the resulting work during spare moments. A complete feature, including tests, and everything else was implemented without me writing a single line of code. All it took was a well-written issue and a well-architected project with good test coverage for the AI agent to work effectively. Which brings me to the next point, the project factor.

The Project Factor

Here's something I've observed that doesn't get discussed enough: the state of your project is the single biggest factor in how effective AI tooling will be.

A well-structured project with:

• Comprehensive test coverage.
• Clear, consistent coding patterns.
• Black-box tests that verify behavior through public interfaces, not implementation, so AI can safely refactor internals without breaking the contract.
• Good documentation and clear architecture.

...will yield far better results from AI tools than a messy codebase with no tests and inconsistent patterns.

This makes sense when you think about it. AI tools learn from context. If your context is chaos, expect chaotic results. If your context demonstrates clear patterns, the AI will follow them.

This has been one of my most important realizations. Investing in code quality and solid tests isn't just about maintainability anymore. It's about making your project AI-ready.

The Productivity Multiplier: Asynchronous and Parallel Development

Here's the real secret to the productivity gains I've experienced. It's not about any single tool. It's about parallelism.

In traditional development, you work on tasks sequentially. One after another. Even with autocomplete helping you type faster, you're still limited by your own processing capacity.

With async AI agents, the model flips. I can have multiple Claude Code instances running on different git worktrees, each tackling a separate task. Or better yet, using GitHub's web-based workflows, I can have multiple PRs being worked on simultaneously.

My role shifts from implementer to orchestrator: I provide direction, review output, and course-correct when needed.

And here's the thing: as a developer, I'm not coding all day. Meetings, code reviews, emails, one-on-ones; they all interrupt flow. With async agents, those interruptions become productive gaps. The agents work while I'm on a call.

The Uncomfortable Truths

It's not all sunshine and rainbows. Here are some sobering observations:

Burnout Risk

Being able to be productive everywhere and anytime creates the temptation to never disconnect. The cognitive load shifts from implementation to review and orchestration, but it doesn't disappear. Orchestrating many parallel tasks and constantly switching context is mentally draining.

If you're not careful, this newfound productivity can accelerate burnout rather than prevent it. Set boundaries. The work will still be there tomorrow.

The Junior Developer Problem

This is uncomfortable to admit, but AI tooling is effectively replacing junior developers in my workflow. I now have a swarm of AI agents that I can orchestrate like a team of eager interns. They follow instructions, produce code, and iterate based on feedback, without the learning and growth that human juniors need.

The only limitation is my availability to give instructions and review work.

What does this mean for the next generation of developers? How do you become a senior developer if you never get to be a junior first?

Organizations need deliberate apprenticeship and mentoring models so people can progress.

Coding Is No Longer the Job

I love coding. I genuinely enjoy the craft of writing elegant solutions.

But increasingly, that's not what I do. My job has become more managerial: defining tasks, reviewing output, providing feedback, and deciding what to build next.

This meme captures it perfectly. The irony isn't lost on me.

Key Takeaways

After months of intensive AI-assisted development, here's what I've learned:

Async Beats Sync

The biggest productivity gains don't come from faster typing or better autocomplete. They come from parallelism. Web-based, async workflows let you orchestrate multiple AI coding agents simultaneously. You don't even need a computer; I've done meaningful work from my phone.

More Hours in the Day

This might sound hyperbolic, but async workflows have figuratively added more hours to my day.

The period I analyzed (September to December 2025) was unusually demanding. During work hours, I was juggling three major open source projects: Kubernetes MCP Server, Fabric8 Kubernetes Client, and Eclipse JKube, plus various AI experiments.

Yet despite this workload, I managed to bring several neglected side projects back to life during my free time. Projects that had been gathering dust for months suddenly became maintainable again.

The reason? Async workflows let me queue up tasks and review results in spare moments. A few minutes here and there, previously too short for meaningful coding, now add up to real progress. Time that was once lost to waiting or context-switching has become productive.

AI Excels at Grunt Work

Repetitive, tedious tasks that would take weeks of focused effort can be completed in days. I refactored this entire blog asynchronously in a couple of days. By my estimates, that would have taken two months of focused work before. Technical debt removal has never been easier.

For example, I migrated YAKD's frontend build from the deprecated create-react-app to Vite. This involved 193 files, renaming .js to .jsx, migrating Jest to Vitest, and updating ESLint configuration. What would have taken days of tedious, error-prone work was completed in minutes.

I also tackled ElectronIM's SonarCloud issues using the GitHub Copilot Coding Agent. The project had been clean for years, but as Sonar rules evolved, new issues appeared that weren't flagged before. This is exactly the kind of low-priority work that would otherwise remain undone forever. AI made it possible to tackle.

Patterns Are Everything

AI follows patterns. If you show it a coding style, an architecture pattern, or an implementation approach, it will replicate it. This makes AI incredibly effective for:

• Extending existing functionality following established patterns.
• Applying consistent changes across a codebase.
• Implementing features similar to existing ones.

Project Quality Matters More Than Ever

Well-tested, well-structured projects get better results from AI. Investing in code quality is no longer just about maintainability. It's about AI-readiness.

Conclusion

2025 has been a year of transformation in how I approach software development. The tools have matured, and the workflows have evolved from "AI as autocomplete" to "AI as parallel workforce."

The productivity gains are real, but they come with trade-offs. The nature of the job is changing. The risks of burnout and the implications for junior developers are concerns we need to address as an industry.

But for now, I'm excited about what's possible. The GitHub contributions graph doesn't lie. Something has fundamentally shifted, and I don't think we're going back.

Introduction

Software testing encompasses various methodologies designed to ensure application quality and reliability. Two fundamental approaches are blackbox and whitebox testing, strategies that examine software from different perspectives. Blackbox testing evaluates functionality without knowledge of internal code structure, while whitebox testing leverages detailed understanding of the application's implementation to verify logic and code paths.

While both methodologies have their place in software development, blackbox testing offers compelling advantages that make it the preferred approach for most scenarios. Understanding these differences is essential for building robust, maintainable test suites that provide genuine regression protection.

In this article, I'll explain the core concepts of blackbox and whitebox testing, their key differences, and why blackbox testing should be the default choice for most development scenarios.

Understanding Blackbox Testing

Blackbox testing is a methodology that examines an application's functionality without considering its internal code structure, design, or implementation details. Testers interact with the software through its public interfaces, focusing exclusively on inputs provided to the system and the outputs it produces.

This approach treats the software as an opaque "black box" where internal workings remain hidden. Tests validate whether the application behaves according to requirements without needing knowledge of how it is implemented.

Key Characteristics

Blackbox testing focuses on the behavior and contract of the software rather than how that behavior is achieved internally. Tests interact only with public APIs, interfaces, and observable outputs.

This methodology decouples tests from implementation details, meaning the internal code can be refactored, optimized, or completely rewritten without breaking tests as long as the external behavior remains consistent. Tests remain valid across implementation changes, providing genuine regression protection.

Benefits for Development

Blackbox tests serve as living documentation of what the software should do from a user's perspective. They validate that the software meets its specifications and requirements without being tied to specific implementation choices.

This approach enables confident refactoring since tests verify the contract rather than the implementation details. Developers can improve performance, restructure code, or adopt better algorithms without modifying tests.

Blackbox tests are also easier for team members to understand because they focus on requirements and behavior rather than implementation specifics, making test suites more accessible across the team.

Understanding Whitebox Testing

Whitebox testing examines the internal structure, design, and code implementation of the software under test. This approach requires knowledge of the programming languages, frameworks, and implementation details used to develop the application.

The method derives its name from the transparency it provides into the application's internal workings. Testers analyze code paths, conditions, loops, and logic flows to design test cases.

Key Characteristics and Limitations

Whitebox testing often relies on mocking frameworks to isolate units of code and verify interactions between components. Tests must know how methods are implemented internally to set up appropriate mocks and expectations.

This creates tight coupling between tests and implementation details. When the implementation changes, even if external behavior remains identical, whitebox tests often fail and require updates.

The Mocking Challenge

Whitebox testing frequently depends on mocks and test doubles to replace dependencies and verify internal interactions. While mocking has legitimate uses—such as testing error handling when dependencies fail or avoiding actual network calls to external systems—over-reliance on mocks to verify internal implementation details creates significant problems.

Tests using mocks verify that code calls specific methods with specific arguments rather than verifying actual behavior. This means tests can pass even when the software doesn't work correctly. Conversely, tests can fail even when the software works perfectly because implementation details changed.

Mocks couple tests directly to implementation choices, making refactoring risky and expensive. Every internal restructuring requires updating numerous mock expectations across the test suite.

Why Blackbox Testing Should Be Preferred

Despite the widespread use of whitebox testing, blackbox testing offers clear advantages that make it the better default in most scenarios.

Better Alignment with TDD

Test-Driven Development (TDD) emphasizes writing tests before implementation to drive design decisions. Blackbox testing naturally supports this workflow because tests specify what the code should do without requiring knowledge of how it will be implemented.

When writing blackbox tests first, developers focus on the specification and requirements rather than implementation details. This leads to better API design and clearer contracts between components.

Whitebox testing can make TDD harder to practice effectively because it requires knowing implementation details before tests can be written.

Implementation Independence

The most significant advantage of blackbox testing is independence from implementation details. Tests verify behavior and contracts, not specific code paths or internal interactions.

This independence enables fearless refactoring where developers can improve code structure, performance, or clarity without modifying tests. Tests continue validating correctness as long as external behavior remains consistent.

By contrast, whitebox tests break whenever implementation changes, even when functionality is preserved. This creates significant maintenance overhead and discourages beneficial refactoring.

Reduced Test Maintenance

Blackbox tests remain stable across refactoring and optimization efforts, reducing maintenance costs. Tests written against public interfaces rarely need updates unless requirements change.

Whitebox tests require frequent updates as internal implementations evolve. Every refactoring triggers cascading test failures that must be addressed before proceeding.

Focus on Specifications

Developers should write tests that verify specifications rather than implementation details. Blackbox tests align with this goal by focusing on requirements and observable behavior.

Unit tests don't need mocks or internal knowledge to be effective. They should test the contract a unit provides through its public interface. Following best practices for test design ensures maintainable and valuable test suites.

These advantages become even more critical in modern development contexts where rapid iteration and continuous refactoring are essential practices.

Blackbox Testing in the AI-Assisted Development Era

The rise of AI-assisted development tools introduces new considerations for testing strategies. AI assistants can modify implementations extensively while attempting to maintain functional behavior. When paired with blackbox tests, these AI-generated changes face immediate validation against specifications without requiring test modifications.

Blackbox tests act as a safety net, verifying that AI-generated code meets requirements while remaining stable through implementation changes. The AI can refactor, optimize, or rewrite logic while tests confirm that external behavior remains correct. This separation between specification and implementation becomes critical when AI assistants frequently suggest optimizations and refactorings.

Whitebox tests become liabilities in AI-assisted development because they break with every implementation change the AI makes. Developers end up spending excessive time reviewing both code and test changes to ensure everything still works correctly. As AI development tools become more sophisticated and autonomous, blackbox tests provide the resilience needed to support rapid iteration while maintaining quality standards.

For real-world examples of AI-assisted development with blackbox testing, see how AI agents boosted developer productivity in 2025.

When to Consider Whitebox Testing

While blackbox testing should be your default approach, whitebox testing remains valuable and necessary in specific scenarios where examining internal implementation reveals issues that external behavior cannot expose.

The Limitations of Pure Blackbox Testing

Completely ignoring source code and assuming optimal implementation is not a reliable strategy for building robust software. Testing every possible input combination to verify outputs is often impractical or impossible, especially with unbounded inputs.

Consider this function:

package main

func product(a, b int) int {
    if a == 42 {
        return 0  // Bug: violates specification
    }
    return a * b
}

A blackbox test that validates typical multiplication cases (product(2, 3) == 6, product(-1, 5) == -5) would pass, yet the implementation violates the specification by returning incorrect results for one input value. Without examining the source code, discovering that 42 produces incorrect results requires either exhaustive testing of all possible inputs (impossible with unbounded integers) or extraordinarily lucky test case selection.

Appropriate Use Cases for Whitebox Testing

Whitebox testing is particularly valuable in scenarios such as:

• Complex algorithms with hidden branches: Internal conditions may only surface through code inspection (e.g., the special case handling in the multiplication example).
• Performance-critical code: Verifying that optimizations are implemented correctly may require checking internal code paths.
• Security-sensitive logic: Authentication flows, encryption, and access control often depend on implementation details that should be verified directly.
• Code coverage goals: Designing tests to exercise all branches and conditions requires knowledge of internal structure.

Balancing Both Approaches

The most effective strategy combines both methodologies:

1. Start with blackbox tests that verify specifications and requirements through public interfaces.
2. Use code coverage tools to identify untested paths and conditions. Then, add targeted test cases to address the gaps.
3. Supplement with targeted whitebox tests for concerns that cannot be validated externally.

Even when whitebox analysis identifies test cases, consider implementing them through public interfaces when possible.

This approach combines the stability of blackbox tests with the completeness of targeted whitebox coverage.

Conclusion

While blackbox and whitebox testing complement each other, the advantages of blackbox testing make it the superior default for modern software development. Blackbox testing focuses on specifications rather than implementation details, enabling confident refactoring and reducing maintenance overhead.

The coupling that whitebox testing introduces through mocks and internal knowledge creates brittle test suites that break with every refactoring. In the era of AI-assisted development, blackbox tests provide an essential protection layer that validates AI-generated changes without requiring constant modifications.

Developers should write unit tests that verify specifications through public interfaces. This produces maintainable, resilient test suites that provide genuine regression protection while supporting rapid iteration and continuous improvement.

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 7.4.0 has been released and is now available from Maven Central 🎉.

This marks the fourth minor release of the Fabric8 Kubernetes Client 7, bringing new features, bug fixes, and improvements while keeping the breaking changes minimal.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Enhanced testing framework with mock client improvements
• Improved informer and watch operation stability
• CRD generation enhancements with annotation support
• Better WebSocket and connection handling
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Enhanced testing framework with mock client improvements

The testing experience has been significantly enhanced in this release. The @EnableKubernetesMockClient annotation now works properly with nested tests, resolving JUnit integration issues that were affecting test organization and execution.

Additionally, the KubeApiTest inheritance from base test classes has been fixed, providing better test framework compatibility and making it easier to structure your test suites.

Improved informer and watch operation stability

This release brings improvements to the Informer API. You can now use Informer.isWatching() to see the underlying Watch state, providing better visibility into watch operations and helping with debugging and monitoring of long-running watch connections.

CRD generation enhancements with annotation support

The CRD generator has been extended with support for @Annotations and @Labels in CRD generation. The CRD generator now includes metadata from these annotations, making it easier to generate comprehensive Custom Resource Definitions with proper annotations and labels.

The java-generator has also been enhanced to support the use of existing enumerations through extended existingJavaTypes configuration.

Better WebSocket and connection handling

Several critical fixes have been implemented to improve connection stability:

• Fixed potential NPE in OkHttp WebSocket handling
• Ensured that streams are properly notified of errors
• Changed rolling update handling to use JSON merge patch to avoid 422 errors during deployment updates

These improvements make the client more reliable when dealing with long-running connections and deployment operations.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.4.0</version>
</dependency>

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

dependencies {
  api "io.fabric8:kubernetes-client:7.4.0"
}

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow

I'm thrilled to announce that the Kubernetes MCP Server has officially migrated to the github.com/containers GitHub organization!

New Repository Location:

👉 github.com/containers/kubernetes-mcp-server

Why the Move?

The Kubernetes MCP Server has grown far beyond its origins as a personal project. It is now a powerful, flexible, and feature-complete Model Context Protocol (MCP) server, enabling seamless interaction with Kubernetes and OpenShift clusters. With over 10 contributors, 400 stars, 60 forks, 46 releases, and thousands of weekly downloads, it has become a key component in the MCP ecosystem.

Our main goal for this migration is to foster a more neutral, community-driven, and inclusive collaboration environment. By joining the well-established Containers organization, we're better positioned to:

• Welcome new contributors and maintainers from diverse backgrounds and organizations.
• Signal that the project is open for community governance and input.
• Ensure the project's long-term sustainability and growth.
• Accelerate the adoption of MCP as a Kubernetes and OpenShift interface.

What’s Next?

Moving to the Containers organization is just the start. With a strong foundation in place and your support, we'll be shipping new features, improving the user experience, and building tools that matter for the Kubernetes, OpenShift, and AI communities.

If you’re building tools for AI agents that need to interact with Kubernetes, or if you're just curious about Model Context Protocol, this is the time to get involved.

Get Involved!

No matter your background, your involvement is welcome and valued! Here’s how you can participate:

• ⭐ Star the repo: github.com/containers/kubernetes-mcp-server
• 🧑‍💻 Contribute: Submit features, bugfixes, issues, documentation, or integrations.
• 📣 Spread the word: Share this announcement, the repository, and your experiences with the Kubernetes MCP Server.

You Might Also Like

• Introduction to the Model Context Protocol (MCP): The Future of AI Integration
• Giving Superpowers to Small Language Models with Model Context Protocol (MCP)
• Introducing Goose, the on-machine AI agent