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

[Mitar]

Hi!

> 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.

:-)

Yes, that's probably the main point of this endeavor. To consolidate the
terminology among networks. I am glad to see the progress. :-)

> and it should not be a required attribute, so that the applications that
> do not deal with this attribute just ignore it.

Just related comment: I think we should not require anything. For the
sake of extensibility. We just define that if you want to put something
in, you should put it in this and this way, but if you do not know how
to generate something, you do not have to. The consumer has to know how
to handle missing fields and extra fields, no?

Or, we should create a really small set of required fields (like UUID of
a device as the only required field I would say). Do you think there
should be any other required fields?

> 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.

OK, this is then 2. and 3. point from:

1.) configuration with which the device should be configured
2.) configuration with which the device is configured
3.) values representing other things about the state of the device

In nodewatcher we have also 1., which is for us "configuration" schema.
And 2. and 3. together is for us "monitoring" schema. So great, we
understand each other now. Let's discuss what we call "monitoring" schema.

> 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.

I think both. So in above terminology, it would be:

1.) total RAM to configure in a virtual device (if applicable)
2.) total RAM reported on a device (can be seen as something configured
for a virtual device, or state of a device hardware)
3.) free RAM reported by a device

So for you, if I understand correctly, this is OK. So if we are working
on 2. and 3. schema, you get total RAM as part of 2. and if you know
that this is a virtual device, you get information about how much it was
configured with. (But you cannot check if this configuration is the one
you would expect, what we additionally do in nodewatcher by comparing it
with 1.)

> 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 agree. We collect this information already as well.

> 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.

Yes, we could define a type and have it as best as possible. OpenWrt has
something which gives model string, not the most precise, but it works
most of the time well.

We have this under "hardware":

https://github.com/interop-dev/network-device-schema/issues/1

"hardware":{
  "board":"tl-wr741nd-v4",
  "model":"TP-Link TL-WR740N\/ND v4"
},

> I would also like to have a vendor/manufacturer, which it's easy to get
> from the mac address prefix.

I think this should go to the consumer. I would not like to store the
MAC prefix table on the nodes to have to support this.

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

Yes. I would say all should be like that, as I wrote above. You ignore
if you don't care something, and nothing is required. The only thing we
have to coordinate is that if you need something, you should coordinate
with others before, so that in the future we don't have a conflict of
what a field means.


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m