On Mon, Nov 14, 2016 at 08:50:54AM -0500, hapr...@stormcloud9.net wrote: > Might help to see an example of what the results look like when using > this schema, however I do have one comment below.
Yes, agreed. I plan to work on making that so. > On 2016/11/14 03:09, Simon Horman wrote: > > Hi Willy, Hi All, > > > > On Thu, Nov 10, 2016 at 04:52:56PM +0100, Willy Tarreau wrote: > >> Hi Simon! > >> > >> On Thu, Nov 10, 2016 at 04:27:15PM +0100, Simon Horman wrote: > >>> My preference is to take things calmly as TBH I am only just getting > >>> started on this and I think the schema could take a little time to get > >>> a consensus on. > >> I totally agree with you. I think the most difficult thing is not to > >> run over a few arrays and dump them but manage to make everyone agree > >> on the schema. And that will take more than a few days I guess. Anyway > >> I'm fine with being proven wrong :-) > > I took a first pass at defining a schema. > > > > * The schema follows what is described on json-schema.org (or at least > > tries to). Is this a suitable approach? > > * The schema only covers "show info" and "show stat" and the fields > > are based on the typed output variants of those commands. > > This leads me to several questions: > > - Is this field selection desirable? It seems to make sense to me > > as presumably the intention of the JSON output is for it to > > be machine readable. > > - Is such an approach appropriate for other show commands? > > - And more generally, which other show commands are desired to > > support output in JSON (in the near term)? > > > > { > > "$schema": "http://json-schema.org/draft-04/schema#", > > "oneOf": [ > > { > > "title": "Info", > > "description": "Info about HAProxy status", > > "type": "array", > > "items": { > > "properties": { > > "title": "Info Item", > > "type": "object", > > "field": { "$ref": "#/definitions/field" }, > > "processNum": { "$ref": "#/definitions/processNum" }, > > "tags": { "$ref": "#/definitions/tags" }, > > "value": { "$ref": "#/definitions/typedValue" } > > }, > > "required": ["field", "processNum", "tags", "value"] > > } > > }, > > { > > "title": "Stat", > > "description": "HAProxy statistics", > > "type": "array", > > "items": { > > "title": "Info Item", > > "type": "object", > > "properties": { > > "objType": { > > "enum": ["F", // Frontend > > "B", // Backend > > "L", // Listener > > "S" // Server > Do we really need to save a few bytes and abbreviate these? We're > already far more chatty than the CSV output as you're outputting field > names (e.g. "proxyId" and "processNum"), so abbreviating the values when > you've got full field names seems rather contrary. And then as you've > demonstrated, this requires defining a "sub-schema" for explaining what > "F", "B", etc, are. Thus requiring anyone parsing the json to have to > keep a mapping of the values (and do the translation) within their code. > Ditto for all the other "enum" types down below. Good point. I'm not sure why that didn't occur to me. But it does seem like a good idea. > > ] > > }, > > "proxyId": { > > "type": "integer", > > "minimum": 0 > > }, > > "id": { > > "description": "Unique identifyier of object within > > proxy", > > "type": "integer", > > "minimum": 0 > > }, > > "field": { "$ref": "#/definitions/field" }, > > "processNum": { "$ref": "#/definitions/processNum" }, > > "tags": { "$ref": "#/definitions/tags" }, > > "typedValue": { "$ref": "#/definitions/typedValue" } > > }, > > "required": ["objType", "proxyId", "id", "field", > > "processNum", > > "tags", "value"] > > } > > } > > ], > > "definitions": { > > "field": { > > "type": "object", > > "pos": { > > "description": "Position of field", > > "type": "integer", > > "minimum": 0 > > }, > > "name": { > > "description": "Name of field", > > "type": "string" > > }, > > "required": ["pos", "name"] > > }, > > "processNum": { > > "description": "Relative process number", > > "type": "integer", > > "minimum": 1 > > }, > > "tags": { > > "type": "object", > > "origin": { > > "description": "Origin value was extracted from", > > "type": "string", > > "enum": ["M", // Metric > > "S", // Status > > "K", // Sorting Key > > "C", // From Configuration > > "P" // From Product > > ] > > }, > > "nature": { > > "description": "Nature of information carried by field", > > "type": "string", > > "enum": ["A", // Age since last event > > "a", // Averaged value > > "C", // Cumulative counter > > "D", // Duration for a status > > "G", // Gague - measure at one instant > > "L", // Limit > > "M", // Maximum > > "m", // Minimum > > "N", // Name > > "O", // Free text output > > "R", // Event rate - measure at one instant > > "T" // Date or time > > ] > > }, > > "scope": { > > "description": "Extent of value", > > "type": "string", > > "enum": ["C", // Cluster > > "P", // Process > > "S", // Service > > "s" // System > > ] > > }, > > "required": ["origin", "nature", "scope" ] > > }, > > "typedValue": { > > "type": "object", > > "oneOf": [ > > { "$ref": "#/definitions/typedValue/definitions/s32Value" }, > > { "$ref": "#/definitions/typedValue/definitions/s64Value" }, > > { "$ref": "#/definitions/typedValue/definitions/u32Value" }, > > { "$ref": "#/definitions/typedValue/definitions/u64Value" }, > > { "$ref": "#/definitions/typedValue/definitions/strValue" } > > ], > > "definitions": { > > "s32Value": { > > "properties": { > > "type": { > > "type": "string", > > "enum": [ "s32" ] > > }, > > "value": { > > "type": "integer", > > "minimum": -2147483648, > > "maximim": 2147483647 > > } > > }, > > "required": ["type", "value"] > > }, > > "s64Value": { > > "properties": { > > "type": { > > "type": "string", > > "enum": [ "s64" ] > > }, > > "value": { > > "type": "integer", > > "minimum": -9223372036854775808, > > "maximim": 9223372036854775807 > > } > > }, > > "required": ["type", "value"] > > }, > > "u32Value": { > > "properties": { > > "type": { > > "type": "string", > > "enum": [ "u32" ] > > }, > > "value": { > > "type": "integer", > > "minimum": 0, > > "maximim": 4294967295 > > } > > }, > > "required": ["type", "value"] > > }, > > "u64Value": { > > "properties": { > > "type": { > > "type": "string", > > "enum": [ "u64" ] > > }, > > "value": { > > "type": "integer", > > "minimum": 0, > > "maximim": 18446744073709551615 > > } > > }, > > "required": ["type", "value"] > > }, > > "strValue": { > > "properties": { > > "type": { > > "type": "string", > > "enum": [ "str" ] > > }, > > "value": { "type": "string" } > > }, > > "required": ["type", "value"] > > } > > } > > } > > } > > } > > > -- Simon Horman si...@horms.nl Horms Solutions BV www.horms.nl Parnassusweg 819, 1082 LZ Amsterdam, Netherlands Tel: +31 (0)20 800 6155 Skype: horms7