Principle:SeldonIO Seldon core Pipeline Version Progression
| Property | Value |
|---|---|
| Principle Name | Pipeline Version Progression |
| Overview | Incrementally evolving a pipeline's capabilities by adding monitoring steps across successive versions |
| Domains | MLOps, Versioning |
| Related Implementation | SeldonIO_Seldon_core_Seldon_Pipeline_Version_Update |
| Knowledge Sources | Repo (https://github.com/SeldonIO/seldon-core), Doc (https://docs.seldon.io/projects/seldon-core/en/v2/) |
| Last Updated | 2026-02-13 00:00 GMT |
Description
Seldon pipelines support seamless in-place version updates. A pipeline can evolve progressively by resubmitting updated Pipeline CRDs with the same pipeline name. Each version adds new steps without disrupting existing functionality:
- Version 1 - Classifier only (basic inference)
- Version 2 - Classifier + drift detection with batch aggregation
- Version 3 - Classifier + preprocessing + outlier detection + drift detection (full monitoring)
The pipeline version number increments automatically with each update, providing a clear audit trail of pipeline evolution.
Theoretical Basis
Progressive pipeline evolution follows the expand-and-contract pattern:
Expand Phase
New steps are added to the pipeline definition:
- The updated Pipeline CRD is submitted with the same pipeline name
- The Seldon scheduler detects the change and creates new Kafka topics for new steps
- New models are loaded (if not already available)
- The pipeline version increments atomically
Atomic Version Transition
The transition between pipeline versions is atomic:
- Requests in-flight are processed by the current version
- New requests are routed to the updated version
- No requests are dropped during the transition
- The pipeline version number provides rollback reference
Rollback Capability
Previous pipeline versions can be restored by resubmitting the earlier definition. Since the pipeline is identified by name, submitting a v1 definition after running v3 will effectively roll back the pipeline to classifier-only mode. All monitoring steps are gracefully removed.
Progressive Monitoring Value
The version progression reflects increasing monitoring maturity:
| Version | Capabilities | Monitoring Level |
|---|---|---|
| v1 | Classifier predictions only | None |
| v2 | Predictions + drift detection | Distribution monitoring (batched) |
| v3 | Predictions + outlier detection + drift detection | Full monitoring (per-request + batched) |
Usage
Use this principle when gradually adding monitoring capabilities to an existing production pipeline. The progressive approach is valuable when:
- Incremental rollout is preferred over big-bang deployment
- Risk mitigation requires validating each monitoring component independently
- Resource constraints require staged infrastructure provisioning
- Team readiness varies for different monitoring dimensions
The typical progression sequence is:
- Deploy v1 with the classifier for baseline inference
- Validate inference quality and performance
- Deploy v2 adding drift detection to establish distribution baselines
- Monitor drift detection accuracy and tune batch sizes
- Deploy v3 adding preprocessing and outlier detection for full monitoring coverage
Related Pages
- SeldonIO_Seldon_core_Seldon_Pipeline_Version_Update (implements this principle) - Concrete pattern for progressive pipeline version updates
- SeldonIO_Seldon_core_Monitoring_Pipeline_Definition (related) - Full monitoring pipeline definition (equivalent to v3)
- SeldonIO_Seldon_core_Seldon_Pipeline_CRD_Monitoring (related) - Monitoring pipeline CRD pattern
- SeldonIO_Seldon_core_Monitoring_Pipeline_Validation (applies to each version) - Validating pipeline readiness after each version update
- SeldonIO_Seldon_core_Monitoring_Component_Deployment (prerequisite) - Component models must be deployed before version updates
Implementation:SeldonIO_Seldon_core_Seldon_Pipeline_Version_Update