openconfig / gnmi

gRPC Network Management Interface
Apache License 2.0
459 stars 196 forks source link

Clarification needed for adding namespace in path #153

Closed ngniksnikhil closed 11 months ago

ngniksnikhil commented 11 months ago

From the documentation given, I was unable to find which should be used as a namespace to distinguish the path. module-name or prefix or any of them.

For a openconfig-intefaces.yang defined as below ` module openconfig-interfaces {

yang-version "1";

// namespace namespace "http://openconfig.net/yang/interfaces";

prefix "oc-if";

`

What is the correct way to create a path for GNMI get request option#1 or 2 or both?

/oc-if:interfaces/oc-if:interface/ /openconfig-interfaces:interfaces/openconfig-interfaces:interface/

gcsl commented 11 months ago

Neither. While YANG has module prefixes to disambiguate models when there are overlaps between them, OpenConfig models in YANG will never rely on the module prefix to provide unique path names. As gNMI supports both OpenConfig and non-OpenConfig schema data where disambiguation might be required, there is a field, 'origin' that is specified to be 'openconfig' for OpenConfig modeled data (the unset value, '', is equivalent as gNMI defaults to OpenConfig) or can be overridden with a vendor specified alternative origin. A given non-OpenConfig origin follows rules subject to a given implementation which may or may not follow the OpenConfig convention.

For OpenConfig paths module name and prefix are elided in gNMI.

/interfaces/interface

ngniksnikhil commented 11 months ago

I think you are talking about 'origin' which can be shown in the Response. I wanted to know how should I form the request?

e.g. If I use gnmic client, how should I specify path in that request?

  1. gnmic get -a ip:port -p password -u username --skip-verify --path /openconfig-interfaces:interfaces/openconfig-interfaces:interface -e json
  2. gnmic get -a ip:port -p password -u username --skip-verify --path /oc-if:interfaces/oc-if:interface -e json

which one is the correct format?

gcsl commented 11 months ago

Origin is in both the request and response. They will always match. The path should be --path /interfaces/interface because this is an openconfig origin model.

hellt commented 11 months ago

@ngniksnikhil in gnmic origin can be set in the path string like this: --path openconfig:/interfaces/interface...

ashumundra commented 11 months ago

Hi Carl,

What about non-openconfig models? Say vendor proprietary YANG models, both prefix and full module-name are good to form the subscription path?

Regards Ashutosh

gcsl commented 11 months ago

gNMI affords the ability to deliver non-OpenConfig data using an alternate origin. The OpenConfig group does not make stipulations for implementations for alternate models. gNMI could be used even in cases where no YANG models exist, such as for a command-line-interface for mixed-schema configurations if certain options are not modeled but accessible via a CLI. The goal of OpenConfig is to standardize the modeling of common configurations and telemetry. If a given proprietary model likewise had implicit guarantees that name collisions were not possible even when ignoring module name and prefix, it could take advantage of the same terseness in gNMI that OpenConfig models do, or it may not and require the prefix, or it may support both options. That would be up to the implementor.

ashumundra commented 11 months ago

Thanks, understood and makes sense.

On Thu, Sep 21, 2023 at 6:54 AM Carl Lebsack @.***> wrote:

gNMI affords the ability to deliver non-OpenConfig data using an alternate origin. The OpenConfig group does not make stipulations for implementations for alternate models. gNMI could be used even in cases where no YANG models exist, such as for a command-line-interface for mixed-schema configurations if certain options are not modeled but accessible via a CLI. The goal of OpenConfig is to standardize the modeling of common configurations and telemetry. If a given proprietary model likewise had implicit guarantees that name collisions were not possible even when ignoring module name and prefix, it could take advantage of the same terseness in gNMI that OpenConfig models do, or it may not and require the prefix, or it may support both options. That would be up to the implementor.

— Reply to this email directly, view it on GitHub https://github.com/openconfig/gnmi/issues/153#issuecomment-1728627472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWIPKFXA3WYOOCJKXPGTM3X3OJOFANCNFSM6AAAAAA47Z3ONA . You are receiving this because you commented.Message ID: @.***>

ngniksnikhil commented 11 months ago

Thank you guys.