Skip to content

Internal Changes representation is not working as expected

While I've been looking into #145 (closed) I've discovered a few more bugs with intended changes ONDs, so called Changes in the goSDN environment.

Description

If we consider the following scenario:

  1. request a set for /system/config/hostname with a new hostname(a Change is created)
  2. commit the requested Change. the commit is accepted and the Change is pushed to the OND (NOTICE: this Change will not be confirmed)
  3. request a get for /system/config/hostname (this results in the device.Model being updated with the new hostname)

Now one would expect that after the defined expiration time, the Change is reset, since no confirm of the change has taken place. But the result is: no actual rollback took place.

Since the reference of the previousState of a Change points directly towards device.Model (see here), it is impossible to detect a difference between previousState and intendedState in this scenario.

This suggests that it would be necessary that previousState should be a reference to a copy of device.Model(instead of a reference to the actual device.Model) at the time of the initialisation of the Change.

However, this problem raises further questions:

  1. What happens if there are multiple Changes and if there are confirms in-between?
  2. What happens if the device has been modified from somewhere else?
  3. ...

Additional findings:

  • change.Confirm doesn't stop the timer, therefore a reroll will always be initiated

  • If device.Model is empty a delete for the path is triggered

  • If for a specific Change a reroll is executed, it is not possible to interact further with that Change. Hence, it is not possible in the further course, e.g., to have all Changes displayed. This is because the errChan is blocking, since it has no reciever (see here).

  • After a COMMITED change has been rerolled, he keeps his state. Instead it should either be reset to PENDING or even be completly removed.

Edited by Malte Bauch