Might help to see an example of what the results look like when using
this schema, however I do have one comment below.
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.
> ]
> },
> "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"]
> }
> }
> }
> }
> }
>
