Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

json-schema: initial pass at schema and validator #313

Merged
merged 1 commit into from
Mar 10, 2016

Conversation

vbatts
Copy link
Member

@vbatts vbatts commented Jan 19, 2016

Conforming to https://tools.ietf.org/html/draft-zyp-json-schema-03
and http://json-schema.org/latest/json-schema-core.html

This work would ideally pair with separating the current reference source effort #276

  • provide validation tool to validate a configuration file
  • full structures
  • define basic primitives
  • account for all the pointer usage
  • discuss versioned schema-$ver.json

The gist of the config.json being tested with (may change periodically): https://gist.github.com/vbatts/5ac2723c9598875ffb0e

Signed-off-by: Vincent Batts vbatts@hashbangbash.com

@vbatts
Copy link
Member Author

vbatts commented Jan 19, 2016

I am working through making usable definitions like has been done for devices

@philips
Copy link
Contributor

philips commented Jan 19, 2016

looks good but makes my head hurt, oy.

@vbatts vbatts force-pushed the json-schema branch 3 times, most recently from bda07e0 to c5521a5 Compare January 19, 2016 21:26
@vbatts
Copy link
Member Author

vbatts commented Jan 19, 2016

It is something to behold, but it is allowing decently flexible validation.

@vbatts vbatts changed the title json-schema: initial pass at schema and validator [WIP] json-schema: initial pass at schema and validator Jan 19, 2016
@kofalt
Copy link

kofalt commented Jan 19, 2016

Food for thought: I see you're already using schema references ("$ref"); perhaps if you broke this up into several files and combined them at the end? For example, the cpu key could be its own schema, etc.

@vbatts
Copy link
Member Author

vbatts commented Jan 20, 2016

I wondered about that, but didn't see a way to "source" or "include", and
really don't think that just concatenated them together felt smooth

On Tue, Jan 19, 2016 at 6:20 PM, Nathaniel Kofalt notifications@github.com
wrote:

Food for thought: I see you're already using schema references ("$ref");
perhaps if you broke this up into several files and combined them at the
end? For example, the cpu key could be its own schema, etc.


Reply to this email directly or view it on GitHub
#313 (comment).

@wking
Copy link
Contributor

wking commented Jan 20, 2016

On Tue, Jan 19, 2016 at 06:53:53PM -0800, Vincent Batts wrote:

On Tue, Jan 19, 2016 at 6:20 PM, Nathaniel Kofalt:
Food for thought: I see you're already using schema references
("$ref"); perhaps if you broke this up into several files and
combined them at the end? For example, the cpu key could be its
own schema, etc.

I wondered about that, but didn't see a way to "source" or
"include", and really don't think that just concatenated them
together felt smooth

$ref is the way to source/include other content 1.

@vbatts
Copy link
Member Author

vbatts commented Jan 20, 2016

how quaint. let me revisit this.

"type": "array",
"items": {
"oneOf": [ { "$ref": "#/definitions/GID" } ]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need oneOf for arrays. Is there a reason:

"items": {
  "$ref": "/definitions/GID"
}

doesn't work?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is a typed array. Otherwise it would allow ["foo", 1, false]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Thu, Mar 03, 2016 at 12:27:46PM -0800, Vincent Batts wrote:

  •  "items": {
    
  •    "oneOf": [ { "$ref": "#/definitions/GID" } ]
    
  •  }
    

it is a typed array. Otherwise it would allow ["foo", 1, false]

I'm pretty sure that's what the $ref-only phrasing 1 means.

@tetron
Copy link

tetron commented Jan 27, 2016

This is just a drive-by suggestion, but you might want to look at https://github.com/common-workflow-language/schema_salad as a possible alternative to JSON Schema.

@vbatts
Copy link
Member Author

vbatts commented Feb 10, 2016

@tetron thanks, but that seems too niche and less of a standard even than JSON-schema is.

@vbatts
Copy link
Member Author

vbatts commented Mar 3, 2016

rebased again

@vbatts
Copy link
Member Author

vbatts commented Mar 3, 2016

I feel this is about ready for review too.

@wking
Copy link
Contributor

wking commented Mar 3, 2016

On Thu, Mar 03, 2016 at 12:05:54PM -0800, Vincent Batts wrote:

I feel this is about ready for review too.

Any comments on my three still-applicable comments:

  • Unnecessary oneOf 1.
  • Missing indent (and a suggestion to wash through jq) 2.
  • Avoid the generic ‘schema/schema.json’ in favor of
    ‘schema/config.json’, so the schema/*.json filename matches the
    config file it covers 3.

@vbatts
Copy link
Member Author

vbatts commented Mar 3, 2016

Done. PTAL

@wking
Copy link
Contributor

wking commented Mar 3, 2016

On Thu, Mar 03, 2016 at 02:06:57PM -0800, Vincent Batts wrote:

Done. PTAL

Indent and oneOfs look good with 5e656f4. I'd still like
schema/schema.json renamed to schema/config.json [1,2].

{
"$ref": "#/definitions/SyscallArg"
}
]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remaining unnecessary oneOf (see 5e656f4).

}
},
"CapabilityString": {
"description": "File permissions mode (typically an octal value)",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the right description for CapabilityString.

And we can probably use Capability instead of CapabilityString (like we don't use MajorUInt); I don't foresee other singular capability types.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@vbatts
Copy link
Member Author

vbatts commented Mar 9, 2016

rebased and updated

@vbatts vbatts changed the title [WIP] json-schema: initial pass at schema and validator json-schema: initial pass at schema and validator Mar 9, 2016
@crosbymichael crosbymichael added this to the v0.4.0 milestone Mar 9, 2016
@crosbymichael
Copy link
Member

LGTM

@mrunalp
Copy link
Contributor

mrunalp commented Mar 9, 2016

Can we squash or re-order the commits?

@vbatts
Copy link
Member Author

vbatts commented Mar 9, 2016

@mrunalp ah yeah. the commits were just as I made progress. Let me clean them up.

Conforming to https://tools.ietf.org/html/draft-zyp-json-schema-03
and http://json-schema.org/latest/json-schema-core.html

* Utilizes a number of JSON schema features, including 'pattern'
* Defined primitives, like integers, that we'll use
* Split out definitions for primitives and platform-specific
* Provide a Makefile for:
 - "fmt" target for *.json
 - "validate" target for building the validation tool

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
@vbatts
Copy link
Member Author

vbatts commented Mar 9, 2016

@mrunalp fully squashed

@vbatts
Copy link
Member Author

vbatts commented Mar 9, 2016

@philips @mrunalp @vishh @hqhq @tianon PTAL

@mrunalp
Copy link
Contributor

mrunalp commented Mar 10, 2016

LGTM

mrunalp pushed a commit that referenced this pull request Mar 10, 2016
json-schema: initial pass at schema and validator
@mrunalp mrunalp merged commit 9b19e76 into opencontainers:master Mar 10, 2016
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Mar 10, 2016
Also:

* Update the link to Go bindings after 7bf06d5 (source and schema:
  differentiate with examples, 2015-12-18, opencontainers#276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
  Schema and validator for `config.json`, 2016-01-19, opencontainers#313).

It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode).  The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path").  Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Mar 10, 2016
Also:

* Update the link to Go bindings after 7bf06d5 (source and schema:
  differentiate with examples, 2015-12-18, opencontainers#276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
  Schema and validator for `config.json`, 2016-01-19, opencontainers#313).

It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode).  The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path").  Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.

Signed-off-by: W. Trevor King <wking@tremily.us>
@vbatts vbatts deleted the json-schema branch April 12, 2016 03:50
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request May 13, 2016
Validation is partly covered by cdcabde (schema: JSON Schema and
validator for `config.json`, 2016-01-19, opencontainers#313) and subequent JSON
Schema work.  The remainder of these targets are handled by ocitools
[1].

[1]: https://github.com/opencontainers/ocitools

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request May 15, 2016
# digest/hashing target

Most of this has spun off with [1], and I haven't heard of anyone
talking about verifying the on-disk filesystem in a while.  My
personal take is on-disk verification doesn't add much over serialized
verification unless you have a local attacker (or unreliable disk),
and you'll need some careful threat modeling if you want to do
anything productive about the local attacker case.  For some more
on-disk verification discussion, see the thread starting with [2].

# distributable-format target

This spun off with [1].

# lifecycle target

I think this is resolved since 7713efc (Add lifecycle for containers,
2015-10-22, opencontainers#231), which was committed on the same day as the ROADMAP
entry (4859f6d, Add initial roadmap, 2015-10-22, opencontainers#230).

# container-action target

Addressed by 7117ede (Expand on the definition of our ops,
2015-10-13, opencontainers#225), although there has been additional discussion in
a7a366b (Remove exec from required runtime functionalities,
2016-04-19, opencontainers#388) and 0430aaf (Split create and start, 2016-04-01,
opencontainers#384).

# validation and testing targets

Validation is partly covered by cdcabde (schema: JSON Schema and
validator for `config.json`, 2016-01-19, opencontainers#313) and subequent JSON
Schema work.  The remainder of these targets are handled by ocitools
[3].

# printable/compiled-spec target

The bulk of this was addressed by 4ee036f (*: printable documents,
2015-12-09, opencontainers#263).  Any remaining polishing of that workflow seems
like a GitHub-issue thing and not a ROADMAP thing.  And publishing
these to opencontainers.org certainly seems like it's outside the
scope of this repository (although I think that such publishing is a
good idea).

[1]: https://github.com/opencontainers/image-spec
[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ
     Subject: OCI Bundle Digests Summary
     Date: Wed, 14 Oct 2015 17:09:15 +0000
     Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com>
[3]: https://github.com/opencontainers/ocitools

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jun 6, 2016
The JSON Schema requirement dates back to cdcabde (schema: JSON
Schema and validator for `config.json`, 2016-01-19, opencontainers#313), but the
property has been explicitly optional in the Markdown spec since
7ac41c6 (config.md: reformat into a standard style, 2015-06-30).

Signed-off-by: W. Trevor King <wking@tremily.us>
Mashimiao pushed a commit to Mashimiao/specs that referenced this pull request Aug 19, 2016
Also:

* Update the link to Go bindings after 7bf06d5 (source and schema:
  differentiate with examples, 2015-12-18, opencontainers#276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
  Schema and validator for `config.json`, 2016-01-19, opencontainers#313).

It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode).  The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path").  Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.

Signed-off-by: W. Trevor King <wking@tremily.us>
Mashimiao pushed a commit to Mashimiao/specs that referenced this pull request Aug 19, 2016
# digest/hashing target

Most of this has spun off with [1], and I haven't heard of anyone
talking about verifying the on-disk filesystem in a while.  My
personal take is on-disk verification doesn't add much over serialized
verification unless you have a local attacker (or unreliable disk),
and you'll need some careful threat modeling if you want to do
anything productive about the local attacker case.  For some more
on-disk verification discussion, see the thread starting with [2].

# distributable-format target

This spun off with [1].

# lifecycle target

I think this is resolved since 7713efc (Add lifecycle for containers,
2015-10-22, opencontainers#231), which was committed on the same day as the ROADMAP
entry (4859f6d, Add initial roadmap, 2015-10-22, opencontainers#230).

# container-action target

Addressed by 7117ede (Expand on the definition of our ops,
2015-10-13, opencontainers#225), although there has been additional discussion in
a7a366b (Remove exec from required runtime functionalities,
2016-04-19, opencontainers#388) and 0430aaf (Split create and start, 2016-04-01,
opencontainers#384).

# validation and testing targets

Validation is partly covered by cdcabde (schema: JSON Schema and
validator for `config.json`, 2016-01-19, opencontainers#313) and subequent JSON
Schema work.  The remainder of these targets are handled by ocitools
[3].

# printable/compiled-spec target

The bulk of this was addressed by 4ee036f (*: printable documents,
2015-12-09, opencontainers#263).  Any remaining polishing of that workflow seems
like a GitHub-issue thing and not a ROADMAP thing.  And publishing
these to opencontainers.org certainly seems like it's outside the
scope of this repository (although I think that such publishing is a
good idea).

[1]: https://github.com/opencontainers/image-spec
[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ
     Subject: OCI Bundle Digests Summary
     Date: Wed, 14 Oct 2015 17:09:15 +0000
     Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com>
[3]: https://github.com/opencontainers/ocitools

Signed-off-by: W. Trevor King <wking@tremily.us>
Mashimiao pushed a commit to Mashimiao/specs that referenced this pull request Aug 19, 2016
The JSON Schema requirement dates back to cdcabde (schema: JSON
Schema and validator for `config.json`, 2016-01-19, opencontainers#313), but the
property has been explicitly optional in the Markdown spec since
7ac41c6 (config.md: reformat into a standard style, 2015-06-30).

Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants