On Mon, Nov 14, 2016 at 08:50:54AM -0500, [email protected] 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 [email protected]
Horms Solutions BV www.horms.nl
Parnassusweg 819, 1082 LZ Amsterdam, Netherlands
Tel: +31 (0)20 800 6155 Skype: horms7
