Joshua, Matt
the -o option does not permit uppercase field (in ZoL anyway) :
> zfs list -o RefeR
bad property list: invalid property 'RefeR'
we print the standardized column name in 'zfs_do_list' function :
static char default_fields[] = "name,used,available,referenced,mountpoint";
the name of properties MUST not ever change, else the code that will
use them will break every time.
Your suggestion about parseable values and human readable values are
already reflected (zfs natural way) :
with human readable values :
> zfs list -J -o used | python -m json.tool
{
"cmd": "zfs list -J -o used",
"stdout": [
{
"used": "55K"
},
{
"used": "56,5K"
}
]
}
and with bytes values (-p option) :
> zfs list -pJ -o used | python -m json.tool
{
"cmd": "zfs list -pJ -o used",
"stdout": [
{
"used": "56320"
},
{
"used": "57856"
}
]
}
Concerning the streaming manner (a JSON objects on each line) : if you
do that, you will not have JSON output, but a bloc of text containing
several json object and you will have to parse it with regexp to load
each json object : very complicated.
A well formed JSON object must have root element (as list, dict),
which is easily loaded by code that will use the json output on server
side (python, java,..)
currently, your command example : "zfs list -J -o name,used,refer" print :
# zfs list -J -o name,used,refer | python -m json.tool
{
"cmd": "zfs list -J -o name,used,refer",
"stdout": [
{
"name": "tank_mirror",
"referenced": "19K",
"used": "55K"
},
{
"name": "tank_strip",
"referenced": "19K",
"used": "56,5K"
}
]
}
The -s/S remains valid with -J :
> zfs list -pJ -s used -o used | python -m json.tool
{
"cmd": "zfs list",
"stdout": [
{
"used": "56320"
},
{
"used": "57856"
}
]
}
> zfs list -pJ -S used -o used | python -m json.tool
{
"cmd": "zfs list",
"stdout": [
{
"used": "57856"
},
{
"used": "56320"
}
]
}
-- Francois@Alyseo
2014-11-18 22:55 GMT+01:00 Matthew Ahrens <[email protected]>:
>
>
> On Tue, Nov 18, 2014 at 11:45 AM, Joshua M. Clulow <[email protected]> wrote:
>>
>> On 18 November 2014 10:18, Matthew Ahrens <[email protected]> wrote:
>> > But more importantly, I presume the JSON output will become a stable
>> > interface. Does anyone else have opinions on this?
>>
>> I have some opinions, based on our use of JSON output from a number of
>> tools at Joyent.
>>
>> >>> On Mon, Nov 17, 2014 at 10:22 AM, Francois Billard
>> >>> <[email protected]> wrote:
>> >>>> the good format is (what we have implemented):
>> >>>> {
>> >>>> "NAME" : "rpool",
>> >>>> "USED" : "1.63G",
>> >>>> "REFER" : "404M"
>> >>>> }
>> >>>>
>> >>>> if you want the structure of a specified pool, you must specify it in
>> >>>> the command as :
>> >>>> "zfs list <pool name>"
>>
>> This seems a reasonable structure to me, except that I would make the
>> keys precisely the same string (case included) as what would be
>> specified in the "-o" arguments, rather than using the value that
>> would display in the headings for human readable output.
>
>
> And rather than using the standard property name (e.g. "referenced")? This
> seems less standardized to me, but I guess parroting back the way they
> specified it (e.g. "RefeR") should be workable as well.
>
>
>>
>> I would also
>> suggest that the JSON format should _always_ contain parseable values,
>> not human-readable values -- i.e. "1750199173" rather than "1.63G".
>
>
> I agree.
>
>>
>>
>> I would also suggest that the output should be _streaming_, rather
>> than built in advance and emitted at the end of the run. Using
>> linefeed-delimited JSON, where one JSON object appears on each "line"
>> of output, makes for a more scalable output format. It consumes less
>> memory to assemble for emission and less memory to parse the resultant
>> output with, e.g. JSON.parse() in Javascript.
>
>
> This implies that the sorting flags (-s / -S) would be invalid with -J, and
> the output would be in nondeterministic order.
>
>>
>> To give a concrete example, I would expect the tool to output
>> something like this:
>>
>> # zfs list -J -o name,used,refer
>> {"name":"rpool","used":"1750199173","refer":"423624704"}
>> {"name":"rpool/data","used":"1024","refer":"1024"}
>> {"name":"rpool/data/child","used:"100","refer":"100"}
>>
>> Note that each line is a separate JSON object, which may be emitted
>> immediately and parsed separately. I would also _not_ include any
>> kind of header record, or information about the command that was run,
>> in the output.
>>
>>
>>
>> Cheers.
>>
>> --
>> Joshua M. Clulow
>> UNIX Admin/Developer
>> http://blog.sysmgr.org
>
>
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
