On Fri, 16 Nov 2018, Erwan Velu wrote:
> Le 13/11/2018 à 16:56, John Spray a écrit :
> > However, what's to stop you just using a map of strings to OSDs in the
> > golang code, and unmarshalling to that? I'd be kind of surprised if
> > the golang JSON parser couldn't handle it.
>
> I can surely make something like Unmarshal in a map[string]json.RawMessage and
> address the structures directly from it.
>
> This is not satisfying for the following reasons :
>
> - this doesn't avoid loading a broken/incomplete input as there is no more
> json validation here
>
> - I don't have any structure data anymore meaning I cannot address items
> directly like in osd.Hostname()
>
> - I have to re-implement accessors for every items I need as I'll have no
> proof it exists or its well formatted.
>
> Considering the size of the json data structure of something like "ceph -s",
> that is a serious extra-load on _every_ tool that needs to read the json while
> we could have share the data structures (like between ceph-nano & my work).
I can't really comment on golang here, but in python this is trivial:
either you can tolerate a missing key (e.g., by substituting a default
value), and use foo.get('field'[, 'default'[), or you can't tolerate it,
and use foo['field'] so that an exception is thrown if it's missing.
Stepping back from the details, though, I think it's important to put this
in perspective. Everyone agrees that having a fully specified (and
documented!) interface (CLI or otherwise) is great for external tools.
The question is what is the cost, either in tracking or dealing with
changes in the external tool, or in specifying the internal format. There
is a maintenance burden on one or both sides either way, and our goal
should be to minimize the total cost.
The goal is to avoid breaking external tools, and we should focus on the
easiest way to accomplish that. IMO trying to specify the internal
dump()ers for all of the internal ceph types is major overkill (and a
rediculous amount of work). Doing nothing is also work for external
tools, just easy work to ignore because we don't know about it until
later when testing (or possibly users) notice.
I liked Noah's initial proposal because it was (1) not much work and (2)
focused on flagging changes before they are introduced, during make check
time, so that the developer can either fix their mistake or make a
conscious decision to change the output schema. As far as I can see it
gets to the root of the problem (unintentional changes to output) with a
lightweight solution.
If there's something even simpler, great. Let's just not sink time into
overengineering a solution the problem based on the brevity of golang...
sage
