Allow Updates

[rjnagal]

Collecting Update requirements and use-cases for the working group.

We should be able to update a running container. There are a few simple updates like resources for vertical scaling of containers (memory, cpu) that should be allowed. Adding a volume is another possible use-case.

Do we split the config into immutable and mutable parts? The updates can be done out of band, but we would like the config to reflect reality of the running state.

Hopefully, we can collect more requirement and concerns before handing it over to a working group.

[philips]

I have been noodling over this one for a few days and I think we do indeed need to split the configuration into two parts, perhaps even two files, to make the difference between clear.

How do we make this distinction? I would argue the delineation is around what the application needs to operate as far as namespaces and security and then what host resources it is allowed to consume on the host.

Application Configuration

• seccomp filters, capabilities, SELinux/apparmor
• namespaces
• rlimits (for app defaults)
• sysctl
• device cgroups (may merge with host configuration)

Host Resource Configuration

• user namespace mapping
• resource cgroups (mem, cpu, disk, network, block)
• sysctls
• mounts
• create a new device node/device cgroups (may merge with host configuration)

This is something that has been discussed a few times in appc in two contexts:

1. The first discussion started about when, if ever, it makes sense for applications to define how much memory, cpu, etc it can consume. Does it make sense for mysql to ever say "memory: 4Gb" in the application configuration? Probably not. We allow images to specify values like memory but they are almost always overridden at runtime.
2. Recently again we talked about the distinction between a resource isolator and a security isolator (spec: security and isolators conflated? appc/spec#349). This tries to draw the line around security vs isolation but I think that can confuse the mental model since there are things like user namespace maps that are used for security but only make sense once you start running on a host.

I think the evolution on my thinking here is drawing the line along what makes sense only once running on a host vs what is static and describes the application's needs.

So, yes, I think we need to be able to design for updating a running container and the things that should be updatable are logically different enough that we should attempt to separate them clearly.

[philips]

We know we are going to want a state file for the bundle so that a user can hunt down the owning PID, etc. So, I think a reasonable thing to do is say that certain sections of the config.json will show up in the state.json file. As a rough straw man it would essentially look like this:

{
  "version": "v0.1.0"
  "process": 8503,
  "dynamic": {
    "resources": {
       "cgroup stuff"
    },
    "sysctl": {
       sysctl stuff
    },
    "rlimits": {
       rlimits stuff
    },
  }
} 

Big open question @rjnagal: How would a user affect change on the container? Would an external system (docker/rkt/etc) rewrite this json to establish a desired state then call a reconciliation loop? Or something else?

https://github.com/opencontainers/runc/blob/master/spec_linux.go#L25-L27

[philips]

Also, here is the mega thread on lifecycle and updates on appc: appc/spec#276. A number of issues we are going to have to think through are discussed at length if we need points of reference.

[cyphar]

This may be related to #493.