<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Ralf,<br>
<br>
On 11/10/2014 12:02 PM, Ralf Schlatterbeck wrote:<br>
</div>
<blockquote cite="mid:20141110110225.GB31530@runtux.com" type="cite">
<pre wrap="">Just joining the discussion now, thanks Federico for starting this.
I'm referring to the google docs document, not the github version
(which I haven't compared, it might be the same).</pre>
</blockquote>
<br>
Thank you for joining the discussion.<br>
<br>
<blockquote cite="mid:20141110110225.GB31530@runtux.com" type="cite">
<pre wrap="">Several points from my side:
- My use-cases come mostly from a node database perspective</pre>
</blockquote>
<br>
I see your point.<br>
<br>
I think i'm not wrong if I say that we discussed that this schema
should not be concerned too much about the different node-db
implementations, it should be concerned mostly about what is the
lowest common denominator of the attributes needed to represent a
network device: its configuration, its hardware attributes, its
software and return this information as a JSON schema that is shared
by our libraries and applications.<br>
<br>
All the attributes should be optional and consumers should ignore
all unknown attributes.<br>
<br>
<blockquote cite="mid:20141110110225.GB31530@runtux.com" type="cite">
<pre wrap="">- We currently distinguish a device from a device type.
The latter contains all attributes that are common to a device
made by a certain manufacturer, e.g. Linksys WRT54GL.
We have the following attributes there some of which we may
want to add to our common schema:
- name (e.g. Linksys WRT54GL)
- model_no (e.g. WRT54GL)
- revision: Devices often come in several revisions that may
*completely* change the hardware in the device. The model number
usually doesn't change. An example for complete hardware change with
revision number is the ASUS WL500G Premium, see
<a class="moz-txt-link-freetext" href="http://wiki.openwrt.org/toh/asus/wl500gp">http://wiki.openwrt.org/toh/asus/wl500gp</a> (sorry for an example with
a very old device, I happen to have several of these)
- The manufacturer is a company, we model companies (with lots of
optional attributes like address and phone number) as a separate
entity and link it to the device type.
The device would get all the attributes that are *not* common
to all devices-types made by a manufacturer. This includes
(static) configuration like IP addresses.
I *think* the current hardware section captures some of
the attributes above, I'd add revision and flash memory.
Our use-case for capturing the hardware attributes separately
is that most users really don't know much about their device,
so they can simply chose something pre-configured.
I would also keep the *typical* RAM, Flash, and CPU Frequency
configuration for the device there. If we later model more complex
devices where some of these aspects can be changed we could override
this in another section that only applies to the concrete device.
I've added my comments to the hardware section.</pre>
</blockquote>
<br>
To recap:<br>
<ul>
<li>model_revision</li>
<li>CPU_frequency</li>
<li>Flash_memory<br>
</li>
</ul>
<br>
<blockquote cite="mid:20141110110225.GB31530@runtux.com" type="cite">
<pre wrap="">- We have an optional "description" attribute for almost anything, this
is very useful for comments and a more verbose description. Since we
said that attributes would be optional, I'd add that in.</pre>
</blockquote>
<br>
We also have it in nodeshot, although it is a node-db related
information and not strictly something that is stored in the device
configuration.<br>
<br>
I'm ok to add it if needed.<br>
<br>
<blockquote cite="mid:20141110110225.GB31530@runtux.com" type="cite">
<pre wrap="">- Regarding 'maintainer' in the general section: We have quite a complex
model for persons and legal entities, and several attributes for
ownership and maintainership of a device. In fact we store this info
not with the device but with the node (to which the device belongs).
Although this decision has spawned some discussions.
So I'd vote for a separate section for modelling ownership and not put
this into an attribute of the device. Note that Funkfeuer thinks that
personal information should be visible only to members of the network,
not generally in an API (privacy issue).</pre>
</blockquote>
<br>
Regarding this attribute, it's contained in the SNMP responses of
the default snmp agent on OpenWRT, so I was just mirroring what is
there.<br>
<br>
I think the attribue should be there even if some communities do not
use it (for whatever reason).<br>
<br>
A potential openwrt-agent that returns the JSON might be configured
to not show certain attributes like this one.<br>
<br>
<blockquote cite="mid:20141110110225.GB31530@runtux.com" type="cite">
<pre wrap="">- Since we currently aim at wireless devices I'd vote for 'firmware' and
'firmware_version' instead of os. Note that the os type and -version
might be attributes of a separate firmware datatype to be modelled
later.
</pre>
</blockquote>
<br>
In ninux we are not interested only in wireless devices.<br>
<br>
Infact I'm working both in my daily job and with ninux on servers,
linux containers (I know in confine they're using virtual boxes on
research devices that can be used by community networkers too to
host their private services) and sensors (lots of fablabs interested
in our network and I guess yours too).<br>
<br>
A possible solution would be to have two different terms, one for os
and one for firmware.<br>
<br>
Since it's common to name a firmware <my cool firmware name>OS
I thought "os" would be enough. Managing only one attribute would be
also easier from the point of view of a programmer who is
implementing something that deals with different device types.<br>
<br>
I hope we can find an agreement on these last attributes soon so
I'll proceed with iteration round 3.<br>
<br>
It's also useful to recap all this discussion in a short structured
summary in the README.<br>
<br>
Federico<br>
</body>
</html>