serialization: Drop rootfs.type (which had only one legal value)

With 0c52d5d (serialization: remove windows-specific layers+base
rootfs, 2016-08-26, #211) this field became a single-choice field.  We
could keep the field to make the current "layers" approach explicit in
the face of future rootfs types, but we'd have to solidify the wording
around it to cover what should happen when rootfs.type was not set, or
if rootfs.type was an unrecognized value.  It seems easier to remove
it and make the "layers" approach implicit default, so that's what
this commit does.  We can restore the field later if/when we have
another rootfs type without breaking forward compatibility.

Code translating between Docker and OCI image renderings can
drop/restore this field while it is translating Docker ↔ OCI media
types, so I don't expect compatibility issues from this change.

Signed-off-by: W. Trevor King <[email protected]>

media-types.md

@@ -38,6 +38,13 @@ This section shows where the OCI Image Specification is compatible with formats
 
 - [application/vnd.docker.container.image.v1+json](https://github.com/docker/docker/blob/master/image/spec/v1.md#image-json-description)
 
+    Differences compared to the OCI schema:
+
+    * Docker's [v1.1](https://github.com/docker/docker/blob/master/image/spec/v1.1.md#container-runconfig-field-descriptions) and [v1.2](https://github.com/docker/docker/blob/master/image/spec/v1.2.md#container-runconfig-field-descriptions) declare a [`rootfs.type`] property but only document a `layers` argument.
+      The OCI configuration does not provide a `rootfs.type` property, and treats all configurations as if they used Docker's `layers` value.
+      Translators converting Docker v1.1 or v1.2 configurations to OCI configurations should error out if `rootfs.type` contains any string other than `layers`.
+      Translators converting OCI configurations to Docker v1.1 or v1.2 configurations shuold always set `rootfs.type` to `layers`.
+
 ## Relations
 
 The following figure shows how the above media types reference each other:

schema/config_test.go

@@ -136,8 +136,7 @@ func TestConfig(t *testing.T) {
       "diff_ids": [
         "sha256:9d3dd9504c685a304985025df4ed0283e47ac9ffa9bd0326fddf4d59513f0827",
         "sha256:2b689805fbd00b2db1df73fae47562faac1a626d5f61744bfe29946ecff5d73d"
-      ],
-      "type": "layers"
+      ]
     },
     "history": [
       {

schema/defs-config.json

@@ -74,9 +74,6 @@
           "items": {
             "type": "string"
           }
-        },
-        "layers": {
-          "type": "string"
         }
       }
     },

serialization.md

@@ -302,12 +302,9 @@ Note: whitespace has been added to this example for clarity. Whitespace is OPTIO
     <dd>
         The rootfs key references the layer content addresses used by the image.
 	This makes the image config hash depend on the filesystem hash.
-        rootfs has two subkeys:
+        Subkeys:
 
         <ul>
-          <li>
-            <code>type</code> is usually set to <code>layers</code>.
-          </li>
           <li>
             <code>diff_ids</code> is an array of layer content hashes (<code>DiffIDs</code>), in order from bottom-most to top-most.
           </li>
@@ -321,8 +318,7 @@ Note: whitespace has been added to this example for clarity. Whitespace is OPTIO
     "sha256:c6f988f4874bb0add23a778f753c65efe992244e148a1d2ec2a8b664fb66bbd1",
     "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef",
     "sha256:13f53e08df5a220ab6d13c58b2bf83a59cbdc2e04d0a3f041ddf4b0ba4112d49"
-  ],
-  "type": "layers"
+  ]
 }</pre>
     </dd>
     <dt>

specs-go/v1/config.go

@@ -49,9 +49,6 @@ type ImageConfig struct {
 
 // RootFS describes a layer content addresses
 type RootFS struct {
-	// Type is the type of the rootfs.
-	Type string `json:"type"`
-
 	// DiffIDs is an array of layer content hashes (DiffIDs), in order from bottom-most to top-most.
 	DiffIDs []string `json:"diff_ids"`
 }