Hi Willy,
On Mon, Nov 14, 2016 at 11:11:12AM +0100, Willy Tarreau wrote:
> Hi Simon,
>
> On Mon, Nov 14, 2016 at 09:09:21AM +0100, Simon Horman wrote:
> > 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?
>
> I'll let others respond as I have no idea since I never need nor use JSON :-)
>
> > * 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.
>
> Yes in my opinion it's the goal. And these are the two only parts that
> were converted to typed output for this reason.
>
> > - Is such an approach appropriate for other show commands?
>
> At the moment I don't think so because the other ones are more related
> to state management than statistics.
Nice, I'm quite happy to limit the scope of this work to info and stat
at least for now.
> > - And more generally, which other show commands are desired to
> > support output in JSON (in the near term)?
>
> I can't think of any right now.
>
> However I have a question below :
>
> > "id": {
> > "description": "Unique identifyier of object within
> > proxy",
> > "type": "integer",
> > "minimum": 0
> > },
>
> Sometimes a description like above appears in your example, is it just
> for a few fields or do you intend to describe all of them ? I'm asking
> because we don't have such descriptions right now, and while I won't
> deny that forcing contributors to add one when adding new stats could be
> reasonable (it's like doc), I fear that it would significantly inflate
> the output.
My understanding is that the description is part of the schema but would
not be included in a JSON instance. Or on other words, would not
be included in the output of a show command.
My intention was to add descriptions for all fields. But in many case
the field name seemed to be sufficiently descriptive or at least I couldn't
think of a better description. And in such cases I omitted the description
to avoid being repetitive.
I do not feel strongly about the descriptions. I'm happy to remove some or
all of them if they are deemed unnecessary or otherwise undesirable; to add
them to every field for consistency; or something in between.
> Also, do you have an idea about the verbosity of the dump here ? For
> example let's say you have 100 listeners with 4 servers each (which is
> an average sized config). I'm just looking for a rought order of magnitude,
> ie closer to 10-100k or to 1-10M. The typed output is already quite heavy
> for large configs so it should not be a big deal, but it's something we
> have to keep in mind.
I don't think the type, description, etc... should be included in such
output as they can be supplied by the schema out-of-band. But the field
name and values along with syntactic elements (brackets, quotes, etc...) do
need to be included. I can try and come up with an estimate if it is
important but my guess is the result would be several times the size of the
typed output (mainly owing to the size of the field names in the output).
> Oh BTW just to let you know, I'm working on a painful bug and possibly a
> small regression which will force me to revert some recent fixes, so you
> may still have a bit of time left :-)
Good luck with the bug and thanks for letting me know.
