Changes applying order during commit request after edit-config to candidate broken when request contains changes for a few modules #3210
Comments
|
I found, that problem was gone when i rollback to sysrepo version 2.2.33 (a1075ab). The next commit (d081644) changes direct reading and writing into shm for subscription to ATOMIC operations and also add more checks for event presence in shm. I found this commit as last which changed sr_shmsub_multi_notify_write_event function. |
|
If I understand it correctly, you want the changes of modules to be applied in a specific order. In current versions there is the function |
|
On the contrary, I'm waiting for edit-config request changes from the first post to be applied sequentially. Changes for ietf-interfaces - before changes for bbf-l2-forwarding (according they order in edit-config xml). Isn't it the default behaviour? Because we never had changes applying order broken on the previous sysrepo versions (not devel). |
|
The order of the data in the edit-config with regards to different modules is ignored since libyang v2 is used because the data are always ordered based on the modules order in the context, which is alphabetical. That is why you can explicitly set the module order. |
|
Hello! Problem: when execute an rpc to delete interfaces+forwarders - the request fails to delete subinterface as there is a reference to a forwarder. Meanwhile, if use sr_module_change_set_order to increase priority for bbf-l2-forwarding module for 10 instead of 0 - it fails to add forwarder as it is adding before subinterface. In the same time that interface/forwarder pair that was created before changing order can be successfully deleted Sysrepo version is 2.2.150 (latest master). Is this intended? Shouldn't the order be reversed in case of delete operation? I can't find any info on the internet / in the code If there is no such feature, could you please tell how can I get info about nc:operation='delete' in sr_modinfo_next_mod or what is the correct way to achieve this? |
Meaning you get a validation error and no data change occurs? That would be the correct behavior.
I do not understand what the order has to do with this, it should not matter at all for validation. But it is possible something does not work as it should, you may try using the current |
|
Thank you for your reply! I checked devel branch, unfortunately it didn't work Just to clarify the question: I want dependent modules to have reverse order when I delete their nodes in the same request. And sr_module_change_set_order does not count the difference between adding nodes (straight order) and removing nodes (reverse order) Like if I want to add interfaces and add forwarders related to them in the same request, the order should be "add interface, add forwarder on that interface". But, if I want to delete that exact pair in one request, the order should be "delete the forwarder, delete the interface" (order is the opposite to add operation). Does sysrepo have such behavior? How it is controlled, what part of the code is responsible for it so I could debug it in there. If it does not, what would you recommend to implement it? My implementation ideas:
Also, it would work if configure each interface/forwarder in separate request, but it can't be implemented as a lot of our and customers testing configuration adds or deletes these objects in one request. |
No, the order cannot be controlled the way you described. Calling the callbacks in the right order is handled by One way of implementing this would be subscribing the same callback to both interface and forwarder changes. The callback can then detect that both were removed or added and perform whatever it needs in the correct order. |
We have one change callback for all modules, it processes each module independently. Do you say we can process several modules at once? So we could apply the correct order |
|
What you should be able to do is ignore whether sysrepo calls the callback for changes on |
|
I think we could just disable sorting of the incoming data tree to alphabetical order in libyang - so it would stay exactly as it is in the original request. Can you suggest places in the code to look at in libyang? |
|
That is a bad idea because all the libyang code relies on that (and it is not alphabetical but following the schema node order). But if you still want to change it, look at |
|
Hello, thanks for your previous suggestions. Idea with changing libyang was abandoned, I failed find exact place of where this order is created, so it wasn't possible to disable it. So the question is: how can I set prio when the lock has been already set by this thread? I have lack of knowledge of how does sysrepo work internally, I didn't find anything about it in documentation. In |
|
I am sorry but I will not explain to you all the internals of sysrepo when you decided to modify something, that is not part of the support we provide. |
Hello!
We have issue on sysrepo version 2.2.132 when run our functional tests. We send edit-config request to candidate datastore, which contains adding new subinterface objects and forwarders which are depend on these new subinterfaces:
Then we send commit message like this:
We perform 4 such requests (with different subinterfaces and forwarders names) sequentially. But test always failed on second or third request due wrong changes applying order.
In case of successful handling request we haven't new SR_EV_CHANGE in shared memory for bbf-l2-forwarding module when we handle SR_EV_CHANGE for ietf-interfaces:
But in falied case sysrepo added SR_EV_CHANGE into shm for bbf-l2-forwarding before we handle bbf-l2-forwarding module when we handle SR_EV_CHANGE for ietf-interfaces. So, changes for bbf-l2-forwarding depended from ietf-interfaces module changes are applied firstly. We can't find necessary new subinterfaces to create forwarders based on them and request fails:
I got such backtrace for corresponding pieces of code:
So, when we handle SR_EV_CHANGE for ietf-interfaces, we check new events for bbf-l2-forwarding module also (before we check ietf-interfaces, due bbf-l2-forwarding is first in change_subs array).
But it worked fine on sysrepo 2.1.64 version.
The text was updated successfully, but these errors were encountered: