[Interop-dev] Round 2: Network Device Config JSON Schema

[Nemesis]

Hey,

I'm mixing answers to Kotsko and Mitar in one email.

On 11/05/2014 01:15 PM, Jernej Kos wrote:
> Hello!
>
> Sorry if you read my response in such a way, but I think that we are
> repeating things and I don't like to discuss the same things over and
> over again.
>
> I believed that we debated this already on the list and all decided to
> go for a simple configuration schema at the moment. Multiple people
> agreed that we should focus our effort at configuration, not monitoring.
> Is this not true? Even I suggested monitoring first, but then also
> agreed that ok, let's focus on configuration.

I don't feel I have been repeating things over and over, I think there
has been a misunderstanding with the terminology we are using.

> And I still agree with that. Let's focus on describing a simple
> configuration schema first. It is ok to have a field for configuring the
> memory limits, but then it should be clearly stated that this field is
> for configuring a memory limit and not for reporting free memory. Free
> memory should be a different field, part of monitoring data.

Yes absolutely, I didn't mention free memory, (Did I?) I wanted to mean
the total RAM available on the device, from an hardware point of view,
and it should not be a required attribute, so that the applications that
do not deal with this attribute just ignore it.

On 11/05/2014 01:25 PM, Mitar wrote:
> Or maybe it is just misunderstanding in terminology. Is it for you
> "configuration" also what you read from the device as its current
> configuration? Not what you write/use when creating/configuring a device?

Exactly.

I need to read information from an existing network that I do not
control (so i cannot configure myself).

> So, for what process/use cases you are proposing a schema? For an API
> where any device could say "for this node, tell me its current state"?
> And that this state would then consist of static and dynamic attributes?

The first library in which I'm going to implement this schema is netengine:
https://github.com/ninuxorg/netengine

I need to ask netengine to retrieve as much info as possible from a
network device and I need netengine to return the data in this json
format that we are defining.

After implementing it in netengine I would like to implement it in the
nodeshot API, but I would also like nodeshot to be able to read the JSON
and convert it to its own database objects.

Then I might do the same for the OpenWISP project.

> So maybe we have three types of values such a schema can contain:
>
> - configuration with which the device should be configured (this
> interface should have this IP)
> - configuration with which the device is configured (this interface has
> this IP)

This already sounds better, but one question regarding terminology:
should we consider some properties like "total RAM available" as
configuration values? These could either be intrinsic attributes of the
hardware or, in case of virtual devices, configurations.

> - values representing other things about the state of the device (this
> interface had since boot this number of bytes send to)

I have also collected a few links regarding openstack.

As far as I've been told, they have not adopted a defined standard but
developed their own in their API.

http://docs.openstack.org/api/openstack-network/2.0/content/General_API_Information-d1e436.html#request-format
http://developer.openstack.org/api-ref-compute-v2.html

It doesn't look so exciting though.

So to finish this round, my point is: I would like to have a few
attributes like RAM and CPU that in case of real physical devices are
intrinsic attributes, while for virtual devices they might be
configurations.
I would also model attribute (Nanostation M5, Dlink whatever, Dell
Server) that are not always related to configuration - it would be very
very hard to list all the possible models at the moment, so it would be
better if this was just a name.
I would also like to have a vendor/manufacturer, which it's easy to get
from the mac address prefix.

And I think that If, for example, nodewatcher didn't need these
attributes, they can be happily ignored.

Do you think this is bad?

Federico