Enhancement to pass specific arguments for each xpath(subscription)

[babukt]

Current pygnmi supports common parameters for all xpaths provided. Please enhance to pass specific arguments for each xpath(subscription)

[wisotzky]

@babukt
Are you just interested in the sample_interval or other attributes as well. To add individual per path control could be considered, but I would like to understand what CLI syntax you would prefer to pass these attributes. This is not really straight forward as I see it. The other option would be, to put the subscription attributes in a YAML file...

Could you also please share how you would like the tool to be used in your environment? It is designed for learning GNMI and testing only - so I've considered it to be okay to use always the same set of attributes per path.

[babukt]

I'm interested in all attributes available under message "message SubscriptionList" and "message Subscription". More importantly, use_models under SubscriptionList and sample_interval & mode under Subscription.
Input parameters can be passed in either YAML or JSON files.

e.g., I want to send a request with multiple subscriptions each with different mode (SAMPLE or ON_CHANGE) and/or with different sample intervals for an individual path.

Have few queries on the usage of this app.

1. As per gnmi.proto Error field is deprecated. Does this app handle errored responses based GRPC error codes?
   https://github.com/openconfig/gnmi/blob/e4ad4a69388b53a15ce6cb08bdafb2dfd05fbc4d/proto/gnmi/gnmi.proto#L165

2. In case of POLL mode, I want to send SubscribeRequest RPC by setting poll on an existing subscription channel . Basically, poll option should be handled in this

3. Do we have any standard parsers to read responses coming in PathElem format ?

   For example to read multiple update messages in a streamed environment
   Ex: notification {
    update {
      path {
        origin: "openconfig"
        elem {
          name: "bgp"
        }
      }
      val {
        json_ietf_val: "{"global": {"config": {"as": 12}}}"
      }
    }
   }

[wisotzky]

You are correct, I am missing some attributes including all of those have been defined in gnmi v0.4 version of the specification. The main reason is, that I do NOT have a TLM/gNMI server supporting version 0.4 to develop and test against. Having this said, this is expected as version 0.4 is less than 2 months old. In Nokia we will support version 0.4 from SR OS 15.1 which will be released in November 2017 timeframe. I will look into supporting those additional attributes by this time.

The same is true about the Error field, which has be deprecated in version 0.4. So yes, I will change the behavior as soon I've got my hands on a node supporting this version.

About subscription mode, Nokia SR OS 15.0 only supports STREAM today. Other types of subscription (POLL, ONCE) might be supported from SR OS 16.0. Having this said, to update the tool I depend on having a TLM server supporting those options to test against.

About "use_models" - it is the same story here. It has been introduced in gnmi v0.4 so depend on having a server supporting this for development and testing. Also I strong believe that this option is insufficient. Reason is, that you might subscribe to leafs from different data models within the same request. Other protocols/APIs using YANG such as NETCONF use XML namespaces (per path element) to identify the elements better.

About parsing results, I might build another tool which is doing this in the future. Currently I am just using a built-in gRPC method, which is dumping the complete content of the SubscribeResponse message without parsing. The reason is, that the OpenConfig/gNMI specification owners (mainly google) publishing continuously new versions of the spec which still have deficits but breaking compatibility with previous versions to a certain extend. So I would love to see something like version 1.0 is released and a promise from OpenConfig guys that this one is stable. So in conclusion I don't have issues that they extend the specification with new attributes - as long they don't break compatibility. I would avoid to spend time building a tool which can support ALL versions of gNMI - as there are not many vendors out there currently supporting it.

About your original request of making per xpath attributes configurable (sample_interval, ...), I will consider this for the next update. But potentially this only makes sense for a tool, which is really dealing with the results not just displaying them. So would be good to understand, how you would intend to use it. In fact, I can see there is market interest for a versatile, scalable TLM collector doing some sort of normalization, binning, aggregation, ... But for me, this would be a commercial product as this would require lots of efforts to design, evolve and maintain.

Just for curiosity, would be good to understand what gNMI servers you are testing against.