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

Remove ellipsis (...) wildcarding #163

Open
ccole-juniper opened this issue Jan 4, 2024 · 3 comments
Open

Remove ellipsis (...) wildcarding #163

ccole-juniper opened this issue Jan 4, 2024 · 3 comments

Comments

@ccole-juniper
Copy link

Proposal: Remove ellipsis (...) wildcarding from the spec.

If there are any users of the feature I'd be interested in the use cases.

If the sense of the community is in agreement I'll make a pull request.

Context from @gcsl (1 Jun 2022):

"In our collection infrastructure we support gnmi path '*' wildcards on the
client side. Generally on the device side, we subscribe to top-level models or
an intermediate branch. The wildcard would be necessary if we intended to
filter a given model to a specific set of leaves only. I am not aware of any
'...' wildcard use anywhere. I had argued it was inefficient to implement and
offered limited utility. I had proposed removing it from the spec on a few
occasions and I think this would be one of the useful deletions prior to a gnmi
1.0 declaration."

@abtuteja
Copy link

abtuteja commented Jan 5, 2024

Hi, with ellipsis I like the ability to probe multiple values/leafs which are defined at different hierarchies. For instance, to get all the different MTUs values on an interface, I can do a GET on /interfaces/interface[name=Ethernet1]/.../mtu and it can give all the MTUs defined in OpenConfig models:

interfaces/interface/state/mtu
interfaces/interface/routed-vlan/ipv4/config/mtu
interfaces/interface/routed-vlan/ipv4/state/mtu
interfaces/interface/routed-vlan/ipv6/config/mtu
interfaces/interface/routed-vlan/ipv6/state/mtu
interfaces/interface/subinterfaces/subinterface/ipv4/config/mtu
interfaces/interface/subinterfaces/subinterface/ipv4/state/mtu
interfaces/interface/subinterfaces/subinterface/ipv6/config/mtu
interfaces/interface/subinterfaces/subinterface/ipv6/state/mtu

@ccole-juniper
Copy link
Author

ccole-juniper commented Jan 8, 2024

Hi, with ellipsis I like the ability to probe multiple values/leafs which are defined at different hierarchies. For instance, to get all the different MTUs values on an interface, I can do a GET on /interfaces/interface[name=Ethernet1]/.../mtu and it can give all the MTUs defined in OpenConfig models:

interfaces/interface/state/mtu
interfaces/interface/routed-vlan/ipv4/config/mtu
interfaces/interface/routed-vlan/ipv4/state/mtu
interfaces/interface/routed-vlan/ipv6/config/mtu
interfaces/interface/routed-vlan/ipv6/state/mtu
interfaces/interface/subinterfaces/subinterface/ipv4/config/mtu
interfaces/interface/subinterfaces/subinterface/ipv4/state/mtu
interfaces/interface/subinterfaces/subinterface/ipv6/config/mtu
interfaces/interface/subinterfaces/subinterface/ipv6/state/mtu

Thanks!

That could alternatively be covered by:

interfaces/interface/state/mtu
interfaces/interface/routed-vlan/*/*/mtu
interfaces/interface/subinterfaces/subinterface/*/*/mtu

Hypothetically, how would you feel about that as an alternative?

@abtuteja
Copy link

Hi,
It is doable but then the client needs info on what schema is supported by which device and then forming a request. The ellipsis gives the ability to probe whatever leaf is available/defined. There are alternatives to use it but I would argue against removing a feature just due to a lack of efficient implementation.

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