Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement to pass specific arguments for each xpath(subscription) #1

Open
babukt opened this issue Sep 29, 2017 · 3 comments
Open

Comments

@babukt
Copy link

babukt commented Sep 29, 2017

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

@wisotzky
Copy link
Member

@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
Copy link
Author

babukt commented Sep 30, 2017

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
Copy link
Member

wisotzky commented Sep 30, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants