[Interop-dev] Network Device JSON Schema

Jernej Kos (spam-protected)
Mon Oct 27 11:14:17 CET 2014


Wait, are you talking also about a configuration schema? I thought that
this discussion is only about the telemetry/monitoring schema that is
used for data reporting from the devices themselves, not something that
requires a running node database etc.?

For configuration schema, nodewatcher v3 also has a completely
different, and again modular, approach. But as Federico said, let's
start small and not try to define everything at once.


On 27. 10. 2014 10:55, Ralf Schlatterbeck wrote:
> Jernej, Federico, concerning the representation of objects:
> I'd like to first define what attributes we need and later how to call
> an object. If such a thing consists of several objects (as in Jernej's
> implementation) is probably secondary.
> Note that Christian Tanzer and me have started to write up what we know
> about other Node database implementations, the attributes used and the
> names for them. This could be a start to define a common API.
> This is on github at https://github.com/Common-Node-DB/paper
> We've tried to summarize the schemas from what we found on the net and
> what we found out by asking people.  This is in background.txt
> Note that we were unable (too dumb :-) to understand the nodewatcher
> schema even after asking. Jernej: Maybe you want to take a look at what
> there already is (see background.txt in the repo above) and contribute a
> section on nodewatcher? This would also be an opportunity to better
> explain your (unique) approach to modularisation -- as this discussion
> shows -- and my experience with trying to understand the nodewatcher
> schema -- this is not immediately obvious. At least not to me.
> Note that I could give you github access to the Common-Node-DB/paper/
> repo -- or you fork and send merge requests. My proposal would be to
> document what there is to later define what a common api should look
> like. The idea is to write a paper -- preferrably with all of you as
> authors -- that defines a minimum common api.
> That said: We *have* started to write a proposal on a common api in
> common-api.txt but this is of course still subject to change.
> I think the two common artefacts that a common api must support are what
> we call a "Node" and a "Device":
> - A Node is at some (geo-) location and several devices may be installed
>   at a Node. Typically a Node has an owner and maybe some additional
>   people managing it.
> - A device is something that communicates via the network. It typically
>   has network interfaces which in turn are associated with IP addresses.
>   It can also have wireless parameters if it contains a radio.
> We also want to discuss which attributes are configuration parameters
> and which are dynamic (measured) data. From the schema at
> https://github.com/interop-dev/network-device-schema/issues/1
> I understand that much of what nodewatcher-agent displays is dynamic
> data. In the current API proposal (above) we're mostly dealing with
> configuration data. Note that we're trying to integrate both, dynamic
> and static data, into a user interface that we call the "dashboard".
> We have an implementation of our API (the 'internal' api, not the
> proposed common api) up at https://ff-nodedb.funkfeuer.at -- I'm working
> on this for a presentation on Wed/Thu this week so it may not be fully
> functional during the next days. In particular the self-documenting
> object model (where you can click on each of the classes and get a
> description of the attributes) is currently not working. You can find an
> overview graphics of the object model on the starting page of the github
> project at https://github.com/CNDB/CNDB/
> You can explore the api at https://ff-nodedb.funkfeuer.at/api
> Note that this database is anonymized, so you'll find only "funkfeuer"
> persons in there.
> Ralf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141027/9466574d/attachment.sig>

More information about the Interop-dev mailing list