Title here
Summary here
Migrating to Fabrica-Based Services in OpenCHAMI
The Evolution of OpenCHAMI Services
OpenCHAMI has undergone a significant architectural evolution with the introduction of fabrica-based services. This transition marks a shift from legacy, monolithic services to modern, API-first microservices generated by the Fabrica framework. Understanding this migration is crucial for both existing operators planning upgrades and new users starting with OpenCHAMI.
From Legacy to Fabrica: What Changed
The Legacy Approach (BSS and cloud-init)
In the legacy tutorial, OpenCHAMI relied on two key services for node bootstrapping and configuration:
- BSS (Boot Script Service) - Responsible for serving iPXE boot scripts and kernel parameters to compute nodes
- cloud-init server - Handled post-boot configuration of nodes once they were booted
These services worked together but had accumulated technical debt over time. BSS, in particular, became challenging to modify due to its complex codebase and tight coupling with other components.
The Fabrica-Based Approach
The current tutorial showcases the new fabrica-generated services:
- boot-service - Replaces BSS, providing the same boot script functionality but built with Fabrica
- metadata-service - Replaces cloud-init, acting as a cloud-init server to provide node-specific configuration data based on SMD inventory; also built with Fabrica
This shift represents a fundamental change in how OpenCHAMI services are developed, maintained, and extended, and goes beyond a simple service replacement.
Why Fabrica? The Benefits of the New Approach
1. Reduced Technical Debt
As highlighted in the boot-service blog post, the motivation for creating boot-service was clear: “inheriting BSS meant that we would have to deal with the technical debt that accumulated over the years.” Fabrica-generated services start with a clean slate, incorporating modern Go practices and eliminating legacy complexities.
2. Consistency and Standardization
Fabrica enforces OpenCHAMI specifications automatically, ensuring that all generated services conform to the standards decided by the Technical Steering Committee and API working group. This means less time spent on boilerplate and more time focused on domain-specific logic.
3. Automatic Code Generation
As demonstrated in the Fabrica inventory blog post, Fabrica transforms simple Go structs into complete REST APIs with:
- CRUD HTTP handlers
- Multiple backend options (file-based for development, SQL for production)
- Auto-generated OpenAPI 3.0 documentation and Swagger UI
- Type-safe Go clients (plus an exposed client Go API)
This dramatically reduces development time and ensures consistency across services.
4. Clear Separation of Concerns
Fabrica’s Kubernetes-inspired resource structure separates spec (desired state) from status (observed state), providing a clear pattern for managing resource state that aligns with cloud-native principles.
Impact on Tutorials and Documentation
The migration is now reflected in the documentation:
Tutorial Changes
- The main tutorial now uses boot-service and metadata-service by default, introduced in OpenCHAMI v0.2.0
- Legacy tutorial is preserved for reference
- Migration guide now available
Configuration Differences
- Boot configuration now uses boot-service endpoints instead of BSS
- The ochami CLI has been updated to work with boot-service
- Service dependencies and startup order have been updated in systemd configurations
Looking Ahead: Future Deployments
The move to fabrica-based services sets the foundation for OpenCHAMI’s future:
Ongoing Service Migration
While boot-service and metadata-service are the first to be generated with Fabrica, other services are planned for migration (such as inventory-service. This will create a uniform codebase where all services benefit from Fabrica’s advantages.
Enhanced Developer Experience
New contributors can now:
- Define service resources as simple Go structs
- Use Fabrica to generate the surrounding infrastructure
- Focus on implementing business logic rather than boilerplate
- Leverage auto-generated clients and documentation
Improved Maintainability
With services built on the same framework:
- Consistent patterns across all OpenCHAMI services
- Shared tooling and debugging approaches
- Easier knowledge transfer between service teams
- Simplified dependency management
Getting Started with the New Services
For new users, the current tutorial provides a complete walkthrough of setting up OpenCHAMI with fabrica-based services. Key steps include:
- Installing the OpenCHAMI release RPM (which now includes fabrica-generated services)
- Configuring boot-service and metadata-service using server-side config
- Using the ochami CLI to manage boot configurations and node metadata (cloud-init configuration)
- Verifying service health through standard endpoints
Existing users planning migration should consult the fabrica-migration guide which provides detailed steps for transitioning from legacy deployments.
Conclusion
The migration to fabrica-based services represents a significant step forward for OpenCHAMI. By embracing modern API generation techniques, we’ve reduced technical debt, improved consistency, and created a foundation for faster innovation. While the core functionality remains familiar to existing users, the underlying architecture now supports more agile development and easier maintenance.
As OpenCHAMI continues to evolve, the fabrica-based approach will enable developers to deliver new features more rapidly while maintaining the reliability and standards that HPC environments demand. Whether you’re starting fresh with OpenCHAMI or planning an upgrade from a legacy deployment, the fabrica-based services offer a cleaner, more sustainable path forward.