Hi, experts
Encounter a question about the ref-counter.
I created a demo service to make it clear. The demo service named classtest will configure a fixed class-map on the device.
The steps are as below.
1. creating the service instance s1 to configure the class-map to device. And the refcounter of the class-map in CDB is 1.
2. creating the service instance s2, the configure won’t deploy to the device as it already exists. And the refcounter in CDB increase to 2.
3. delete the service instance s1. The expected behavior should be only decrease the refcounter to 1 in CDB and no configuration change to device, right?
But the fact in my test is the class-map is deleted in the device. Not only the content of the class-map, but the class-map itself.
Below is the terminal output of my operation.
admin@ncs(config)#
admin@ncs(config)# services classtest svc1 name a1 device r1
admin@ncs(config-classtest-svc1)# commit dry-run outformat native
native {
device {
name r1
data class-map a1
match precedence 2 3
end-class-map
!
}
}
admin@ncs(config-classtest-svc1)# commit
Commit complete.
admin@ncs(config-classtest-svc1)# end
admin@ncs# show running-config devices device r1 config cisco-ios-xr:class-map a1 | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>r1</name>
<config>
<class-map xmlns="http://tail-f.com/ned/cisco-ios-xr" refcounter="1" backpointer="[ /ncs:services/classtest:classtest[classtest:svc='svc1'] ]" >
<name>a1</name>
<match>
<precedence>
<list>2</list>
<list>3</list>
</precedence>
</match>
</class-map>
</config>
</device>
</devices>
</config>
admin@ncs# config t
Entering configuration mode terminal
admin@ncs(config)# services classtest svc2 name a1 device r1
admin@ncs(config-classtest-svc2)# commit dry-run outformat native
native {
}
admin@ncs(config-classtest-svc2)# commit
Commit complete.
admin@ncs(config-classtest-svc2)# end
admin@ncs# show running-config devices device r1 config cisco-ios-xr:class-map a1 | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>r1</name>
<config>
<class-map xmlns="http://tail-f.com/ned/cisco-ios-xr" refcounter="2" backpointer="[ /ncs:services/classtest:classtest[classtest:svc='svc1'] /ncs:services/classtest:classtest[classtest:svc='svc2'] ]" >
<name>a1</name>
<match>
<precedence>
<list>2</list>
<list>3</list>
</precedence>
</match>
</class-map>
</config>
</device>
</devices>
</config>
admin@ncs# config t
Entering configuration mode terminal
admin@ncs(config)# no services classtest svc1
admin@ncs(config)# commit dry-run outformat native
native {
device {
name r1
data class-map a1
no match precedence 2 3 //the class-map should not be delete.
end-class-map
!
}
}
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)# end
admin@ncs# show running-config devices device r1 config cisco-ios-xr:class-map a1 | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>r1</name>
<config>
<class-map xmlns="http://tail-f.com/ned/cisco-ios-xr" refcounter="1" backpointer="[ /ncs:services/classtest:classtest[classtest:svc='svc2'] ]" >
<name>a1</name>
</class-map>
</config>
</device>
</devices>
</config>
The class-map is delete on the device.
RP/0/RSP0/CPU0:11_tj-e-2#sh run class-map a1
Tue Oct 25 06:45:40.921 UTC
% No such configuration item(s)
RP/0/RSP0/CPU0:11_tj-e-2#
The NSO version is 4.2.1 and NED is cisco-ios-xr 4.4.1. I also tried NED cisco-ios-xr 4.4.5 and got the same result.
Is there anything wrong?
Thanks.
Best regards.
—
He Chang
Hello,
I am sorry to say leaf-lists are not handled by FASTMAP.
As service svc1 created the leaf-list precedence/list it will also be removed when
the service svc1 is deleted.
To see what a service does and also get warnings do:
services classtest svc1 name a1 device r1
commit dry-run | debug service
For leaf-lists the suggestion today is to have a stacked service design. Model a service with a list
which maps to a leaf-list on the device. Then each list instance of the service will be correctly
reference counted.
Cheers
/Dag
Hi, Dag
Thanks for your explanation. I saw that warning using debug service command.
BTW, do we have roadmap to support leaf-list in FASTMAP?
Best regards.
—
He Chang
Hi, Dag
Also, there is another issue may related to this.
When we add configuration with delete tag in service create code, the dry-run debug service gives a warning as below.
*** WARNING ***: delete in service create code is unsafe if data is shared by other services
Does it mean the delete operation is not handled by FASTMAP?
And if we use, it will have the ref-counter issue also?
Thanks.
Best regards.
—
He Chang / 常 贺
Hello,
work for handling leaf-lists correctly in FASTMAP has been started.
The work is extensive so it is not yet on the roadmap. It will be part
of a future major release. It will not be part of the upcoming 4.3 that is for
sure.
Cheers
/Dag
Hello,
yes deleting things in a service is unsafe if several services share the same data.
If there is just one service the FASTMAP algorithm will handle the deleted items.
There is no such thing as a shared delete.
If however you need to delete something in a service and several services needs
to delete the same configuration you can use a stacked service design pattern.
Let one service S1 handle the initial configuration, delete and setting something.
Let all other services dependent on the same initial configuration share-create S1.
Then configuration will be restored when the last service is deleted because of
S1 being reference counted.
Cheers
/Dag
Hi!
I just created a simple VLAN service for another project, maybe you can use it as a starting point. Please note that it's barely tested
YANG below and service template attached.
Fredrik