Repository navigation
Add controller-based architecture specification - #558
Closed
greghaynes wants to merge 8 commits into
Closed
greghaynes wants to merge 8 commits into
greghaynes wants to merge 8 commits into
Conversation
This specification document proposes a significant architectural evolution to transition idpbuilder from a CLI-driven installation model to a controller-based architecture. Key changes include: - New Platform CR to orchestrate the entire IDP platform - Dedicated controllers for ArgoCD, Gitea, and Nginx components - Enhanced GitRepository and new Package CRs - Clear separation between infrastructure and platform services - 7-phase implementation plan over 20 weeks - Migration strategy with backward compatibility - Support for production workloads and virtualized control planes The new architecture will enable Kubernetes-native management through kubectl and GitOps tools, improve observability and debugging, and provide better extensibility for third-party integrations. Signed-off-by: Greg Haynes <greg@greghaynes.net>
Make the implementation plan phase-based without specific week durations to allow for more flexible planning and execution. Signed-off-by: Greg Haynes <greg@greghaynes.net>
Enable flexible provider selection for key platform components: - Git Provider: Support for Gitea (in-cluster), GitHub (external), and GitLab (future) - Gateway Provider: Support for Nginx Ingress, Envoy Gateway, and Istio Gateway (future) Key changes: - Replaced GiteaComponent and NginxComponent with GitProvider and Gateway CRs - Added provider field to allow selection between implementations - Updated Platform CR to support provider-specific configuration - Added GitProviderReconciler and GatewayReconciler with pluggable provider factories - Included examples for GitHub + Envoy Gateway configuration - Updated all diagrams and documentation to reflect provider model This architecture enables: - Using external Git providers (GitHub/GitLab) without in-cluster Git - Modern gateway implementations (Envoy/Istio) alongside Nginx - Easier testing and development with different provider combinations - Future extensibility for additional provider implementations Signed-off-by: Greg Haynes <greg@greghaynes.net>
Change Git provider architecture to use individual CR types instead of a single GitProvider CR with embedded configuration. This improves modularity and enables multiple providers simultaneously. Key changes: - Introduce separate CR types: GiteaProvider, GitHubProvider, GitLabProvider - Each provider type has its own reconciler - Define duck-typed interface with common status fields: * endpoint: External URL for UI/cloning * internalEndpoint: Cluster-internal API URL * credentialsSecretRef: Authentication credentials - Platform CR references a collection of provider CRs instead of inline config - GitRepository and other consumers use unstructured access to read common fields from any provider type Benefits: - Support multiple Git providers simultaneously (e.g., Gitea + GitHub) - Clear separation of concerns - each provider is independent - Easy to add new provider types without changing Platform CR - Other controllers can use any provider generically via duck typing - Provider CRs can exist independently and be shared across platforms - Simpler testing - can test each provider type in isolation Gateway providers updated similarly with NginxGateway, EnvoyGateway, etc. Duck typing pattern follows Kubernetes conventions (like Service, Ingress) allowing flexible composition without tight coupling. Signed-off-by: Greg Haynes <greg@greghaynes.net>
Refactor gateway architecture to use separate provider CR types with duck-typed common interface, mirroring the Git provider pattern. Key changes: - Replace single Gateway CR with provider-specific types: * NginxGateway - Nginx Ingress Controller * EnvoyGateway - Envoy Gateway * IstioGateway - Istio service mesh gateway - Each gateway provider has dedicated reconciler - Define duck-typed status interface: * ingressClassName: For creating Ingress resources * loadBalancerEndpoint: External access URL * internalEndpoint: Cluster-internal API endpoint - Platform CR uses 'gateways' collection for multiple gateway references - Added utility functions for duck-typed gateway provider access - Included detailed reconciler implementations for each provider type Benefits: - Support multiple gateway implementations simultaneously (e.g., Nginx for public traffic, Envoy for internal/service mesh) - Clear separation of concerns - each gateway provider is independent - Easy to add new gateway types (Traefik, Kong, etc.) - Components can dynamically choose which gateway to use - Ingress resources work with any provider via ingressClassName - Simpler testing with isolated provider reconcilers Added examples: - Multi-gateway configuration showing Nginx + Envoy - Component controller using duck-typed gateway access - Ingress creation working with any gateway provider type This completes the duck-typing pattern across both Git and Gateway providers, enabling true composability and extensibility. Signed-off-by: Greg Haynes <greg@greghaynes.net>
Revise architecture diagram and description to accurately represent the new provider-based design with duck-typed interfaces. Changes: - Updated diagram to show separate provider controller groups * Git Provider Controllers box with Gitea/GitHub/GitLab reconcilers * Gateway Provider Controllers box with Nginx/Envoy/Istio reconcilers - Each provider reconciler shows exposed duck-typed fields - Platform Services layer shows multiple providers coexisting - Added concrete examples of provider combinations: * Gitea for dev + GitHub for production * Nginx for public + Envoy for service mesh Added Key Architecture Principles section: 1. Duck Typing - common status fields without shared interface type 2. Composition - Platform references providers by name and kind 3. Extensibility - new providers without Platform CR changes 4. Independence - providers can exist and be managed separately 5. Flexibility - runtime provider selection by components Updated PlatformReconciler description: - References provider CRs instead of creating component CRs - Focuses on orchestration and status aggregation Updated reconciler descriptions: - GitRepositoryReconciler works with ANY Git provider - PackageReconciler references Git providers dynamically The design now clearly shows the composable, multi-provider architecture that enables production-grade flexibility. Signed-off-by: Greg Haynes <greg@greghaynes.net>
Extend the duck-typing architecture to GitOps management, replacing ArgoCDComponent CR with separate provider types for ArgoCD and Flux. Key changes: - Replace ArgoCDComponent with GitOps provider CRs: * ArgoCDProvider - ArgoCD GitOps engine * FluxProvider - Flux GitOps toolkit - Each GitOps provider has dedicated reconciler - Define duck-typed status interface: * endpoint: External URL for web UI * internalEndpoint: Cluster-internal API endpoint * credentialsSecretRef: Admin credentials - Platform CR updated to use 'gitOpsProviders' collection - Platform CR now only contains provider references (no inline component config) - Platform status aggregates provider status from referenced CRs - Added utility functions for duck-typed GitOps provider access - Included detailed reconciler implementations for both providers Benefits: - Support multiple GitOps implementations simultaneously (e.g., ArgoCD for applications, Flux for infrastructure) - Clear separation of concerns - each provider is independent - Easy to add new GitOps providers (e.g., Jenkins X) - Package controllers can dynamically choose which GitOps provider to use - Different teams can use different GitOps tools - Simpler testing with isolated provider reconcilers Updated documentation: - Platform CR spec now purely references providers (no inline configs) - Platform status aggregates provider readiness - High-level design diagram shows GitOps Provider Controllers box - Platform Services layer includes GitOps Providers - Bootstrap flow reflects provider-based architecture - Component interaction diagram shows provider references - Examples show multi-GitOps provider configuration - RBAC section includes all provider reconciler permissions - Phase 1 and Phase 2 updated with GitOps provider CRDs and reconcilers Architecture principles: 1. Duck Typing - common status fields without shared interface 2. Composition - Platform references providers by name and kind 3. Extensibility - add providers without Platform CR changes 4. Independence - providers exist and managed separately 5. Flexibility - runtime provider selection by components This completes the duck-typing pattern across Git, Gateway, and GitOps providers, creating a fully composable platform architecture. Signed-off-by: Greg Haynes <greg@greghaynes.net>
- Phase 1: Core end-to-end with existing providers (Gitea, Nginx, ArgoCD) - Phase 2: CLI integration and migration path - Phases 3-7: Incremental alternative provider additions - Phase 8: Production features and stabilization This approach validates the architecture early with a narrow vertical slice before adding alternative providers, reducing risk and enabling faster value delivery. Signed-off-by: Greg Haynes <greg.haynes@siemens.com>
Contributor
|
Why have you closed this PR ? @greghaynes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This specification document proposes a significant architectural evolution to transition idpbuilder from a CLI-driven installation model to a controller-based architecture. Key changes include:
The new architecture will enable Kubernetes-native management through kubectl and GitOps tools, improve observability and debugging, and provide better extensibility for third-party integrations.