Add support for anonymous volumes

[realrajaryan]

• Closes [Request]: Support anonymous volumes #726.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

Adds support for anonymous volumes. Users can now create volumes without explicit naming using -v /path and --mount type=volume,dst=/path syntax.

Usage:

# anonymous volume  
container run -v /data alpine
container run -v anon-01k7jpghe4kg4ph5a4vkccksbb:/data alpine

# Multiple anonymous volumes
container run --rm -v /logs -v /cache -v /tmp alpine

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

[jglogan]

Why not just use plain UUIDv4? Containers do the same if no --name is provided, and it keeps the PR simpler.

[jglogan]

What purpose do these labels serve?

[jglogan]

I think I'd prefer that we don't do what Docker does, at least for now:

Just like named volumes, anonymous volumes persist even if you remove the container that uses them, except if you use the --rm flag when creating the container, in which case the anonymous volume associated with the container is destroyed.

IMO it introduces a bunch of server-side complexity that we can add later should we need it. Perhaps we can approach the problem of pruning such volumes creatively to make up for the lack of the --rm anonymous volume feature.

[egernst]

I always wondered what the use case is/was with respect to anonymous not being tied to workload.

[dcantah]

Is the complexity for the server that much though? I think we're (as we've found 😄) somewhat beholden to the behavior of other tools regardless, and Docker's behavior somewhat makes sense to me here. I think the outcome of not following this --rm behavior is a little more devious than others (like not supporting some flag they did, which is minor in most cases) as if folks have gotten used to --rm being the "nuke this thing please" button, if we didn't follow suit they may be surprised after 100 container runs with -v /whatever to find they have a bunch of volumes filling up their disk.

[jglogan]

It's not whether it's too complex for the server. I'd rather do it as two smaller PRs if we're going to do it.

I also don't like us having to drop a bunch of extra fields in our core structs for anonymous and have to broaden the API when we're already using reserved labels for resource scope/role hints.

Let's get the basic stuff in place and do the cleanup in a follow-up PR.

I always wondered what the use case is/was with respect to anonymous not being tied to workload.

"I don't care about the volume name but I want the data around for later."

I agree that it's a bit of a tenuous use case.

[jglogan]

My preference is for no anon-. Then unnamed containers and volumes follow the same naming convention.

[jglogan]

Let's discuss using either com.apple.container.resource.role=anonymous, or com.apple.container.resource.anonymous like you're using it now.

[jglogan]

It's a UUID now, could just say "Generate a random name"

[jglogan]

Could we just check whether the volume is anonymous here, and if so create it, instead of all the retroactive checking in the exception handler?

[jglogan]

For the future, we should probably sort everything this way.

[jglogan]

This seems fine. If we have this, anon- on the name really does seem superfluous.