jasder
/
runc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

README: Focus on local runtime (create/start/stop) 

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.
This commit is contained in:
W. Trevor King 2015-06-25 11:37:24 -07:00
parent e7e34ba6f4
commit 80a464d096
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -19,7 +19,7 @@ A great analogy for this is the shipping container. Just like how Standard Conta
## 1. Standard operations
Just like shipping containers, Standard Containers define a set of STANDARD OPERATIONS. Shipping containers can be lifted, stacked, locked, loaded, unloaded and labelled. Similarly, Standard Containers can be started, stopped, copied, snapshotted, downloaded, uploaded and tagged.
Just like shipping containers, Standard Containers define a set of STANDARD OPERATIONS. Shipping containers can be lifted, stacked, locked, loaded, unloaded and labelled. Similarly, Standard Containers can be created, started, and stopped using standard container tools (what this spec is about); copied and snapshotted using standard filesystem tools; and downloaded and uploaded using standard network tools.
## 2. Content-agnostic