These actions need consistent tooling, and they're the sweet spot for
tools like runc. Once you map the container spec to the filesystem,
the other actions (copy, snapshot, upload, download) can all be
handled by existing tools (e.g. POSIX's 'cp', 'btrfs subvolume
snapshot', netcat, etc.). If existing tooling for those actions is
not sufficiently portable, new portable tools can be written, but that
should be separate from the container-specific stuff here.
I'm not sure about the intended meaning of the 'tagged' action. Was
that intended for discoverability ("I want a container named 'Nginx'")
or auth ("Is my local /srv/nginx the same container 'Nginx' that Bob
audited?"). I think both are independent of the container runtime
though.
We had an in-person spec discussion, lets separate the spec into some
high-level sections to clarify future discussion.
Crosby agreed to let me merge to master :)
Lai Jiangshan
Michael Crosby
W. Trevor King
Brandon Philips
Patrick Chanezon