Repository navigation
Formalize Shipper strategies #260
Description
This is an epic task about re-shaping and formalisation of Shipper strategies.
On the motivation side: currently Shipper is only operational for web-serving workloads (web semantics including traffic shifting). This is not going to work for different kind of workloads, for example: data streaming processors, headless reactive daemons etc.
We have initiated this transition in #254, where we identified independent strategy execution steps and started moving things around. It seems logical that the current strategy is not the only one out there and it would make sense to formalise strategy and strategy pipelines. The next step would be to separate the default specific strategy and make it one of many possible strategies. The application manifest could specify the desired execution strategy.
In the meantime, one of the first steps could be to move target object creating from release scheduling to release strategy execution. Target object creation might be considered to be an artefact of web-specific default Shipper strategy. Imagine we define a strategy which only manipulates objects from the chart itself, in this case no explicit creation is required.
In the light of what has been said, #259 could be implemented as an horizontal autoscaling strategy, an alternative to the current static capacity strategy. Another example of it's applicability is #124, which could also be approached with a rolling update strategy. #234 can be implemented for one or a few distinct service mesh solutions.
This ticket could be used to keep track of progress on this development direction once the core team agrees it's something we want to see in Shipper.
Activity