Hi,
I've written up a proposal on what source file headers should contain at
[1]. Comments, changes, questions welcome from everyone. Approval of the
proposal welcome from Vidar and/or Morten.
[1] http://metanav.uninett.no/devel:source_file_headers
--
Stein Magnus Jodal
UNINETT
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
--
mvh
Morten Brekkevold
UNINETT
