There are three types of transactions in clixon-controller:
- Device connection establishment and configuration pull
- Device configuration push (validate / commit)
- Device RPC calls
Transactions of the first type usually succeed or fail quickly. In practice, you either have a connection to the device or you don’t. Likewise, a NETCONF <get> operation typically completes very fast.
Transactions of the second and third types can take significantly longer. Operations like VALIDATE, COMMIT, or device-specific RPCs may take a while to complete on the device side.
Some issues we've observed
-
Having a single device-timeout for all three transaction types is inconvenient. From a user perspective, I’d expect an almost immediate response if a device is unreachable (connection failure), while being able to wait longer for configuration push results.
-
The push commit command may run for up to device-timeout seconds without producing any output. If device-timeout is set to a large value, staring at a blank screen for that long is quite frustrating.
-
If an unrecoverable error occurs during a Push transaction — for example during discard, commit, or when the device timeout is triggered — the affected device is disconnected and the transaction is aborted without rollback.
If the transaction involved multiple devices, it’s unclear where the configuration was actually applied and where it was not. The only thing you know is where it failed (from the field in the transaction).
Would it make sense to:
- Separate the device connection timeout from the configuration push / RPC timeouts and make them different configuration parameters?
- Show progress information in the CLI after push commit / validate has started?
- Extend transaction information (available via NETCONF, CLI, and RESTCONF) to include which devices were actually affected and whether the operation succeeded or failed on each one?
There are three types of transactions in clixon-controller:
Transactions of the first type usually succeed or fail quickly. In practice, you either have a connection to the device or you don’t. Likewise, a NETCONF
<get>operation typically completes very fast.Transactions of the second and third types can take significantly longer. Operations like VALIDATE, COMMIT, or device-specific RPCs may take a while to complete on the device side.
Some issues we've observed
Having a single device-timeout for all three transaction types is inconvenient. From a user perspective, I’d expect an almost immediate response if a device is unreachable (connection failure), while being able to wait longer for configuration push results.
The
push commitcommand may run for up todevice-timeoutseconds without producing any output. Ifdevice-timeoutis set to a large value, staring at a blank screen for that long is quite frustrating.If an unrecoverable error occurs during a
Pushtransaction — for example during discard, commit, or when the device timeout is triggered — the affected device is disconnected and the transaction is aborted without rollback.If the transaction involved multiple devices, it’s unclear where the configuration was actually applied and where it was not. The only thing you know is where it failed (from the field in the transaction).
Would it make sense to: