This document lists in more detail than the release notes tasks done in 2006 and January 2007 for NAV 3.2
| Task id | T1 | ||
| Assigned to | Morten Brekkevold | ||
| Used time | 20 hrs | ||
| Start date | |||
| Status | |||
| Due for | NAV 3.2 |
| Task id | T3 | ||
| Assigned to | Stein Magnus Jodal | ||
| Estimated time | 120 hrs (approx. 240 hrs used) | ||
| Start date | Approx. 17 July 2006 or later | ||
| Status | Finished by 6 Oct 2006 | ||
| Due for | NAV 3.2 |
This is a big task. We suggest close to a complete rewrite of the message and maintenance tool. We would like to keep most of today's functionality, but simplify the user interface. Radically improved user friendliness is our goal.
We would like to split the tool into two separate tools:
We introduce four new tables replacing the original three tables;
| message | (replaces emotd) | ||
| maint_task | (replaces (maintenance) | ||
| maint_component | (replaces emotd_related) | ||
| message_to_maint_task | (N-M relation replaces N-1) |
The following fields will be defined:
Contains the messages registered in the messages tool. Each message has a timeframe for when it is published on the NAV main page.
messageid sequential primary key
title title of the message (text)
description The message itself. Presented on the NAV main
page, open information, should be understandable
for end users (text).
tech_description technical description. Not compulsory. Not shown on
the front page. Shown on drill down page, only for logged
in NAV users. Contains more technical information
regarding the message (text).
publish_start start time for when the message is published
publish_end end time for publish
author user (NAV logged in user) who posts the message.
Only he can edit. Others can make a follow up message.
last_changed timestamp when the message was edited the last time
(typos etc may be edited)
replaces_message If there is a development in the case posted in the
original message a follow up message may be posted, the
follow up will have a reference to the message
it replaces. Only the follow up is shown on the
NAV main page with a link to its predecessor.
replaced_by Foreign key to the message replacing this one.
Automatically updated by triggers based on data
from replaces_message.
Deprecated fields from emotd table:
type deprecated
published deprecated - was used for expiring message,
we do this instead by adjusting the publish_end
affected deprecated - not always relevant
downtime deprecated - not always relevant
title_en deprecated
desscription_en deprecated
detail_en deprecated
affected_en deprecated
downtime_en deprecated
A maintenance task consist of a set of maintenance components. This may be entire locations or entire rooms or certain netboxes, modules and/or services.
A maintenance task has a time frame (start and stop time). In this time period events regarding the devices/services selected are not sent as alerts to NAV users. I.e. event engine will not post these events on the alertq, only on alerthist.
maint_taskid sequential primary key
maint_start start of the maintenance window
maint_end end of the maintenance window
description textual description of the maintenance task
author author of the maintenance task. Only the author may edit.
state takes the values 'scheduled', 'active', 'passed'
or 'overridden'. maintengine changes this value.
Keeps track of the components that are chosen for a particular maintenance task. (key,value) pairs relate to the relevant NAV tables (location, room, netbox and service).
maint_taskid the maintenance task this relates to. key may be location / room / netbox / module or service value relevant locationid/roomid/netboxid/serviceid Note: We turn off the option of setting a module on service.
This table implements an N-M relation between messages and maintenance tasks. We thus allow a task to be related to zero, one or more message. Similarly a messsage may relate to zero, one or several tasks.
messageid relation to a message maint_taskid relation to a task
This new tool will have two tabs; one for putting things on maintenance, the other for displaying the maintenance schedule. In addition the Status tool will show a listing of what currently is on maintenance, see task T4 below (consider linking to this page).
published on te NAV main page, maintenance descriptions are not)
| Task id | T4 | ||
| Assigned to | Stein Magnus Jodal | ||
| Estimated time | 40 hrs (28 hrs used) | ||
| Start date | 13 Oct 2006 | ||
| Status | Finished by 3 Nov 2006 | ||
| Due for | NAV 3.2 |
Current maintenance status should be shown on the status page. This will involve two new sections (in bold), the complete list of sections then being:
The two maintenance listings should take the same columns as there equivalent status listing. Downsince and downtime will then illustrate the downtime of components on maintenance. If the components in question is not down, the value of downsince should be 'Up' and the value of downtime should be blank.
The history icon should be used for maintenence components in the same manner as other components on the status page.
In addition a wrench icon should be used, linking the maintenance details of the item in question. I.e. the details on the maintenance task that this item is part of (maintenance window, description, optional link to adhering message).
Note that the source for the maintenance listings should be the alerthist table looking for eventtype=maintenanceState where the end time is not set.
Check that the other status components do not include items that in fact are on maintenance!
Also check that the user status page preference with this change also supports the three new maintenance section.
If there i.e. are noe modules on maintenance, 'No modules on maintanance' should be shown.
The header of the maintenance sections should not link to 'history' as the others do, but instead link to 'maintenance schedule'.
NEW: From The services down section link to the alternative graphical view; https://nav.x.y/browse/service/allMatrix Feel free to improve this view. A matrix that shows the grid lines would be better. Or take a look at how Hobbit does this. I.e. use green and red balls/bullets instead, and drop the suggested grid lines.
| Task id | T5 | ||
| Assigned to | Morten Brekkevold, Stein Magnus Jodal | ||
| Estimated time | 80 hrs (first four bullets) | ||
| Start date | |||
| Status | |||
| Due for | Partly NAV 3.2, maybe all |
It is set to 100 today, consider if the default should be larger… 1000!
Use data from netboxinfo with key='unreqCDP'.
Alternatviely consider making a separate gwipport report with focus on IP attributes (ip addresses, metric, hsrp, vlan and more). The gwport report could then have all interfaces listed once, so that secondary addresses and static routes will not be included here, only in gwipport.
| Task id | T6 | ||
| Assigned to | Morten Brekkevold, Stein Magnus Jodal | ||
| Estimated time | 80 hrs | ||
| Start date | 10 Nov 2006 | ||
| Status | Done for 3.2 by 22 Jan 2007 | ||
| Due for | NAV 3.2 and 3.3 |
the other for other attributes:
| Task id | T7 | ||
| Assigned to | Morten Brekkevold | ||
| Estimated time | 1 hrs | ||
| Start date | |||
| Status | |||
| Due for | NAV 3.2 |
| Task id | T8 | ||
| Assigned to | John Magne Bredal | ||
| Estimated time | 120 hrs | ||
| Start date | |||
| Status | |||
| Due for | NAV 3.2 |
| Task id | T9 | ||
| Assigned to | John Magne Bredal | ||
| Estimated time | 60 hrs | ||
| Start date | |||
| Status | |||
| Due for | NAV 3.2 |
| Task id | T12 | ||
| Assigned to | Stein Magnus Jodal | ||
| Estimated time | 120 hrs | ||
| Start date | 12 June 2006 | ||
| Status | Finished by 10 July 2006 | ||
| Due for | NAV 3.2 |
| Task id | T23 | ||
| Assigned to | Stein Magnus Jodal | ||
| Estimated time | 10 hrs (about 1 hour used) | ||
| Start date | 13 Oct 2006 | ||
| Status | Finished by 13 Oct 2006 | ||
| Due for | NAV 3.2 |