Streamlining Kratix: Bundling Controller & Adapter Images

Hey guys! Today, we're diving into an exciting feature update that's all about streamlining Kratix. We're talking about bundling the controller manager and adapter images into a single, unified image. This is going to make things so much easier to manage and distribute, which means less hassle for everyone. Let's get into the details!

Context: Why Bundle Images?

Simplifying Kratix Distribution and Management is our main goal here. Think about it: maintaining fewer images is always a win, right? It reduces complexity and makes the whole process smoother. Plus, the pipeline adapter image and the Kratix controller image are typically released together. It just makes sense to bundle them up! This not only simplifies the release process but also reduces the chances of version mismatches, leading to a more stable and predictable system.

Bundling these images helps in several key ways:

• Reduced Maintenance Overhead: Fewer images mean less to track, update, and secure. This saves time and resources.
• Simplified Deployment: Deploying a single image is always easier than deploying multiple images. This reduces the potential for errors and speeds up the deployment process.
• Improved Consistency: Bundling ensures that the adapter and controller are always in sync, reducing the risk of compatibility issues.
• Streamlined Release Process: Releasing one image instead of two simplifies the release pipeline, making it faster and more efficient.

The Advantages of Bundling Images

When we bundle these images, we're essentially creating a more cohesive and manageable unit. This approach has several benefits, both in terms of development and operations. For developers, it means a simpler build and release process. For operators, it translates to easier deployments and reduced operational overhead. It’s a win-win!

Moreover, this change aligns with the best practices in containerization, where smaller, self-contained units are favored for their portability and scalability. By reducing the number of images, we're also reducing the attack surface, enhancing the overall security posture of Kratix.

The unified image also makes it easier to reason about the system as a whole. Instead of thinking about two separate components that need to be deployed and managed independently, we can now treat them as a single unit. This simplifies troubleshooting, monitoring, and overall system management. It's about making life easier for everyone involved in the Kratix ecosystem.

Engineering Notes: What's Changing?

From an engineering perspective, Kratix core won't change much. It will still load the image name from the config map. The cool part is that the image itself will be the same as the Kratix image. This means less code churn and a smoother transition. We’re keeping the core stable while making improvements under the hood. Think of it as a well-coordinated pit stop during a race – quick, efficient, and with minimal disruption.

Key points to keep in mind:

• The image name changes will be reflected in the Kratix helm chart. This is crucial for deployment and updates.
• We might rename work-creator to pipeline-adapter to keep things consistent and clear. It's a good opportunity to clean up naming conventions and make the codebase more understandable.
• We'll be updating the generated config map to have the new value, ensuring everything points to the right image.

Diving Deeper into the Technical Adjustments

The helm chart update is a critical part of this change. We need to ensure that the chart accurately reflects the new image structure and that deployments are seamless. This involves modifying the chart templates to reference the unified image and updating any related configurations. It's like updating the blueprint of a house to match the new layout – accuracy is key.

The potential renaming of work-creator to pipeline-adapter is more than just a cosmetic change. It's about aligning the codebase with the intended functionality. A clear and consistent naming convention makes the code easier to understand and maintain, reducing the likelihood of confusion and errors. It’s like giving everything in your toolbox a label so you know exactly what you're grabbing.

Updating the config map is the final piece of the puzzle. This ensures that Kratix knows where to find the new image. It's a simple change, but it's essential for the system to function correctly. Think of it as updating the address in your GPS so you don't get lost.

Acceptance: How Do We Know It Works?

We're using Gherkin to define our acceptance criteria. This helps us ensure that the new setup works as expected. Here’s the scenario:

Given I have a running deployment of Kratix
When I run workflows
Then the pipeline adapter comes from the same image

This means we need to verify that when Kratix is running and workflows are executed, the pipeline adapter is indeed using the bundled image. It’s like making sure the cake tastes as good as it looks!

Ensuring Seamless Integration

The acceptance test is designed to validate the core functionality of the bundled image. It checks that the pipeline adapter, which is a critical component of Kratix, is correctly integrated with the new image. This test provides confidence that the changes we've made haven't introduced any regressions and that the system is working as expected.

This test is just one part of a broader testing strategy. We'll also be conducting unit tests, integration tests, and end-to-end tests to ensure that the system is robust and reliable. Testing is a continuous process, and we're committed to delivering high-quality software.

The Gherkin scenario is written in a human-readable format, making it easy for everyone to understand the acceptance criteria. This promotes collaboration between developers, testers, and stakeholders, ensuring that everyone is on the same page. It's like having a shared understanding of the recipe before you start cooking.

Tasks: The To-Do List

To get this done, we have a few key tasks:

• [ ] Update Kratix Helm Chart: Make sure the chart reflects the new image setup.
• [ ] Update any documentation referencing the pipeline adapter image: Keep our docs up-to-date.
• [ ] Update the generated config map to have the new value: Point Kratix to the right image.
• [ ] Remove redundant make targets (or deprecate it as a noop as to not cause unexpected failures): Clean up our build process.
• [ ] Update home scripts, quick-starts, syntasso/ci etc to remove the adapter building step: Streamline our automation and tooling.

Breaking Down the Tasks

Let's break down these tasks a bit more. Updating the Helm chart is crucial for ensuring that deployments are seamless. This involves modifying the chart templates to reference the unified image and updating any related configurations. It's like updating the blueprint of a house to match the new layout – accuracy is key.

Updating the documentation is equally important. We want to make sure that our users have the latest information about how to use Kratix. This includes updating any references to the pipeline adapter image and providing clear instructions on how to deploy and manage the new bundled image. It's like providing a detailed user manual for a new product.

Updating the config map is the final piece of the deployment puzzle. This ensures that Kratix knows where to find the new image. It's a simple change, but it's essential for the system to function correctly. Think of it as updating the address in your GPS so you don't get lost.

Removing redundant make targets is about cleaning up our build process. We want to get rid of any unnecessary steps and make sure that our builds are as efficient as possible. This is like decluttering your workspace so you can focus on the important tasks.

Finally, updating home scripts, quick-starts, and CI/CD pipelines is about streamlining our automation and tooling. We want to make sure that our automated processes are using the new bundled image and that everything is working smoothly. It's like automating the coffee machine so you can have a fresh cup every morning without lifting a finger.

Conclusion

Bundling the controller manager and adapter images is a significant step towards making Kratix easier to use and manage. It simplifies deployments, reduces maintenance overhead, and improves consistency. Plus, it aligns with best practices in containerization. We’re excited about these changes and how they’ll benefit the Kratix community. Stay tuned for more updates as we roll this out!