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

Mitar (spam-protected)
Wed Nov 5 13:25:08 CET 2014


Hi!

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?

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?

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)
- values representing other things about the state of the device (this
interface had since boot this number of bytes send to)


Mitar

> 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.
> 
> 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.
> 
> 
> Jernej
> 
> 
> On 05. 11. 2014 12:39, Nemesis wrote:
>> Hey guys, I took one hour to write something and it took you minutes to
>> answer. I find your answers arrogant and disrespectful. I would like the
>> discussion to go back to normal terms and I'd like us to understand each
>> other needs.
>>
>> I'll continue below.
>>
>> On 11/05/2014 12:21 PM, Mitar wrote:
>>> Hi!
>>>
>>>> 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.
>>> Are we then the right group of people to define something as general as
>>> this? Wouldn't then be better to look in how OpenStack if configuring
>>> their devices and use that?
>>
>> We might very well do that, I know a friend who is now contributing
>> actively and I can request his help to know more about what kind of
>> format do they use and if there is anything better.
>>
>>> Why then try to define anything specific for
>>> mesh/wireless nodes?
>>
>> Because that's our specific use case, no?
>>
>>>> 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),
>>> Yes, we can try to define a schema which can be for anything: WiFi
>>> enabled watches, Internet of Things sensors, smart kitchen appliances.
>>> All that can be connected to the network this days.
>>>
>>> So let's define a schema which will contain a field for configuring the
>>> temperature of my networked microwave oven.
>>
>> Do not exagerate my words. I wrote that it should be not too broad.
>>
>>> Or maybe we should limit to thing we do and use now?
>>
>> Yes we should, and something I need right now is a schema that is able
>> to tell me information like cpu, ram, and so on.
>>
>>>
>>>> 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.
>>> I think we are getting again into same direction why we failed to define
>>> such a common schema so many times until now. We tried to do too much. I
>>> would say that just defining few common types would be an achievement.
>>> Do we use an UUID to uniquely represent a network device? What other
>>> common field types can we think about. Let's do that first.
>>
>> I was not implying that we should define everything, just that we should
>> make it possible to have a few attributes that do not necessary mean
>> that they can be changed by some software.
>>
>>>
>>>> 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.
>>> Yes yes. But then, why don't we maybe just don't try to reinvent the
>>> wheel hundreds of researches of Internet of things are doing at the
>>> moment? I think if you want so generic thing, then we should move this
>>> discussion to schema.org discussion, or some other relevant mailing
>>> list. Because then it is bigger than us.
>>
>> That would be awsome, but i wouldn't do that before we do some first
>> rounds here in order to get what we need first. That process might be
>> done in a separate step, why do everything in one step?
>>
>>> There are so many people already working on this. Even SNMP itself and
>>> schemas used in SNMP are an example.
>>
>> Indeed the information represented here is something I'm also extracting
>> via SNMP.
>>
>> But is there a known and widely adopted JSON schema already? If yes
>> please provide information.
>>
>>>
>>>> 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.
>>> Yes, let's define a non-industry standard for all this while there are
>>> probably industry standards already.
>>
>> "Probably"? I have been looking for this for a while.
>>
>> I don't want to reinvent the wheel.
>>
>> Is there a JSON schema that is already being used by few softwares that
>> deal with networks?
>>
>> I thought that every software implemented its own JSON API, XML or
>> whatever, but I might be wrong. It would be much better if you provided
>> some links or some background info.
>>
>>> This will be definitely be helpful.
>>
>> This tone used in these situations is surely not helpful.
>>
>>
>> _______________________________________________
>> 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
> 

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




More information about the Interop-dev mailing list