Load/save vs rollback?

CDB and CDB API
1

Hi,
my scenario is:
there’s a system under test. Tests basically are doing some commits on which apps that are tested do some more commits and then the state and configuration of the system is validated. On with the next test etc.

Now I need to restore the system to some initial configuration and state before each test. I can’t afford backup and restore because that involves reset of the system which takes too long.

I’m considering using save and load or using rollbacks.

I find load a litte too disruptive, I mean it will basically edit config in one transaction and I don’t know if this won’t have any side-effects on my applications…
… load doesn’t know which of the changes were commited by test code and which were committed by applications so there’s room to potential problems with applications that do not expect to have “their” config modified without reboot.

Is rollback a more gentle way to revert config in this respect ?
I could selectively rollback changes that were commited by test code backwards and that would be the least surprising way to the applications. They should be able to handle that and the system should be reverted to initial state.

Does my reasoning make sense?

Is there a method to remember initial rollback point and then get list of the consecutive rollback points after each test execution, filter the ones commited by CLI or NETCONF and play them back?

Best regards!
Filip

2

Hi,

In general, if the system was transactional and targeted automation, creating a base config as your initial config and setting that as the state before each test would be providing you with test results that are not affected by some other config diff.

But if the system is not transactional and cannot accept that you set the config back to a base config, or that you can’t set the config back to a base config for some other reason, the rollback strategy that you describe seems to be the most reasonable way to revert/roll back your test configuration.

Best regards

3

hello Conny,
yes, it’s not that simple. I mean that the system configuration is kinda divided; some configuration data is visible to northbound interfaces and meant to be manipulated by them (‘external’ config) and the rest is ‘internal’ configuration meant to be manipulated by the system itself in response to the changes to former. For the sake of design and implementation simplicity the applications “own” their parts of configuration and may assume that “their” configuration is never changed from outside or by other applications. Unfortunately these configurations categories are not in separate branches but interleaved. So I can’t simply save/load the ‘external config’…

That why my asking about rollback functionality in ConfD because at least I can tell if rollback corresponded to a transaction commited by system or from outside, right?

Where can I find more documentation about this functionality (or is the User’s Guide the only resource)?

4

The confd.conf(5) man page under /confdConfig/rollback settings is all you need.
I would just dedicate a user name to your tests, e.g. “test” and then if I want to rollback configuration selectively related to that user, just search the rollback files for that user:

$ cat confd-cdb/rollback0
# Created by: test
# Date: 2020-05-28 18:41:01
# Via: netconf
# Type: delta
# Label: 
# Comment: 
# No: 10001
# TransactionId: 48
# Hostname: Some-Host

dhcp {
    delete:
    default-lease-time 34s;
}

find the test user rollback files:

$ find ./confd-cdb  -name "rollback*" |xargs grep "Created by: test" | cut -d ":" -f 1
./confd-cdb/rollback2
./confd-cdb/rollback3
./confd-cdb/rollback1
./confd-cdb/rollback0
5

Over NETCONF you could do something like this:

$ netconf-console --rpc=-<<<'<get><filter type="subtree"><rollback-files xmlns="http://tail-f.com/ns/rollback"><file><creator>test</creator></file></rollback-files></filter></get>'
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <rollback-files xmlns="http://tail-f.com/ns/rollback">
      <file>
        <id>1</id>
        <name>rollback1</name>
        <fixed-number>10003</fixed-number>
        <creator>test</creator>
        <date>2020-05-28 18:51:53</date>
        <via>netconf</via>
      </file>
      <file>
        <id>2</id>
        <name>rollback2</name>
        <fixed-number>10002</fixed-number>
        <creator>test</creator>
        <date>2020-05-28 18:51:35</date>
        <via>cli</via>
      </file>
      <file>
        <id>4</id>
        <name>rollback4</name>
        <fixed-number>10000</fixed-number>
        <creator>test</creator>
        <date>2020-05-22 03:10:41</date>
        <via>cli</via>
      </file>
    </rollback-files>
  </data>
</rpc-reply>

If you need some more details:

$ netconf-console --rpc=-<<<'<action xmlns="urn:ietf:params:xml:ns:yang:1"><rollback-files xmlns="http://tail-f.com/ns/rollback"><get-rollback-file><id>1</id></get-rollback-file></rollback-files></action>'
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <content xmlns="http://tail-f.com/ns/rollback">
# Created by: test
# Date: 2020-05-28 18:51:53
# Via: netconf
# Type: delta
# Label: 
# Comment: 
# No: 10003
# TransactionId: 174
# Hostname: SOME-HOST

dhcp {
    subnets {
        delete:
        subnet 192.168.128.0 255.255.255.0;
    }
 }
</content>
</rpc-reply>

Do a selective rollback:

$ netconf-console --rpc=-<<<'<action xmlns="urn:ietf:params:xml:ns:yang:1"><rollback-files xmlns="http://tail-f.com/ns/rollback"><apply-rollback-file><id>1</id><selective/></apply-rollback-file></rollback-files></action>'
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

etc…

6

I have similar requirement , I need to revert to original base for my tests to start always with a fresh environment . Can you point right document with which i can label the config as “base” . and the steps to revert it via rest-api ??

7

I suggest you use a RESTCONF YANG patch where you delete your root resources and merge your base config in the same patch.
Examples from the RFC: https://tools.ietf.org/html/rfc8072#appendix-A.1.5
See also examples.confd/restconf/yang-patch