Documentation
¶
Index ¶
Constants ¶
const ( // ComponentName is the unique identifier for this component. ComponentName = "configchange-handler" // EventBufferSize is the size of the event subscription buffer. // Size 50: Moderate-volume component handling config and validation events. EventBufferSize = 50 )
const ( // StatusUpdaterComponentName is the unique identifier for this component. StatusUpdaterComponentName = "status-updater" // StatusUpdaterEventBufferSize is the size of the event subscription buffer. StatusUpdaterEventBufferSize = 50 )
Variables ¶
var DefaultReinitDebounceInterval = types.DefaultDebounceInterval
DefaultReinitDebounceInterval is the default time to wait after the last config change before signaling controller reinitialization. This allows rapid CRD updates to be coalesced, ensuring templates are fully rendered before reinitialization starts. Uses the centralized debounce interval from types package.
Functions ¶
This section is empty.
Types ¶
type ConfigChangeHandler ¶
type ConfigChangeHandler struct {
// contains filtered or unexported fields
}
ConfigChangeHandler coordinates configuration validation and detects config changes.
This component has two main responsibilities:
Validation Coordination: Subscribes to ConfigParsedEvent, sends ConfigValidationRequest, collects responses from validators using scatter-gather pattern, and publishes ConfigValidatedEvent or ConfigInvalidEvent.
Change Detection: Subscribes to ConfigValidatedEvent and signals the controller to reinitialize via the configChangeCh channel with debouncing to coalesce rapid changes.
Debouncing behavior: When multiple CRD config changes arrive in rapid succession, the handler debounces the reinitialization signal. This ensures all pending renders complete before reinitialization starts, preventing the race condition where reinitialization cancels in-progress renders.
Architecture: This component bridges the gap between configuration parsing and validation, and between validation and controller reinitialization. It uses the scatter-gather pattern from the event bus for coordinating validation across multiple validators.
func NewConfigChangeHandler ¶
func NewConfigChangeHandler( eventBus *busevents.EventBus, logger *slog.Logger, configChangeCh chan<- *coreconfig.Config, validators []string, debounceInterval time.Duration, ) *ConfigChangeHandler
NewConfigChangeHandler creates a new ConfigChangeHandler.
Parameters:
- eventBus: The EventBus to subscribe to and publish on
- logger: Structured logger for diagnostics
- configChangeCh: Channel to signal controller reinitialization with validated config
- validators: List of expected validator names (e.g., ["basic", "template", "jsonpath"])
- debounceInterval: Time to wait after last config change before triggering reinitialization. Use 0 for default (500ms).
Returns:
- *ConfigChangeHandler ready to start
func (*ConfigChangeHandler) EnableReinitialization ¶
func (h *ConfigChangeHandler) EnableReinitialization()
EnableReinitialization enables the reinitialization signaling mechanism.
This must be called after controller startup is complete to allow config changes to trigger reinitialization. During startup, ConfigValidatedEvents occur that should NOT trigger reinitialization. Calling this method signals that the startup phase is complete and future config changes should trigger reinitialization.
Note: CRDWatcher uses generation-based filtering, so status-only updates (which don't increment generation) never trigger ConfigValidatedEvents in the first place.
func (*ConfigChangeHandler) SetInitialConfigVersion ¶
func (h *ConfigChangeHandler) SetInitialConfigVersion(version string)
SetInitialConfigVersion sets the initial config version to prevent reinitialization on bootstrap ConfigValidatedEvent.
This must be called after fetching the initial config but before CRDWatcher starts. When CRDWatcher's informer triggers onAdd for the existing CRD, it publishes a ConfigValidatedEvent with the same version. Without this tracking, that event would trigger reinitialization, creating an infinite loop.
Parameters:
- version: The resourceVersion from the initial CRD fetch
func (*ConfigChangeHandler) Start ¶
func (h *ConfigChangeHandler) Start(ctx context.Context) error
Start begins processing events from the EventBus.
This method blocks until Stop() is called or the context is canceled. The component is already subscribed to the EventBus (subscription happens in constructor). Returns nil on graceful shutdown.
Example:
go handler.Start(ctx)
func (*ConfigChangeHandler) Stop ¶
func (h *ConfigChangeHandler) Stop()
Stop gracefully stops the component.
type StatusUpdater ¶
type StatusUpdater struct {
// contains filtered or unexported fields
}
StatusUpdater updates HAProxyTemplateConfig status based on validation results.
This component subscribes to ConfigValidatedEvent, ConfigInvalidEvent, and ValidationFailedEvent, updating the HAProxyTemplateConfig CRD status to reflect validation state. Users can then see validation errors via `kubectl describe haproxytemplateconfig`.
Architecture: This is an event adapter that bridges validation events to Kubernetes API updates. It uses the generated typed client for HAProxyTemplateConfig status updates.
The component handles two types of validation: - Config validation (Stage 1): Template syntax, JSONPath expressions, etc. - HAProxy validation (Stage 4): Rendered config syntax check with haproxy -c.
func NewStatusUpdater ¶
func NewStatusUpdater( crdClient versioned.Interface, eventBus *busevents.EventBus, logger *slog.Logger, ) *StatusUpdater
NewStatusUpdater creates a new StatusUpdater.
Parameters:
- crdClient: Kubernetes client for HAProxyTemplateConfig CRD
- eventBus: EventBus to subscribe to validation events
- logger: Structured logger for diagnostics
Returns:
- *StatusUpdater ready to start
func (*StatusUpdater) Name ¶
func (u *StatusUpdater) Name() string
Name returns the component name for lifecycle management.