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

[Mitar]

Hi!

> A real, physical device has an intrinsic CPU and RAM, while a virtual
> one must have it configured because it won't use everything that is used
> on the host, I suppose.

Yes. Let's add that to configuration schema then.

> If certain mibs are implemented you can use SNMP to retrieve device
> name, firmware version, device model, total RAM.

Yes, this is what would then be stored in monitoring schema, no?

> SNMP can be also used to change configurations, although I never tried.

Me neither. I always thought that SNMP is read-only, too.

> Ok, that's the sql alchemy model of open stack nova, it is not a JSON
> schema that can be used/shared by different libraries or applications
> written in different languages, using different databases, and so on.

Hm. But JSON is just a serialization format. This models can help us see
what all other people are interested to store about (network) devices.
No? So probably when we define a schema, it does not really matter if it
is JSON or XML or some other serialization. We are working in JSON
because it is the most common format. But our APIs would probably easy
allow that one adds ?format=xml to the URL and get data in XML instead
of JSON, same data, in same schema.

So the question is, why we would not map OpenStack models to JSON?

We could also try to test our schema against OpenStack models and see if
we can express things there.

But this OpenStack models were just an example. I think we both agree
that we should limit things for our case to a smaller set of fields,
things which we are using now, while keeping schema extendable, so that
we can add more things, when any community comes with a new use case and
new fields. So let's define the set of those common fields we know we
need now.

I think the open question from your initial e-mail today is: should we
define one schema where we have a configuration part (you call this
static part, no?) and monitoring part (you call this dynamic part) in
one, or should we have this two things separate.

I think it would be better if we would do one by one, just to avoid
confusion. But if later on implementor of this schema decides to provide
data for both schemas from one API endpoint, why not.

So maybe it is just a question how we are naming things? That instead of
using "network device configuration" we should use "network device
static attributes" and instead of "network device measurements" we
should use "network device dynamic attributes"? I think this is OK, I
don't really have an opinion on this, if we make sure we clearly know
which is which. (And then, for example, memory could be both among
static attributes and dynamic attributes.)

(And of course static attributes could also change through time, when
configuration of a device change. But is different to dynamic attribute.
Uh, confusion. :-) )


Mitar

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