GitHub user mmodzelewski created a discussion: Configuration Storage Trait for Connectors Runtime
## Overview I'd like to propose extending the connectors runtime to support pluggable configuration storage through a trait-based approach. This would align the connectors runtime configuration management with the patterns already established in the Iggy server. ## Proposed Changes ### 1. Configuration Storage Trait Introduce a trait that abstracts configuration storage operations. This would enable: - **Default file-based implementation**: Maintaining backward compatibility with the current file-based configuration system - **API-backed implementation**: Supporting dynamic configuration management through a remote configuration API - **Future extensibility**: Allowing additional storage backends (e.g., database, etcd, consul) without modifying core logic ### 2. Extended Connectors API Enhance the connectors API layer to support: - **PUT endpoints**: Enable updating connector configurations at runtime - **RESTful configuration management**: Provide a consistent API surface for configuration CRUD operations ## Benefits 1. **Consistency**: Aligns connectors runtime with Iggy server's configuration management approach 2. **Flexibility**: Enables dynamic configuration updates without restarts 3. **Operational improvements**: Supports centralized configuration management in distributed deployments 4. **Backward compatibility**: File-based configuration remains the default, ensuring existing setups continue to work ## Use Cases - Dynamic connector reconfiguration in production environments - Centralized configuration management across multiple connector instances - Integration with configuration management systems and GitOps workflows ## Questions for Discussion 1. Should configuration updates trigger automatic connector restarts, or should this be configurable? 2. What validation and rollback mechanisms should be in place for configuration changes? 3. Should we support configuration versioning and audit logging? 4. Are there specific configuration API backends we should prioritize beyond the default file-based implementation? Looking forward to hearing your thoughts! GitHub link: https://github.com/apache/iggy/discussions/2343 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
