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

[Jernej Kos]

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
> 

-------------- 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/c65bcaf4/attachment.sig>