As you know, we're planning to get rid of some of the complexity of recording device lifecycle events in NAV, by removing parts of the device management system.

Yet, it appears that parts of the lifecycle event recording that was planned, is still wanted, and should have been present since 2003 has not been properly implemented.

As the tigaNAV report [1] of 2003 states, there are supposed to be events for "start of operation" and "end of operation". When a device is first seen on the network, serving as either a netbox or a module, a "start of operation" event should be posted. When the netbox is deleted, an "end of operation" event should be posted. This is all neatly explained on pages 56-57 of the report.

Also, when a netbox is replaced in the field, one "end of operation" should be posted for the old device, and a "start of operation" should be posted for the new device.

The former seems to have never been implemented. The latter is partially implemented through the serialChanged event type, which is posted by getDeviceData when it notices that a netbox' serial number has changed.

Before I go on, I'll add this reference to an ongoing issue where this surfaced: https://bugs.launchpad.net/nav/+bug/285336

The serialChanged event does not have the deviceid field set, because it is related to two deviceids, not one. A consequence of this is that alerthist entries for serialChanged will never be removed from the database, even when the netbox is deleted. The only trigger action here is setting netboxid=NULL when a netbox is deleted. The alerthist table is left with orphaned records (i.e. no deviceid or netboxid foreign keys set).

There does exist a deviceState event type, with at least to related alert types (deviceInIPOperation, deviceInStack) that address the aforementioned lifecycle events from tigaNAV. These lack the corresponding stop-events, and they seem to be unused by NAV - at least, I cannot find them present in the alerthist tables of any of the installations I've checked.

So far, this is all informational. Here's hoping that some discussion will result from this.

Nonetheless, this is material for a blueprint. Seeddb obviously needs modification to support this, and so does gDD. Probably, it will be implemented as part of the new ipdevpoll, not gDD, so hopefully it will be there in NAV 3.6.

[1] http://metanav.uninett.no/static/reports/tigaNAV.pdf