I was wondering if it is possible to trigger a transaction commit (maapi_apply_trans) in an action handler (for an action to which a transaction is associated of course, such as an action triggered from the CLI).
I gave it a try and couldn’t succeed to make it work. I tried two different methods.
Method one, I just used the maapi_apply_trans on the transaction I obtained from the confd_action_ctx (i.e the current transaction ongoing in the agent that triggered the action). To me, it makes sense that it does not work since that would place the transaction in a new state (START first and then READ) and therefore the agent that initiates the action would end up with a transaction in a new state without knowing it. Is-that the reason why it does not work?
Method two, I created a new transaction with maapi_start_trans (let’s call it T2) on the maapi socket attached to the action transaction (let’s call it T1). Then I copied T1 into T2 with maapi_copy. After that, I just call maapi_apply_trans and maapi_finish_trans. But that fails too. I don’t get why.
You cannot commit/apply a attached transaction (and I guess you can’t really expect this to work). But nothing prevents you from opening a new read-write transaction, doing whatever changes you need to do and then applying it.
Now I have read your question more carefully… I’m not really familiar with maapi_copy, but the manpage says that it is intended for copying between “two transactions from the same user session but towards different data stores” - that is not your situation, or is it?
I’m not sure what behavior you are trying to get, can you describe it? Why do you need to copy the configuration between the two transactions?
We use the I-style CLI and in configuration mode we have an action for several submodes that one can call to apply the configuration that the user just entered (so the configuration accumulated in the current opened transaction).
As stated in confd_user_guide-6.7.1 section 16.3.2, All changes to the
device’s configuration are done to a copy of the active configuration, called a candidate configuration. I believe if we don’t have a “cli-delayed-auto-commit” in the submode where one modifies the config then the modifications are in the candidate datastore right away, correct? In case we have a “cli-delayed-auto-commit” then each new configuration modification is accumulated in the transaction (opened then on the candidate database). In the first case, my action should only trigger a candidate commit (commit the candidate to the running) and in the second case I thought I could use the second trick I explained in my original post. But that does not work…
I think you are mixing two different notions: candidate datastore and candidate configuration - the naming is obviously unfortunate, I think this is for historic reasons.
Even if you do not have candidate datastore enabled, any change done in CLI stays in the candidate configuration until you run the commit command in C-/J- style, or complete the command in I- style, or exit the mode with delayed auto-commit. Once you do that, the changes in the candidate configuration go all the way to running, either directly or through candidate, depending on your setup. (For the sake of completeness this is a bit different if you use “config shared” mode, but I don’t think you do.)
In either case, there is nothing you need to do about the configuration after commit is issued (or the stuff in I-style happens). If you still feel you need to do something before commit, you may want to have a look at custom CLI commands instead - as I understand what you want to do applies to CLI only.
Ok I understand that “candidate configuration” is actually the pending changes in the current confd transaction, correct?
So let’s say that I’m under a submode with delayed auto-commit, and let’s say that I call an action after entering some configuration changes (I do not enter commit, or anything that would trigger it). In that case, I should see in the current transaction (I attach a maapi socket to the current transaction in my action handler) all the pending changes, correct?
Now, in this action handler I understand that I could not trigger a commit (maapi_apply_trans) and that’s normal. I understand that in fact in the I-style, the transaction I get in my action handler is opened on the running datastore. Hence I cannot use the “maapi_copy” with a new transaction that would be opened toward the running datastore, correct? But I’m now wondering why such a limitation. Why it’s not possible to open multiple transactions toward the same datastore and copy (copy the candidate configuration, so all pending modif that are stored locally in the transaction) between each other? And if it’s really not possible how can I achieve what I want to do?
I know that I can use clispec for CLI commands but we may need to have this action present for other agent as well…
You probably (have not tested myself) cannot use maapi_copy, but you have several other means at your disposal, in particular maapi_diff_iterate and maapi_cli_diff_cmd to get changes in one and apply them to another transaction. But I doubt this is what you want to do - the end result would be that after the action has completed, the CLI user has a opened transaction, but there have been a parallel transaction with changes addressing the same parts of the data model, so the CLI user would have to deal with a conflict. Can you describe how the intended behavior should look like from the user’s perspective?
As for other agents: for interfaces like RESTCONF or NETCONF the scenario does not make sense, there is nothing like “pending changes”. And if you are implementing other agents yourself, I believe you still may need to resort to custom methods, not actions.
i’m also watching this thread, is an interesting discussion, though i do not understand the requirement or intended user use-case / behavior you are trying to achieve…
I believe that inability to copy between same datastores is either missing requirement for such operation, or same reason why you cannot apply pending transaction -> not to hijack pending list of changes from transaction and force apply “in the backend”… Not that it would not be possible to resolve, but, api developers probably didn’t see the need to copy same set of changes when they can be only applied once…
Maybe if you describe from the CLI-user’s perspective what you are trying to resolve/achieve, it will make more sense and be more easy to respond to…
(maybe the thing that you are trying to resolve should be / is addressed in a different layer of pending transaction?)
If i had to guess, you might be trying to achieve some sort of dynamic checkpoints for un-commited changes, but i miss still the user point of view use-case on level of CLI…
Basically, we have some submodes with an action called “execute” which does the same thing as commit. This action is there because in our old products we have this keyword to trigger a configuration. In some of our submodes, we have a delay auto-commit (recalling that we use the I-style CLI). We do that because we don’t want the configuration to be flushed each time the user changes a single config strap. Once the user feels ready he can trigger an execute.
For pure CLI we could add this command in a clispec but I don’t know if we can controller under which submode we make this command available… Additionally, we may want to have it for an other agent (not netconf, neither restconf).
I understand. But look at it from this perspective: The transaction that you are trying to commit was opened and is owned by the agent used by the user. As we discussed, you cannot commit a transaction to which you attach; and you can copy the transaction to a new one and commit the new one, but that would not be really convenient from user’s point of view. This means that so as to do what you want, you need the agent to provide means to do that, to provide you access to user’s transactions. The CLI agent allows you to define CLI commands for this purpose; I don’t know what other agents you are using, but you need them to to provide some means too and they may or may not differ considerably from CLI commands.
And yes, you can control the mode where a CLI command is available - see the mode attribute of /clispec/$MODE/cmd.