openconfig
Confusion in usage between Origin and use_models
I am finding it difficult to distinguish the purpose of Origin field in the prefix and use_models in the Subscribe/Get request. Both seems to serve the same purpose of specifying the data model/schema to which data should be fetched from.
Can the gnmi spec team clarify this a bit ?
My use case: The data model has got some change / some data elements were not in proper hierarchy. But fixing this bug, brings in backward compatibility issue in RPC response. I was trying to find out a way where I can let the users to decide when they want to move their infra to accept the new response structure.
Maybe we should start w/ a show of hands as to any implementation that supports use_models and tag this field for deprecation across the respective RPCs.
To my knowledge there is no shipping implementation support and this adds unnecessary complexity.
As far as your use-case, what you are describing is "schema selection" along w/ a specific version however this can have the cascading dependency issue that comes along with it. Users are not going to want this complexity all the way down to per-model versions imo - schema version (or bundles) could be something driven by other means (e.g. config based pinning, packages, etc..)
FWIW, we (google) are not using the use_models field in gNMI. Also, FWIW, the reference gnmi server also does not implement use_models.
As @jsterne says, this isn't used within Nokia and I would support deprecation.
To address the original question -- I'm not sure how these two concepts are related. origin (as described in the spec) is a means to have disjoint trees of data which are disambiguated based on the origin (which could be conceptually thought of as a prefix or a first element to any path). The use_models does not do this, since there is not a 1:1 origin to model correlation -- since multiple models can define one schema-tree that is rooted at /.
That being said, use_models was originally something we added to the specification to be able to handle the case that one wanted to filter augmented nodes from being returned when doing schema-compliance checks. In practice, there is complexity of implementing it in a number of different ways, and I think this has rendered it defunct.
(Some archaeology shows that this was included in the very first gNMI specification draft that I wrote in October 2016. We envisaged that it would be useful in the case described above, and also discussed whether it could be used as a means to allow schema module transitions (i.e., use_models told you to use v0.1.0 but server supports v0.2.0`, servers could translate between v0.1.0 and v0.2.0 -- this also turns out to increase complexity and hasn't been something that we've needed thus far.)
Based on this -- I'm good with deprecating this from the specification.
Thx folks - I've gone ahead and cut PR https://github.com/openconfig/gnmi/pull/230 for the proto IDL side and can initiate a subsequent spec update if we are in agreement