ConfD User Community

Aborted transaction (because of MUST) causes CDB inconsistency error on CLI which uses model with MUST constrain from subagent

General
#1

I have the next problem: I have a model with “must” constraint. That model is located on subagent (S) and mounted to the main system (M) (compiled with --subagent /) .

When I try to commit configuration on S (via CLI) I am getting the error message and CLI wants me to either fix the configuration (to fitt the constrain) or to revert the changes.

The same action on M causes the next message:

cGate(config)# commit
Aborted: <my node>: <my error message from must>

--- WARNING ------------------------------------------------------
Running db may be inconsistent. Enter configuration mode and
load a saved configuration.
------------------------------------------------------------------

The same behaviour I can see if some of the validation points abort the transaction: on S it is ok, on M it causes the same warning.

there are no warnings on S, while if I enter CLI on M again I see that message on login.
If I clean up (reinstall) CDB on M everything is OK.

What should I do, how to figure out the reason for such behaviour?

Thank you.

#2

This looks like a ConfD bug. The message appears as soon as a commit on the master fails due to that the subagent refuses the new configuration. If this is an option for you, I think you can just ignore it - as far as I know, it appears only as a message in the CLI and does not affect the system. You can also clear the flag using maapi_set_running_db_status().

If you have a channel for that you can try to raise a ticket, but since subagent setup is very rarely used, I’m not sure if it has a real chance for a fix.

1 Like
#3

I need to correct my statement a bit: it is not so innocuous as it seemed. If you have two subagents and your configuration change touches both of them, and the first subagent accepts the configuration whereas the second refuses it, this is when the database really becomes inconsistent - the change done to the first subagent is not reverted, so your configuration has been only partially applied.

#4

Thank you very much for your answer; my setup is using only one subagent and one master (for the error to appear) and I will not use the subagents feature at all.