1
0
mirror of https://github.com/opencontainers/runtime-spec.git synced 2026-02-05 09:45:57 +01:00
Files
runtime-spec/schema/config-solaris.json
W. Trevor King 4e5a137fc1 schema: Completely drop our JSON Schema 'id' properties
We're using JSON Schema draft-04 [1], as declared by our '$schema'
properties [2].  In draft-04, the 'id' keyword alters the resolution
scope.  But our current '$ref' values use JSON Pointers [3,4] with
relative references like 'defs-linux.json#/definitions/Device' that
ignore the 'id's.

By draft-07, 'id' has become '$id', and [5]:

  The root schema of a JSON Schema document SHOULD contain an "$id"
  keyword with a URI (containing a scheme).

But since [6], including any URI that cannot be retrieved generates an
error:

  $ ./validate config-schema.json test/config/good/minimal.json
  Could not read schema from HTTP, response status is 404 Not Found

While a root 'id' entry would be nice, we don't currently host these
anywhere with a useful URI.  We could use [7], but then testing pull
requests would be difficult.

By draft-07, the purpose of internal '$id' entries is clearly
explained [5]:

  Providing a plain name fragment enables a subschema to be relocated
  within a schema without requiring that JSON Pointer references are
  updated.

We don't need that, because we control all the references.  In the
infrequent event of a subschema move, we can update the consuming
references in the same commit.

The draft-07 $ref docs also explain that $ref targets may be URNs [8]:

  The URI is not a network locator, only an identifier.  A schema need
  not be downloadable from the address if it is a network-addressable
  URL, and implementations SHOULD NOT assume they should perform a
  network operation when they encounter a network-addressable URI.

I haven't found analogous wording for $id, but it's possible that
gojsonschema is being overly agressive with its attempted retrievals.

This commit removes all of our 'id' entries.  The resulting JSON
Schema is valid (regardless of where you host it) and does not
generate the 404s.

Reported by Tom Godkin [9] and William Martin [10].

[1]: https://tools.ietf.org/html/draft-zyp-json-schema-04#section-7.2
[2]: https://tools.ietf.org/html/draft-zyp-json-schema-04#section-6
[3]: https://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-07
[4]: https://tools.ietf.org/html/rfc6901
[5]: https://tools.ietf.org/html/draft-handrews-json-schema-00#section-9.2
[6]: 83a7f6369d
[7]: https://raw.githubusercontent.com/opencontainers/runtime-spec/v1.0.1/schema/config-schema.json
[8]: https://tools.ietf.org/html/draft-handrews-json-schema-00#section-8
[9]: https://github.com/opencontainers/runc/issues/1680
[10]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/L9ME-YRPmmc
      Subject: runtime-spec validation questions
      Date: Thu, 4 Jan 2018 15:47:50 +0000
      Message-ID: <CAMp6QwMTJab5K25=CVy=6OZV6NRX0s-nMLGwqC8ZMpFEp5bF_Q@mail.gmail.com>

Signed-off-by: W. Trevor King <wking@tremily.us>
2018-01-05 11:20:18 -08:00

66 lines
1.9 KiB
JSON

{
"solaris": {
"description": "Solaris platform-specific configurations",
"type": "object",
"properties": {
"milestone": {
"type": "string"
},
"limitpriv": {
"type": "string"
},
"maxShmMemory": {
"type": "string"
},
"cappedCPU": {
"type": "object",
"properties": {
"ncpus": {
"type": "string"
}
}
},
"cappedMemory": {
"type": "object",
"properties": {
"physical": {
"type": "string"
},
"swap": {
"type": "string"
}
}
},
"anet": {
"type": "array",
"items": {
"type": "object",
"properties": {
"linkname": {
"type": "string"
},
"lowerLink": {
"type": "string"
},
"allowedAddress": {
"type": "string"
},
"configureAllowedAddress": {
"type": "string"
},
"defrouter": {
"type": "string"
},
"macAddress": {
"type": "string"
},
"linkProtection": {
"type": "string"
}
}
}
}
}
}
}