Remove requirement to increase the StackSet version

[linki]

StackSet and Stack resources are inspired by the relationship between ReplicaSet and Pods (and also Deployment and ReplicaSet I would say).

When I modify a Deployment object (an in-place update) Kubernetes will seek ReplicaSets matching the desired podTemplate spec and create them for the new version if not present.

Similarly, when I update a StackSet in-place and change the stackTemplate spec a new Stack is created for that version. However, to make it really working one also has to increase the stackVersion field which is transparent in the Deployment/ReplicaSet case (presumeably via the pod-template-hash label).

[mikkeloscar]

I tried to explain (internally) the reasons for designing it the current way. Will dump what I wrote here:

So the basic idea is that a StackSet declares what a stack should look like in this moment of time.
Since we want multiple stacks over time for switching traffic the version will also change each time we declare a new state.

Another solution would be to omit the version from the StackSet declaration and then rely on the system generating a new revision for each new version of the StackSet. This is for instance how a Deployment works with ReplicaSets.

The problem of a dynamically generated revision though, is that it becomes harder to map a deployment (CDP), to the resulting stack.
Imagine, you as a user, want to find the pods of a certain CDP deployment. If the revision is dynamic you can not map it directly to the CDP_BUILD_VERSION (or whatever format you use), but if you declared it at deployment time and this is used as the stack name ({stackset.Name}-{version}), then it's easy to map it.
Another benefit is that you don't have to resolve the new stack version after a deployment in order to interact with it. If you have a smoke_test step where you want to call the service endpoint of the stack, then it's easier if you know it has the name {stackset.Name}-{version} rather than figuring out what something like {stackset.Name}-{dynamic-revision} resolves to.

An additional "feature" of this design is that you can declare version: "static" which would then result in a single stack that is updated whenever the StackSet is updated. This will not allow for traffic switching but will give the behaviour of rolling updates with the benefits of the life cycle that the StackSet abstraction provides (automatic generation and dependency management of the lower level resources; Service, Deployment, HPA etc.).

Does this make sense?

[mikkeloscar]

@linki and I talked more about this today and it would be cool to support the following use cases:

• manually set the version so it's easy to control from a CD pipeline
• Set a static version which means only one stack will be created for a stackset
• Automatic version generation based on hash(stacktemplate).