Remove HP SwitchStack support from NAV
getDeviceData implements a low-level hack for HP devices, causing modified swport ifIndices to be stored in the database for all HP devices. In effect, gDD assumes ALL HP devices are HP SwitchStacks, which causes all sorts of HP related problems for the rest of NAV. HP SwitchStacks seem to be rarely used nowadays, so we should remove support for them to restore proper handling of HP devices in NAV.
Blueprint information
- Status:
- Complete
- Approver:
- Morten Brekkevold
- Priority:
- High
- Drafter:
- Morten Brekkevold
- Direction:
- Approved
- Assignee:
- Morten Brekkevold
- Definition:
- Approved
- Series goal:
- Accepted for 3.5
- Implementation:
- Implemented
- Milestone target:
- v3.5.0b2
- Started by
- Morten Brekkevold
- Completed by
- Stein Magnus Jodal
Related branches
Related bugs
Sprints
Whiteboard
This blueprint was triggered by many HP-related problems experienced at NTNU. They lack proper topology information for several HP switches, and are unable to get NAV to produce any meaningful information about HP routers. NTNU have split up all their HP SwitchStacks because of other management problems, so the SwitchStack support is no longer critical for them. None have come forward asking to keep this support since the question of removal was posted on the nav-users mailing list.
A series of changesets to remove the broken HP support has been committed. These have been tested on NTNU's development NAV server, as NTNU has a lot of HP equipment and HP topology problems.
The patches remove any special module-related treatment of HP as a vendor in the SimpleSnmp library, the getDeviceData daemon and other parts of NAV that attempt to obey NAV's HP ifIndex hack by doing ifIndex computions for HP devices (such as arnold, makecricketconfig and snmptrad's linkupdown plugin).
A migration strategy for old data is necessary. Most likely, the only feasible way to do this is to delete all modules from HP equipment and let getDeviceData discover it all over again.