Re: Getting the JSON schema of commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 9, 2018 at 1:46 AM Erwan Velu <evelu@xxxxxxxxxx> wrote:
>
> - I was wondering if you generated this schema manually or if you
> created a tool to make it ?

I created them manually

> - I also noticed that some structures I see on the cli side are feed on
> the fly and depending on the state of the cluster, so items pop in/out.
> Does your approach cover that ? Are we sure we don't forgot any
> field/value ?

I've never encountered any output that the JSON schema standard can't
handle, even when items pop in/out dynamically at runtime, or when
items have different value types. That doesn't mean it it's easy to
use instances of those schemas, which seems like what you are seeing
with the example below. As for missing field/values, there is that
chance. But that is why it is useful to build intermediate structures
that are used for the sole purpose of representing the output. That
should make it easy "guarantee" the output schema.

> - There is already some implementation which are almost impossible to
> map to a data structure.
>
> Services struct {
>     RbdMirror struct {
>        Daemons struct {
>          Num4467 struct {
>
> That Num4467 structure is random while it should be an array of a known
> type.

I'm a little confused about what you mean by its random, but should be
an array. I'm guessing you mean that that struct corresponds to an
item in a json serialization that changes. The schema handles that,
but in this case, language support for dynamically inspecting the
contents is useful. I'm guessing Go doesn't make that easy / possible?

Perhaps..

>
> There is also examples where the key is a hostname.
>
>      Rgw struct {
>           Daemons struct {
>                Summary  string `json:"summary"`
>                    CephRgw0 struct {
>
> Some tooling like ceph-nano or ceph-ansible workaround this, but I'm
> also facing this.
>
> It would be nice if we can avoid this by having only pre-defined data
> structures. I'm pretty sure if your PR goes on this item you will face a
> show stopper with it as we can't validate this as a schema.
>
> Changing this will break the output and any users. But I do think we'll
> have to make it at some point for the sanity of the output.

I'm having a problem mapping these structs to the corresponding
sources in Ceph. Could you maybe paste some of the JSON serializations
or point to a CLI and how to generate the challenging JSON?

Moving forward, I'm wondering if it would make sense to think about
how to evolve the existing interfaces to provide more stability.
Something like `-f json-stable` that has very strict standards and
then eventually replacing existing `-f json`.



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux