runtime: Clarify UTS and mount cleanup on 'delete'

[wking]

Now that #649 allows us to get into this sort of situation. This sort of ownership may also apply to other resources (cgroups?), but we can handle them in follow-up PRs (or here, I don't mind).

Also drop “Configuration” from the root header. Everything in that file is a configuration.

[wking]

I've added a cgroup-ownership line and polished the earlier bits up slightly with abf8855 → 083f23e.

[mrunalp]

LGTM

[RobDolinMS]

@dqminh Want to take a look? This needs another maintainer.

[dqminh]

I dont know, this seems overly specified. I think the concept of "deleting resources owned only by the container" makes more sense, i.e. you dont delete changes to shared resources (i.e. when container make changes to a shared namespace ).

[wking]

I think the concept of "deleting resources owned only by the container" makes more sense…

I tried to cover that generically in the preceding paragraph. This paragraph gives some explicit examples to illustrate the concept and avoid ambiguity about who owns a given resource. Do you feel that the preceding paragraph is sufficiently clear without these more-detailed examples?

[dqminh]

Deleting a container MUST delete the resources that were created during the `create` step.
Resources associated with the container, but not created by this container, MUST NOT be deleted.

For ownership concept, it is reasonably enough for me.

I think its not harmful to have more examples to illustrate the point, but they need to be clearly spelled out as example so they wont be mistook as the only cases that we will support.

WDYT about something like:

In the following example, when the container joins an existing mount namespace on Linux and changes root with the following config.json

{
root: /new/root,
linux: { namespaces: [ {type: mount, path: /proc/1234/ns/mnt} ] },
}

deleting the container MUST not remove the existing mount namespace, and MUST not undo the changes to root

In the following example, when the container joins an existing UTS namespace on Linux and changes hostname with the following config.json

{
hostname: runtimespec,
linux: { namespaes: [{type: uts, path: /proc/1234/ns/uts} ] }
}

deleting the container MUST not remove the existing UTS namespace, and MUST not undo the changes to hostname.

[wking]

WDYT about something like…

I'm fine with a bit more hand-holding like that. To be absolutely clear that these examples were informative (and not adding new normative restrictions), I've reworded them to avoid MUST and split them off into new subsections with 083f23e → 52a5199. I've also added a similar cgroup example so we don't focus exclusively on namespaces. And I've also filled out the configs because I don't like fragments (although we have an existing fragment example here). I personally prefer the compactness of 083f23e, but maybe maintainers prefer 52a5199 or a sweet spot somewhere in between? If you want something in the middle, please give me a list of corners to cut (e.g. “drop the subsections” or “use JSON fragments for the configs”).

[wking]

And I've just pushed 52a5199 → eeacccd adding a new mount namespace to the UTS example, otherwise the (required) root.path entry would pivot the host mount namespace.

[hqhq]

I think deleting namespace is a bit overly specified, it probably is not true since on Linux, namespace is destroyed when the last process that is a member of the namespace terminates.

So if we join a shared namespace and the original container exits, our container's terminates will delete this namespace, and that's something we should not interfere.

[crosbymichael]

This is just too much over-specifying things and underlying system implementation. Its not needed in the spec.

REJECT

[crosbymichael]

I don't see why we should have examples like this in the spec at all. Its too much overspecifying things and your descriptions are wrong anyways on how namespaces are "destroyed".

[crosbymichael]

My example I know we have examples in the repo showing off how to populate fields but examples like this describing functionality/implementation don't belong in my opinion.

[crosbymichael]

Closing because we should not have implementation specific examples detailing functionality like this in the spec. The original two sentences are enough and provide the context required for runtime authors on their platforms.