49 lines
1.8 KiB
Markdown
49 lines
1.8 KiB
Markdown
---
|
|
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
|