Wildcard support in the Path for the method ytypes.GetOrCreateNode(..)

[mbalachandar]

Hi

It looks like, the method ytypes.GetOrCreateNode(..) does not have the support for Wildcard path (*, /.../).

Is there any plan to add the support for wildcard to this method ytypes.GetOrCreateNode(..) same as ytypes.GetNode(..)

Thanks Balachandar

[gcsl]

Can you elaborate on your intended use case? A data path will never have a wildcard as the path would always fully resolved (all keys specified). One could not anticipate what path should be created if a wildcard were passed.

[mbalachandar]

Hi Carl

This is to handle the wildcards mentioned in the GNMI paths - which will come as a request from the Northbound for the subscription.

Thanks Balachandar

[robshakir]

A Subscription can only be to Get nodes though, not create them. As Carl says, we can't clearly anticipate what paths are to be created with a wildcard for creation:

• We could if we only think about non-list elements -- ygot.BuildEmptyTree basically does this.
• We cannot if we think about list elements -- we'd have to anticipate every possible value of the keys.

Either way, this doesn't seem to make a huge amount of sense as a feature request. If you disagree, please can you provide a much more detailed use case. Thanks!

[mbalachandar]

Hi Rob

I agree that we can't create nodes without specific keys in the path, but if there is any API which gives the list of paths with "single-level wildcard" for the multi-level wildcard path in the request that would be helpful to subscribe those particular "single-level wildcard" paths.

For example: Request path: /interfaces/.../state List of paths (single-level wildcard): /interfaces/a//state /interfaces/a//b//state /interfaces/a//b//c//state

here, a,b,c are list nodes in the schema under the interfaces node.

Thanks Balachandar

[mbalachandar]

character * is got removed in the previous post.. mentioning it again by escaping it

For example:

Request path: /interfaces/.../state

List of paths (single-level wildcard): /interfaces/a/*/state /interfaces/a/*/b/*/state /interfaces/a/*/b/*/c/*/state

[mbalachandar]

And, I want to mention another point here, that is at the time of subscribing these kind of paths with wildcards, data node may not exist. In that case, GetNode(..) may not work.

Also the problem is how do I store these path information in my subscription list, and I would like to keep these info as yang Go structure, so that when the data is available I can unmarshal the data with this stored yang Go structure.

Thanks Balachandar

[gcsl]

ygot does not implement a gnmi.Subscribe RPC. You are correct that you could not just use GetNode to capture any future updates added that did not exist at the start of the subscription. However, this also wouldn't work for those that did as there would be no automatic forwarding of updates to those nodes either.

If you would like to see an implementation of a gnmi.Subscribe, there is one in the gnmi collector under http://github.com/openconfig/gnmi, notably subscribe/subscribe.go . The matching of new updates is handled with match/match.go . The implementation here is devoid of ygot as the collector is schema agnostic. The gnmi Notifications could be rendered via ygot and tied to a subscribe implementation similar to the gnmi collector.

On Mon, Sep 30, 2019 at 6:33 PM Balachandar Mani notifications@github.com wrote:

And, I want to mention another point here, that is at the time of subscribing these kind of paths with wildcards, data node may not exist. In that case, GetNode(..) may not work.

Also the problem is how do I store these path information in my subscription list, and I would like to keep these info as yang Go structure, so that when the data is available I can unmarshal the data with this stored yang Go structure.

Thanks Balachandar

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openconfig/ygot/issues/316?email_source=notifications&email_token=AEL4QL4IPAEG7KMMKEUZEG3QMKSHHA5CNFSM4I37UOT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD77TSGQ#issuecomment-536819994, or mute the thread https://github.com/notifications/unsubscribe-auth/AEL4QL4CDWLGFQZSUF3WTQ3QMKSHHANCNFSM4I37UOTQ .

[mbalachandar]

Thanks Carl.. for the inputs.

Regards Balachandar