Hello,
I am trying to do something similar to what has been done in ‘cliapp.c’ example.
The datastore configuration that I have set is similar to what is given in the example i.e (Running + Candidate + writable-through-candidate).
Steps:
Create a configuration from confd cli and commit it.
Trigger the delete-config, which performs the below set of actions:
a. maapi_connect
b. maapi_start_user_session as “admin”
c. maapi_start_trans(sock, CONFD_CANDIDATE, CONFD_READ_WRITE)
d. maapi_delete_config(sock, CONFD_CANDIDATE)
e. maapi_candidate_confirmed_commit
f. maapi_candidate_commit
g. maapi_apply_trans
h. maapi_finish_trans
Steps ‘e’ and ‘f’ were added as part of troubleshooting.
Also, note that, I am using CANDIDATE instead of RUNNING as given in the example. That is because, confd throws an error saying RUNNING cannot be used for write in this datastore configuration. So, not sure why it is like that in the example.
All the above steps finishes without error, but I do not see the configuration (show full-configuration)getting deleted. So, I am actually doubting the purpose of this ‘maapi_delete_config’ API. Is it really intended for what I am trying to do here ?
If you run the cliapp example with the “-c” flag you will start a transaction towards the candidate datastore instead of running. In confd.conf in the example the access mode for the running datastore has been set to “writable-through-candidate”, hence if you try to start a transaction towards running you will get an error saying that the “datastore is not writable”
$ make CLIAPP_FLAGS=-c start
...
./cliapp -c
dbname =1
#maapi-demo-cli
In the ConfD CLI
(config)# root bar 77 foo fuuuu servers server test ip 192.168.0.1 port 3535
(config-server-test)# commit
(config-server-test)# exit
(config)# show full-configuration root
root foo fuuuu
root bar 77
root servers server test
ip 192.168.0.1
port 3535
!
Now in the example CLI
#maapi-demo-cli help
commands
show - show current conf
help - show this text
abort - abort current trans
commit - commit current trans
create name ip port - create new server
delete name - delete server
candidate-reset - copy running into cand
validate-trans - trans validate
delete-config - delete config
candidate-commit - copy cand to running | confirm
candidate-confirmed-commit secs
maapi-demo-cli show
foo: fuuuu
bar: 77
server name=test ip=192.168.0.1 port=3535
#maapi-demo-cli delete test
#maapi-demo-cli show
foo: fuuuu
bar: 77
#maapi-demo-cli candidate-reset
#maapi-demo-cli show
foo: fuuuu
bar: 77
#maapi-demo-cli abort
#maapi-demo-cli show
foo: fuuuu
bar: 77
server name=test ip=192.168.0.1 port=3535
#maapi-demo-cli delete test
#maapi-demo-cli show
foo: fuuuu
bar: 77
#maapi-demo-cli candidate-reset
#maapi-demo-cli show
foo: fuuuu
bar: 77
#maapi-demo-cli commit
#maapi-demo-cli show
foo: fuuuu
bar: 77
Back in the ConfD CLI:
(config)# show full-configuration root
root foo fuuuu
root bar 77
Thanks Cohult.
Yes, I am running the cliapp with ‘-c’. Noticed it a while later only.
The issue I am observing is with ‘delete-config’, not with simple delete of a node.
Also, I am trying here to clear the configuration entirely, so I have commented out the namespace setting API, since in real case also I wont be knowing the namespace.
The maapi_delete_config( ) call will only remove configuration changes made through a commit (as implemented in the example) operation (maapi_apply_trans( ) followed by maapi_finish_trans( )) that haven’t yet gone through a maapi_candidate_commit( ) (meaning haven’t yet been written into the running datastore). The maapi_delete_config( ) call won’t delete any configurations from your running datastore. You will need to use the actual delete operation to clear your configuration first from the candidate datastore and then use commit followed by a candidate-commit to save it to the running datastore.
‘maapi_delete’ api takes a transaction handle, which makes me assume that it will delete the configuration changes ONLY within that transaction.
‘maapi_delete_config’ api does not take any transaction handle, so it appears to a user that it will work outside of a transaction.
As per your comment:
The maapi_delete_config( ) call won’t delete any configurations from your running datastore.
So, what does it exactly do ? I am providing it with dbname as ‘CANDIDATE’, so my expectation for it is to clear the candidate DB not RUNNING. I have tried running ‘maapi_candidate_commit’ as well after calling it.
There is ‘maapi_delete_all’ API as well, but it looks to be similar to ‘maapi_delete’ in that, it will also do the changes done within a transaction, not outside it.
What is the general recommended way of clearing the entire config outside of the transaction which created and committed the config?
Iterate through the loaded modules and find its confd namespace hash.
Find out the top nodes in that yang module and set that as the namespace in the API ‘maapi_set_namespace’
Call ‘maapi_delete’ on that node.
Do maapi_candidate_commit
End the transaction.
The iteration in #1, #2 is something an application is not expected to do, as it can be done much efficiently in the confd side, provided there is an API for that. I am looking for such an API, that can do this in a single call.
Unfortunately, maapi_delete_config() is not well documented, and it only works on candidate datastore as Wai describes.
There is a maapi_delete_all() function that can be utilized. E.g:
maapi_delete_all(sock, tid, MAAPI_DEL_SAFE) ;
followed by a load of the AAA rules:
int flags = MAAPI_CONFIG_XML | MAAPI_CONFIG_MERGE;
maapi_load_config(sock, th, flags, "./confd-cdb/aaa_init.xml");
Thanks Cohult. Really appreciate your help.
Initially I was running into some wierd issue while doing ‘maapi_delete_all’, thats why I didnt continue with it. But it seems that, after reloading the ‘aaa_init.xml’, that issue is no longer appearing.
It does work like how I wanted it to be , so does ‘maapi_delete’ with extra work. But I am noticing that, once I delete the configuration, it no longer appears in confd-cli so that I can reconfigure it. That command is effectively disappeared from the config terminal. Any idea ?
Usually that is exactly the behaviour if you deleted the AAA configuration and your user no longer have access to the configuration. Can you see your AAA configuration after the delete and reload of AAA config? If not, check that the aaa_init.xml contents were loaded properly