Definition of componentSpec in the component JSON Schema expresses no constraints

[Relequestual]

The first definition defined in the component schema looks to be incorrect.
Currently, the componentSpec defines no JSON Schema keywords, and so emposes no constrains as to what it should contain.

I suspect this is an oversight, and you just need to nest the current object inside properties.

This does suggest that you might not be testing your schemas to make sure they do what you want. It might be beneficial to do this to avoid this issue in the future.

You can use the same approach as per the official JSON Schema test suite, and probably borrow existing testing code in your language of choice as a result.

spec/schema/component.schema.json

Lines 45 to 87 in 21d4609

	"definitions": {
	"componentSpec": {
	"parameters":{
	"type": "array",
	"description": "The component's configuration options.",
	"items": {
	"$ref": "#/definitions/componentParameter"
	}
	},
	"workloadType":{
	"type": "string",
	"description": "A succinct, semantically meaningful descriptor of the component's runtime profile.",
	"enum": ["Server", "SingletonServer", "Worker", "SingletonWorker", "Task", "SingletonTask"]
	},
	"osType":{
	"type": "string",
	"default": "linux",
	"description": "The OS required to host (all of) the component's containers (since containers share a kernel with the underlying host).",
	"enum": ["linux", "windows"]
	},
	"arch": {
	"type": "string",
	"default": "amd64",
	"description": "The CPU architecture required to host (all of) the component's containers (since containers share physical hardware with the underlying host).",
	"enum": ["i386", "amd64", "arm", "arm64"]
	},
	"containers":{
	"type": "array",
	"description": "The OCI container(s) that implement the component.",
	"items": {
	"$ref": "#/definitions/container"
	}
	},
	"workloadSettings": {
	"type": "array",
	"description": "Declaration of non-container settings that should be passed to the workload runtime.",
	"items": {
	"$ref": "#/definitions/workloadSetting"
	}
	},
	"required": ["workloadType"],
	"additionalProperties": false
	},

[z0r0]

In also working on this with the reporter, I suspect that the componentSpec should also have a "type" of "object" associated with it.

[resouer]

Thanks for reporting! My 2c is it may be way easier to generate from KubeVela's go types directly - it's where the constraints are enforced indeed.

[z0r0]

Are these schemas even being used directly anymore then if they're being re-implemented within kubevela?

[Relequestual]

Thanks for reporting! My 2c is it may be way easier to generate from KubeVela's go types directly - it's where the constraints are enforced indeed.

Great. If you can generate them from a source of truth, that's always preferable. It's usually really hard to do that though, and tooling isn't there. You'd have to build your own solution. Yack shaving for sure.

[resouer]

@Relequestual Yeah, we already explored it a bit actually. For example, vela now auto-generating json schema for the schematic section of OAM entities, and then build UI forms with it. This is early stage but IMO a promising direction as the customer's dashboard are fully "pluggable", new forms become immediately ready to use whenever a new component/trait is installed in the platform.

@z0r0 KubeVela is actually the source-of-truth for the whole thing, a possible action is we could officially export the schemas from vela api to the spec repo in next release.