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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
