"kubecfg update pods" returns an error

[darkgaro]

I am trying to update an existing pod with :
/opt/bin/kubecfg -c framework-dev.json update pods/app-instance-dev

but as soon as I run the above command I get an error :
F1010 01:49:29.804442 21400 kubecfg.go:395] Got request error: unimplemented!

Original pod:

{
  "id": "app-instance-dev",
  "kind": "Pod",
  "apiVersion": "v1beta1",
  "desiredState": {
    "manifest": {
      "version": "v1beta1",
      "id": "app-instance-dev",
      "containers": [{
        "name": "framework",
        "image": "registry.domain/dev-framework",
        "ports": [{
          "containerPort": 80,
          "hostPort": 80
        }],
        "volumeMounts": [{"name": "data", "mountPath":"/data"}],
        "imagePullPolicy": "PullIfNotPresent",
      }],
      "volumes": [{
        "name": "data",
        "source": {"emptyDir": {}}
         }]
    }
  },
  "labels": {
    "name": "app-instance"
  }
}

new pod :

{
  "id": "app-instance-dev",
  "kind": "Pod",
  "apiVersion": "v1beta1",
  "desiredState": {
    "manifest": {
      "version": "v1beta1",
      "id": "app-instance-dev",
      "containers": [{
        "name": "framework",
        "image": "registry.domain/dev-framework:v0.1.1",
        "ports": [{
          "containerPort": 80,
          "hostPort": 80
        }],
        "volumeMounts": [{"name": "data", "mountPath":"/data"}],
        "imagePullPolicy": "PullIfNotPresent",
      }],
      "volumes": [{
        "name": "data",
        "source": {"emptyDir": {}}
         }]
    }
  },
  "labels": {
    "name": "app-instance"
  }
}

Only difference is that new pod is retrieving a new image tag.

Does that mean that this functionality is not implemented yet ? if so is there then no way to update a POD ??? that seems a pretty essential functionality. Maybe I am missing something here ?

Thanks

[thockin]

I think your interpretation is correct.

[brendandburns]

We had deferred updating a pod until a later date, because there are basically two different kinds of updates.

There are updates that require that the container be restarted (updating the image for example) and there are updates that you can do in place (increasing the amount of CPU)

Right now, every update requires a pod restart, and if you are going to do that, then you may as well just create a new pod, and then tear down the other pod.

That said, there's no reason not to just do the update in place, and let the kubelet restart the pod, so I'll file a PR to do that, the kubelet already does hashing and will do the appropriate thing.

[darkgaro]

As far as I understand it right now problem is that if I tear down a pod to make an update, aren't I going to loose the "emptyDir" volume which if you look at my pod example is currently part of the pod. In my case I want to keep the same volume but just upgrade one container, I don't want to loose the volume.

Also what if I have a pod that has few other containers, but I only really want to update one container, by tearing down the pod aren't I going to loose all those containers. If that's the case we kind of loose the usefulness of docker modularity since it becomes all or nothing situation.

I kind of expected the pods to be more of a loose grouping or encapsulation of containers for the purposes of management and services exposure and not so tightly connected to become one new entity where operations are performed always on all containers.

[brendandburns]

Yes, you're definitely correct.

It's implemented this way on the kubelet, we just need to get the right data into the right places... I think the PR will be done this evening.

--brendan

[darkgaro]

Oh ok that's good to hear then :) Thanks for confirming that.

[brendandburns]

#1713 has the fix.

[dchen1107]

Are we going to support in-place update, and defer non-in-place one? Also increasing a container's CPU limit cannot always be treated as in-place update. For example, scheduler already overcommit a node on CPU, and user wants to increase one container's CPU on that node, which might result in a pod rescheduling.

[brendandburns]

I'm defering in place update. Right now the kubelet hashes the container config, and if it changes it restarts the container. So it restarts on any change. We'll use that behavior for now.

[lavalamp]

IMO: Make a new pod, delete the old one. If you need zero-latency restarts, you do that by starting up replicationControllers and turning the old one down while you turn the new one up (we'll automate this in the future). With the possible exception of metadata, pods should be immutable after they're scheduled.