1.8 KiB
| title |
|---|
| Overview |
Here are some workitems on the roadmap
Embed rollout in an application
We will support embedded rollout settings in an application. In this way, any changes to the application will naturally roll out in a controlled manner instead of a sudden replace.
Add support to trait upgrade
There are three trait related workitems that complement each other
- we need to make sure that traits that work on the previous application still work on the new application
- traits themselves also need a controlled way to upgrade instead of replacing the old in one shot
- rollout controller should suppress conflicting traits (like HPA/Scalar) during the rollout process
Add metrics based rolling checking
We will integrate with prometheus and use the metrics generated by the application to control the flow of the rollout. This part will be very similar to flagger.
Add traffic shifting support
We will add traffic shifting based upgrading strategy like canary, A/B testing. We plan to support Istio in our first version. This part will be very similar to flagger.
Support upgrading more than one component
Currently, we can only upgrade one component at a time. We will support upgrading more components in one application at once.
Support Helm Rollout strategy
Currently, we only support upgrading k8s resources. We will support helm based workload in the future.
Add more restrictions on what part of the rollout plan can be changed during rolling
Here are some examples
- the BatchPartition field cannot decrease beyond the current batch
- the RolloutBatches field can only change the part after the current batch
- the ComponentList field cannot be changed after rolling starts
- the RolloutStrategy/TargetSize/NumBatches cannot be changed