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

Wed Nov 5 12:18:08 CET 2014

Hello!

But this is exactly the reason I pointed this out at the beginning. You
are again mixing configuration and monitoring/telemetry. I don't see why
you would want a "schema of everything".

There is no problem with having an option in the configuration for
configuring for example memory limits of a LXC container (or any other
device). BUT, it should be clear that this field is for configuring
memory limits, not for reporting currently free memory or something
completely different.

Reusing the same fields for completely different purposes IMO leads to
confusion and I strongly disagree with doing so.

Jernej

On 05. 11. 2014 12:10, Nemesis wrote:
> I try to explain a meta issue that has arised during this round 2. I
> think this issue is very important, at least to me.
> 
> I started to think about it after these questions:
> 
>   * Why would you configure the amount of RAM available on the hardware?
>     This is a property of the configured device and not a configuration
>     option
> 
>   * Ok, but since this is device configuration, how can I configure a
>     specific firmware version? For example in wlan slovenija, we have a
>     field that can specify the exact version that should be installed
>     (or null in case the default version should be used).
> 
> I don't think this JSON should contain only configurations that can be
> changed by a certain type of software.
> 
> I'm not so convinced anymore that calling it "network device
> configuration" it's appropiate.
> 
> We said that we are not trying to do something too broad and that's
> great but we also should not limit too much its scope, immagine this:
> 
> virtual devices, linux containers. Someone might develop a system where
> you can configure the ram, disk space and other things.
> 
> I would like this schema to be able to represent the attributes of
> something that it is reachable via a layer2 or layer3 network, even a
> virtual-device (immagine hardware unit testing), after all the
> discussion I think this schema should have a static part (what we are
> doing right now) and a "dynamic" part that is dedicated to attributes
> that change rapidly over time (what we before called the
> monitoring/telemetry data), pheraphs the two might be used either
> together in a single object or separately, that would also be very useful.
> 
> This schema should have very few required fields, only the very bare
> minimum that is common to all the network objects, this allow the
> different implementations to use only what they need.
> As we said, it should be subdivided in parts that can be extended, and
> implementations should ignore unknown fields.
> 
> But it would be VERY useful to MANY people, not just us doing community
> networks, if this schema included also (with optional attributes)
> information like ram, disk space, cpu and other attributes that are not
> strictly related to the fact that you can change its configuration.
> 
> Immagine data mining, you could use a library that can extract
> information from the network and returns this schema, when you are doing
> data mining it is very useful to know ram, cpu, operating system and
> many other information you cannot strictly change from its configuration.
> 
> I immagine that a software that manages configurations might use only
> the attributes that can be changed, while a software that returns all
> the info of a device might return all the static attributes, a software
> that does monitoring might use only the monitoring data while an HTTP
> API might return everything, including the monitoring data in one single
> response.
> 
> By allowing this flexibility we can lay the ground for something that
> could be used by many people, and if many libraries and softwares that
> deal with networks start using a common schema it will mean that the
> resulting eco system will be richer, which would be very good for everyone.
> 
> Federico
> 
> 
> On 11/03/2014 08:00 PM, Jernej Kos wrote:
>> Hello!
>>
>> There are some problems with this schema, especially regarding radios
>> and VIFs. Radios are not network interfaces and can't have things like
>> IP addresses and MTUs configured. Only VIFs are network interfaces.
>>
>> I have also added inline comments to Google Docs.
>>
>>
>> Jernej
>>
>> On 03. 11. 2014 19:18, Nemesis wrote:
>>> Hey,
>>>
>>> my latest commits:
>>> https://github.com/interop-dev/network-device-schema/compare/937d506ba9...955122b723
>>>
>>> I removed most of the dynamic attributes, we can define that in a
>>> separate step(hopefully soon!).
>>>
>>> I think mitar's suggestion that we should implement it in a way that
>>> parsers ignore unknown arguments is the way to go.
>>>
>>> I copied the JSON example here:
>>> https://docs.google.com/document/d/13uNsnvV4lLjuAf1qXdztXp_kg_uzcfPwjaXGNmzarvE/edit
>>> disable "*print layout*" from "*view > print layout*".
>>>
>>> I hope we can do a few fast iterations there by using the inline
>>> comments. Github and email only for this task is a bit clunky.
>>>
>>> I'm adding a few comments about doubts I have right now.
>>>
>>> I propose to keep discussing "meta" issues here via email,
>>> whilediscussing issues about the schema (eg: why is this info here and
>>> not there, is this argument required? ecc.) there on the document.
>>>
>>> Please participate with some comments so that you can receive further
>>> notifications about replies.
>>>
>>> Federico
>>>
>>> PS: i'm cross posting this to other ninux lists (ninux-devand nodeshot),
>>> for those who haven't followed the entire discussion, hereit is:
>>> https://lists.funkfeuer.at//pipermail/interop-dev/2014-October/000169.html
>>> https://lists.funkfeuer.at//pipermail/interop-dev/2014-November/000192.html
>>>
>>>
>>>
>>> _______________________________________________
>>> Interop-dev mailing list
>>> (spam-protected)
>>> https://lists.funkfeuer.at/mailman/listinfo/interop-dev
>>>
>>
>>
>> _______________________________________________
>> Interop-dev mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/interop-dev
> 
> 
> 
> 
> _______________________________________________
> Interop-dev mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/interop-dev
> 

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