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

[Mitar]

Hi!

Seems relevant for configuration part:

https://datatracker.ietf.org/wg/netmod/documents/

But not sure if it is useful.


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