From 80a464d0969417bdfad6de73984de20261ee8241 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Thu, 25 Jun 2015 11:37:24 -0700 Subject: [PATCH] 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. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b44ded87..a3ae9587 100644 --- a/README.md +++ b/README.md @@ -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