[Interop-dev] Network Device Configuration JSON Schema

[Nemesis]

Hey,

On 11/02/2014 03:07 PM, Jernej Kos wrote:
> Hello!
>
> Ok, thank you for your clarification.

Welcome

>
>> > Latelly i've been working more on the network device configuration
>> > object, which I simplified by calling it network-device-schema.
> The proposed terminology does not help though. If you are proposing a
> configuration schema then it should be named "Network Device
> Configuration JSON Schema". And there should be another schema named
> "Network Device Monitoring JSON Schema". Using a generic name and mixing
> various things together is IMO not a good thing.

[CUT]

> Also, you propose the name "NetJSON". I personally don't like it because
> it is, similar to "network-device-schema", much too generic. There
> should be a different specification for configuration and a different
> specification for monitoring.

Sorry, I was just abbreviating, I'm not very interested in the name
right now.

I think that after we will have done a few iterations we'll have a
clearer idea.

>> > It's true that the schema contains also dynamic attributes (like
>> > noise and dbm) which change over time, and after you pointed that I
>> > realized it might not have sense to put it there.
> The difference is that the configuration schema is used to bring a
> device into a specific state, while the monitoring schema can be used to
> report on the current state of the device (which in ideal conditions
> should somehow reflect what was configured and would also provide some
> additional "dynamic" data).
>
> But ok, let's focus on configuration. If I understand you correctly, we
> are not aiming for an API but only for a self-contained JSON-based
> serialization format of a node's configuration. This configuration
> should IMO be:
>
>   i) Platform-independent (it should be able to describe any network
>      device configuration). This configuration can later be transformed
>      for example into OpenWrt UCI, but the schema itself should be
>      platform-independent.

Yea, I think it would be very useful if it could describe the common
attributes of any network device: a server, a router, a sensor, ecc.

>   ii) Extensible. As we have learned when redesigning the nodewatcher
>       platform, no one schema can provide everything so it should be
>       easily extensible when later one one needs to add some new
>       attributes.

Definitely.

How do you think is best to achieve this?

For example, GeoJSON has a "properties" key in which you can put
whatever attribute you need.

Any other example?

> From my end, I can provide you with the platform-independent
> configuration schema description that the current nodewatcher
> development version is using:
>
>   https://nodewatcher.readthedocs.org/en/development/node_config.html
>
> An example simplified JSON serialization of this schema for an imaginary
> node would be:
>
>   https://gist.github.com/kostko/9b6eb44f373e17891d65
>
> Note the absence of any platform-specific device identifiers (we are
> using names like "lan0" and "wifi0" to denote interfaces -- these
> identifiers are later resolved depending on the target device). Also
> note that nodewatcher is actually able to validate whether this
> configuration can be instantiated on a concrete target device.

Thank you.

> In case we come up with a good schema, I would be willing to provide an
> implementation of nodewatcher v3 configuration exporter.

I'm looking forward to go ahead.

I'm very open to changes to the schema in order to get it right (or as
close as possible to right).

I would like to get some more feedback from all the other communities
reading this list.

Please let us know.

As a next step I should probably compare the schema on the github repo
with the one at https://gist.github.com/kostko/9b6eb44f373e17891d65 and
make a "synthesis".
Any other good JSON schema around?
**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141102/6420f278/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141102/6420f278/attachment.sig>