Joshua, Matt, Richard,
Ok, we understood the need for reducing the memory footprint... it makes
sense but we also think standard JSON output could be of use for some other
usages or type of users...
So to resume, we propose to code both ;-) and hope it will give more choice
and make everybody happy ?
1) LDJSON
-> we can keep standard JSON with -J and LDJSON with -j
2) -p option by default
3) full name in properties name (was already implemented)
Currently here is the two type of outputs :
with LDJSON :
> zfs list -j tank_mirror/zvol976 tank_mirror/zvol977
{"name":"tank_mirror/zvol976","used":"393216","available":"503808","referenced":"8192","mountpoint":"-"}
{"name":"tank_mirror/zvol977","used":"393216","available":"503808","referenced":"8192","mountpoint":"-"}
{"stderr":""}
and with JSON :
> zfs list -J tank_mirror/zvol976 tank_mirror/zvol977
{"stdout":[{"name":"tank_mirror/zvol976","used":"393216","available":"503808","referenced":"8192","mountpoint":"-"},{"name":"tank_mirror/zvol977","used":"393216","available":"503808","referenced":"8192","mountpoint":"-"}],"stderr":""}
> zfs list -J tank_mirror/zvol976 tank_mirror/zvol977 | python -m json.tool
{
"stderr": "",
"stdout": [
{
"available": "503808",
"mountpoint": "-",
"name": "tank_mirror/zvol976",
"referenced": "8192",
"used": "393216"
},
{
"available": "503808",
"mountpoint": "-",
"name": "tank_mirror/zvol977",
"referenced": "8192",
"used": "393216"
}
]
}
https://github.com/Alyseo/zfs/tree/json has been updated accordingly and we
are moving forward on next commands...
We really would like to agree with the community on each command output (-J
& -j) so output can locked for the near or far futur.
Will appreciate if your guys, can :
- agree on the proposal (-J and -j) and the zfs list output format for both
(json and ldjson)
- tell us how you would like to agree and validate from a community point
of view next command outputs (currently working on" zpool list" including
verbose option : could be on github later today).
Last but not least, will be necessary to think about format
spec/description (like mentioned by Joshua).
Looking forward your feedback and next steps.
Thank you
Regards,
Alyseo Team
2014-11-19 21:50 GMT+01:00 Richard Elling <[email protected]>
:
> On Nov 19, 2014, at 12:17 PM, Joshua M. Clulow <[email protected]> wrote:
>
> On 19 November 2014 11:56, Richard Elling
> <[email protected]> wrote:
>
> On Nov 19, 2014, at 11:42 AM, Yacine Kheddache <
> [email protected]>
> wrote:
>
> I really do not understand why you guys would like to change this (I mean
> between standard output and json output) ?
> Cause today everybody is parsing standard output which mean you are already
> using "-p" arg to display used info in bytes... correct ?
>
>
> The combination of the "-H" and "-p" flags is currently the most
> reliable way to get something parseable out of zfs(1M). But these are
> basically bolt-on flags, added to bend the human-readable output of
> operator tools into something slightly more useful for programmatic
> consumption.
>
> Adding JSON support to the tooling is a great idea, precisely because
> it allows us to specify (and commit to supporting) a well-defined
> output format where programmatic consumption is the primary goal.
> This format should consist of the best machine-readable representation
> of the data that we can provide.
>
> We should be able to publish a specification document that precisely
> describes the parts of the format that we are committing to, so that
> engineers can reliably consume this output in their own code. For
> example, here is a basic specification for an unrelated JSON-based
> format:
>
> http://eng.joyent.com/usage/format_hf4.html
>
> Note that it precisely describes the physical structure of the data
> (Line-delimited JSON), the names of the keys that we are committing to
> provide and the data type and structure of each value.
>
> Going one step further, we could also provide a JSON Schema[1], akin
> to an XML Document Type Definition. The output of zfs(1M) could then
> be validated mechanically against this schema in test suites, to
> ensure that we don't break the committed output format.
>
> [1] http://tools.ietf.org/html/draft-zyp-json-schema-03
>
>
> I find orderly to be much easier to use and can automatically generate
> JSON schema.
> http://orderly-json.org/
>
>
>
> So why you can not simply use "-p" with "-J" instead of creating (which is
> my main point here in fact) a diff between standard output
> and json output ? In addition is also mean with your suggestion that when
> using "-J" no one can use the human readable output anymore if they want...
>
> Correct, the JSON is consumed by automation, not humans
>
>
> Right. The JSON output format should be rigidly defined, as much as
> possible. The combination of flags used to produce the JSON data
> should not have to be a consideration when consuming it. This enables
> engineers to consume it reliably in software that needs to run across
> all of the platforms that support OpenZFS, well into the future.
>
>
> +1
> -- richard
>
>
>
> Cheers.
>
> --
> Joshua M. Clulow
> UNIX Admin/Developer
> http://blog.sysmgr.org
>
>
>
> _______________________________________________
> developer mailing list
> [email protected]
> http://lists.open-zfs.org/mailman/listinfo/developer
>
>
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
