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

subscription: return parent node to oper_state callback #45

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

avazquezrd
Copy link
Contributor

We have a Sysrepo plugin that is subscribed as operational data provider to /ietf-hardware:hardware/component/software leaf, which generates a call for each component when /ietf-hardware:hardware node is requested (as expected). The problem is that with the parameters currently available in OperDataCallbackType (xpath, private_data), it is not possible to distinguish between components. Similar problem with interfaces-state module is described here.

The solution proposed in that issue consists of using the parent node that is returned, since in this case the state must also be built on this parent node. This parent node has the path with the key we need, so we can distinguish between components.

This pull request adds the parent node as parameter exposed in operational state request callback.

Copy link
Collaborator

@rjarry rjarry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Adrián,

thanks for your patch. I am not comfortable with breaking the API. Would it be possible to change the xpath argument to convey some information about the actual list item that is being refered?

In the linked issue sysrepo/sysrepo#1786 it mentions that it is possible to call lyd_path(*parent) to get the actual requested node.

What do you think?

sysrepo/session.py Outdated Show resolved Hide resolved
sysrepo/subscription.py Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented Mar 2, 2023

Codecov Report

Attention: Patch coverage is 16.66667% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 66.54%. Comparing base (956e214) to head (587f88c).

❗ Current head 587f88c differs from pull request most recent head 362f5b2. Consider uploading reports for the commit 362f5b2 to get more accurate results

Files Patch % Lines
sysrepo/subscription.py 0.00% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #45      +/-   ##
==========================================
- Coverage   66.93%   66.54%   -0.40%     
==========================================
  Files           8        8              
  Lines        1113     1064      -49     
==========================================
- Hits          745      708      -37     
+ Misses        368      356      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@avazquezrd avazquezrd requested a review from rjarry March 2, 2023 18:51
@rjarry
Copy link
Collaborator

rjarry commented Mar 26, 2024

Hi sorry for the very long delay. I had a second look and I am still not comfortable with breaking this API.

I had an idea: we could add a parent_xpath key in the extra_info keyword arguments of the operational data callback when extra_info=True is set during subscription. That way, the API is preserved and you get the info you need.

What do you think?

@avazquezrd
Copy link
Contributor Author

avazquezrd commented Mar 26, 2024

Hi sorry for the very long delay. I had a second look and I am still not comfortable with breaking this API.

I had an idea: we could add a parent_xpath key in the extra_info keyword arguments of the operational data callback when extra_info=True is set during subscription. That way, the API is preserved and you get the info you need.

What do you think?

Hi! I had already forgotten about this issue 😅. I think that it would be enough to distinguish between different leafs in a list, yes.

Another thing I mentioned in my initial comment is that the parent node is also needed to build the state on it, but I think that the parent node can be re-instantiated from XPath without any problem and we could build the state directly on it, right? In that case, I think that your proposal is fine for the use that this parameter should have!

@avazquezrd
Copy link
Contributor Author

Hi!

I have added requested changes, now the parent_xpath is passed through extra_info.

The only way to differentiate two calls when there is a subscription
on an internal element of a list is by using the parent node. Moreover,
in these cases, it is on this parent node that the data structure to
be returned must be built.

Signed-off-by: Adrián Vázquez <[email protected]>
@avazquezrd
Copy link
Contributor Author

avazquezrd commented May 14, 2024

Hi @rjarry, any new comments on this? I'm not sure why the GitHub workflows are failing, but it seems more like a setup thing.

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

Successfully merging this pull request may close these issues.

2 participants