Keep BuildKit state in a volume

[crazy-max]

Retain BuildKit state inside a named volume if the container is removed for the docker-container driver. --volume flag has also been added to the rm command to be able to force volume removal.

Signed-off-by: CrazyMax [email protected]

[tonistiigi]

But where is the volume created on create?

I wonder if for backward compatibility we should remove volume by default. Or print a warning that volume is still there and data was not released. Maybe there is a good opt-in flag that is opposite of --rm. Most of the time I think users want to remove volume. @thaJeztah

I guess we could revisit the deletion path once upgrade command is added in the future. I guess then rm always deletes volume(or at least by default). And upgrade performs rm+create without touching the volume.

[crazy-max]

@tonistiigi

Most of the time I think users want to remove volume.

Agree, just wanted to keep the same UX as other commands of the Docker CLI but maybe it's not legitimate in this case.

[thaJeztah]

Retain BuildKit state inside a named volume if the container is removed for the docker-container driver. --volume flag has also been added to the rm command to be able to force volume removal.

Haven't looked closely at the changes, but be aware that --volume only removes anonymous (unnamed) volumes, and won't remove "named" volumes; from docker rm --help:

-v, --volumes   Remove anonymous volumes associated with the container

[crazy-max]

@thaJeztah

--volume only removes anonymous (unnamed) volumes

In our case it's not so yes that's confusing.

I have changed the behavior to be backward compatible with an opt-in flag called --keep-state instead.

[thaJeztah]

In our case it's not so yes that's confusing.

Reason for that is that anonymous volumes are commonly used as temporary / ephemeral storage. docker rm -v <some container> is somewhat the equivalent of docker run --rm <some image with a VOLUME>. When naming a volume, in most cases that's for a reason (being able to reference the volume later), and we don't want to inadvertently remove my_important_database_volume.