Sending configurations separately

[temabeloglinskiy]

Hi, Olof
I have a question about the clixon-controller.
We have a scenario where the configuration needs to be sent only to certain devices, not all.
For example, these are devices in an HA-pair, where one device is active and the other passive.
We want to send the configuration only to the active device and can read the device status via the RPC.
But the problem is that the clixon-controller can't selectively send the configuration to the required devices—it sends it to all devices if the configuration has changed.
I suggest adding a function to push_device_one() between xml_diff and the configuration send. This function can be moved to the clixon-controller plugin, allowing us to implement our own configuration send logic.
What do you think about this?
Or are there other implementation methods?
I've provided a quick example in the screenshot.

[denniswa]

Can this be solved by generating and pushing HA specific config to a HA address instead of individual devices?

[temabeloglinskiy]

@denniswa The problem is that we don't know which device in the HA pair is active, as the statuses will change depending on the detected failure (port down). The idea is that before committing, we check the device's status from the clixon-controller, and the clixon-controller sends the configuration only to the active device. We already have configuration synchronization functionality from the active device to the passive one. It's also important to note that we don't have floating IP addresses on the management interface, as this would require a manual reconnection by the clixon-controller after the device status changes from passive to active.

[denniswa]

That was basically what I was asking if you could manage the device(s) via floating IP instead :-)

[olofhagsand]

We are currently making a revision of the transaction mechanism to make the semantics clearer, see eg #247 (part 3). I that work the semantics for skipping devices is more clear. So far, reasons for skip can be if a device is disabled, or is not connected / not reachable. This is primarily for pull, but also applies for push, with the difference that a changed closed device generates an error and the whole transaction is aborted.
I think you are suggesting a further reason to skip a device for push (or pull?) which could be controlled by the application by a callback. I.e., reasons for skipping devices is not only that they are disabled or closed, but also if the application indicates a "soft" skip flag/callback for a device.
Is this what you had in mind?
The reason why a commit fails if a device is changed AND is not connected, is that the local controller config will not be in sync with the actual device config. If an oen device is skipped in this way, this will be the case, eg that the config as the controller sees it, is different from what the actual device config is. It is like it is disabled.
BTW, have you considered disabling the passsive?

[temabeloglinskiy]

@olofhagsand Yes, we'd like to introduce additional features to gracefully skip configuration application for devices. In our case, we can use a callback to read the device status and, if the device is in standby mode, not send the configuration to it (commit push).
There's no problem with the configuration difference between the clixon-controller and the device in standby mode, as the device can become active at the next moment, and the previously saved configuration in the clixon-controller will be sent to that device.

[denniswa]

I might be wrong here but that way I think about commits is that if your commit contains config for device1 and device2 and you have marked device2 to be skipped then the commit would always fail (and rollback for both devices).
Do you suggest that we do local commit on both devices and the only push to device1? In that case the controller and device config will (probably) always be out-of-sync with device2 and you have to manually pull config from device2 after every commit. That manual pull would then always overwrite what was in the controller... I guess in your case the diff might be minimal since its replicated between HA devices but it seems a bit messy?

[temabeloglinskiy]

@denniswa We tried configuring fw1 and fw2 from the clixon controller, skipping the fw1 device, and performing a commit push—the transaction completed successfully.
How we did this is shown in the screenshot from my first post.
Regarding replication between active and passive devices, our algorithm requires the first device to confirm the application of the configuration on the second device. Otherwise, the commit on the first device won't work, and the transaction will be rolled back with an error. So, we only need to send the configuration to the first device—it will either replicate the configuration to the second device with confirmation, or it won't replicate and roll back the entire transaction. The reason we're not considering simultaneous configuration synchronization via clixon-controller on both devices is because there are configuration differences in terms of IP addresses or MAC addresses. However, we do allow these parameters to be reconfigured via clixon-controller on each device individually.

[denniswa]

@temabeloglinskiy OK so after your successfully completed commit both devices are still in-sync? (check by issue 'show devices diff')

[temabeloglinskiy]

@denniswa There is no difference in configuration - everything is fine

root@eve-img>
root@eve-img> conf
root@eve-img> configure
root@eve-img[/]# set devices device * config contexts context sample config description new1
May  6 15:27:27.152484: MARK: rpc_get_yanglib_mount_match: MARK1
May  6 15:27:27.152524: MARK: rpc_get_yanglib_mount_match: MARK2
May  6 15:27:27.152533: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:27.152547: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:27.155478: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:27.155498: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:27:27.155521: MARK: rpc_get_yanglib_mount_match: MARK3
May  6 15:27:27.155533: MARK: rpc_get_yanglib_mount_match: MARK32
May  6 15:27:27.155542: MARK: rpc_get_yanglib_mount_match: Device name is fw1
May  6 15:27:27.155549: MARK: rpc_get_yanglib_mount_match: MARK32
May  6 15:27:27.155557: MARK: rpc_get_yanglib_mount_match: Device name is fw2
May  6 15:27:27.155565: MARK: rpc_get_yanglib_mount_match: MARK4
May  6 15:27:27.587155: MARK: rpc_get_yanglib_mount_match: MARK1
May  6 15:27:27.587192: MARK: rpc_get_yanglib_mount_match: MARK2
May  6 15:27:27.587201: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:27.587238: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:27.590181: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:27.590203: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:27:27.590233: MARK: rpc_get_yanglib_mount_match: MARK3
May  6 15:27:27.590246: MARK: rpc_get_yanglib_mount_match: MARK32
May  6 15:27:27.590267: MARK: rpc_get_yanglib_mount_match: Device name is fw1
May  6 15:27:27.590282: MARK: rpc_get_yanglib_mount_match: MARK32
May  6 15:27:27.590290: MARK: rpc_get_yanglib_mount_match: Device name is fw2
May  6 15:27:27.590298: MARK: rpc_get_yanglib_mount_match: MARK4
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]# op
root@eve-img[/]# operation sho
root@eve-img[/]# operation show d
root@eve-img[/]# operation show devices di
root@eve-img[/]# operation show devices diff
  <cr>
root@eve-img[/]# operation show devices diff
May  6 15:27:36.696568: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:36.696603: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:36.698622: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:36.698648: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:27:36.706573: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:36.706598: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:36.706776: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:36.706787: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:27:36.706821: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:36.706843: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:36.707249: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:36.707271: MARK: clicon_rpc_netconf_xml: MARK4
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]# comm
root@eve-img[/]# commit pus
root@eve-img[/]# commit push
  <cr>
root@eve-img[/]# commit push
May  6 15:27:52.708986: MARK: <actions-type> argument is CHANGE
May  6 15:27:52.709118: MARK: MARK1
May  6 15:27:52.709146: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:52.709202: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:52.718660: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:52.718686: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:27:52.718704: MARK: MARK11
May  6 15:27:52.718719: MARK: MARK12
May  6 15:27:52.718728: MARK: MARK2
May  6 15:27:52.718739: MARK: MARK3
May  6 15:27:52.719773: MARK: MARK4
May  6 15:27:59.167318: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:27:59.167353: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:27:59.167531: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:27:59.167556: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:27:59.167579: MARK: MARK5
OK
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]#
root@eve-img[/]# operation show devices diff
May  6 15:28:55.969355: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:28:55.969416: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:28:55.971586: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:28:55.971630: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:28:55.980333: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:28:55.980387: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:28:55.980645: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:28:55.980664: MARK: clicon_rpc_netconf_xml: MARK4
May  6 15:28:55.980754: MARK: clicon_rpc_netconf_xml: MARK1
May  6 15:28:55.980785: MARK: clicon_rpc_netconf_xml: MARK2
May  6 15:28:55.981290: MARK: clicon_rpc_netconf_xml: MARK3
May  6 15:28:55.981309: MARK: clicon_rpc_netconf_xml: MARK4
root@eve-img[/]#

FW1

FW2

[denniswa]

@temabeloglinskiy OK nice, so as long as you edit config that also is automatically replicated it works. The drawback would be if some config is not replicated or if you only edit one device instead of both then you would end up with one device out-of-sync, but that might be acceptable or even expected

[temabeloglinskiy]

@denniswa Yes, exactly.

@olofhagsand Olof, can you tell me when you plan to consider implementing the soft skip feature in the clixon-controller?

[olofhagsand]

As I said we are reviewing the transaction skip/closed/disabled semantics to make it clearer. Soft skipping sounds like a good idea but will have to wait until this revision is done. It will be after 7.8 is released.