Open Stack

On 05/22/2017 12:01 PM, Zane Bitter wrote:
> On 19/05/17 17:59, Matt Riedemann wrote:
>> I'm not really sure what you're referring to here with 'update' and [1].
>> Can you expand on that? I know it's a bit of a tangent.
> 
> If the user does a stack update that changes the network from 'auto' to 
> 'none', or vice-versa.

Detour here, apologies...

Why would it matter whether a user changes a stack definition for some 
resource from auto-created network to none? Why would you want 
*anything* to change about instances that had already been created by 
Heat with the previous version of the stack definition?

In other words, why shouldn't the change to the stack simply affect 
*new* resources that the stack might create? After all, get-me-a-network 
is intended for instance *creation* and nothing else...

Why not treat already-provisioned resources of a stack as immutable once 
provisioned? That is, after all, one of the primary benefits of a "cloud 
native application" -- immutability of application images once deployed 
and the clean separation of configuration from data.

This is one of the reasons that the (application) container world has it 
easy with regards to resource management. If you need to change the 
sizing of a deployment [1], Kubernetes doesn't need to go through all 
the hoops we do in resize/migrate/live-migrate. They just blow away one 
or more of the application container replicas [2] and start up new ones. 
[3] Of course, this doesn't work out so well with stateful applications 
(aka the good ol' Nova VM), which is why there's a whole slew of 
constraints on the automatic orchestration potential of StatefulSets in 
Kubernetes [4], constraints that (surprise!) map pretty much one-to-one 
with all the Heat resource dependency management bugs that you 
highlighted in a previous ML response (network identifier is static and 
must follow a pre-described pattern, storage for all pods in the 
StatefulSet must be a PersistentVolume, updating a StatefulSet is 
currently a manual process, etc).

Best,
-jay

[1] A deployment in the Kubernetes sense of the term, ala
https://kubernetes.io/docs/concepts/workloads/controllers/deployment

[2] 
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L508

[3] In fact, changing the size/scale of a deployment *does not* 
automatically trigger any action in Kubernetes. Only changes to the 
configuration of the deployment's containers (.spec.template) will 
automatically trigger some action being taken.

[4] 
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#limitations