Hi Team, I am facing an issue where commit-id is getting improperly incremented when restconf is used. This unusual behavior is causing issues while doing a configuration rollback since we are not sure if each command increased commit IDs by 1 or 2.
confd version: 8.0
I can see two issues:
- If I did few CLI commits, and then did a change via restconf, commit-id is incremented by 2 (10022–> 10024)
- If I pushed a config via restconf that already exists, commit-id is not incremented (expected since there is no delta), but after this if I do another configuration via restconf which does have a config change, commit-ids are incremented by 2. (10027–> 10029)
admin@kumar-abhijeet-10-164-33-141-08-28-06-44 08:26:21# show configuration commit list
SNo. ID User Client Time Stamp Label Comment
0 10029 admin rest 2023-08-28 08:26:42
1 10027 admin rest 2023-08-28 08:25:51
2 10026 admin rest 2023-08-28 08:24:36
3 10025 admin rest 2023-08-28 08:22:36
4 10024 admin rest 2023-08-28 08:21:07
5 10022 admin cli 2023-08-24 12:03:05
6 10021 admin cli 2023-08-24 12:01:36
7 10020 admin cli 2023-08-24 12:00:44
8 10019 admin cli 2023-08-24 11:59:45
I don’t think there is any contract as to behavior of rollbacks’
fixed-number attribute, except that for given rollback it never changes. If you need to refer to rollbacks relatively to the most recent, use rollback id which starts with 0 for the most recent and increases by 1.
Hi mvf, thanks for your answer.
I checked how we are doing rollback and why this changed behavior is affecting us.
We use this restconf api for rollbacks–>
Instead of providing which commits (fixed-number) we need to revert, we specify a number that is a diff between when we started configuration and where we are now. For example, If I want to revert configuration done via rest, I will do
Call above api with this xml
But, here is the problem, I endup reverting configurations done via cli too.
If the commit-ids were sequential, the revert will work correctly
Because commit-ids are getting incremented by
2 infrequently in between, the application cannot co-related which id to revert to based on commit-ids returned in initial and final config.
So there is certain rollback you want to apply and you know its
fixed-number? In that case just use it instead of its
id, i.e. send