Hi everyone,
for quite some time we've been aware of many fundamental problems with the way support for HP SwitchStacks has been implemented in NAV.
HP SwitchStack support was implemented in NAV 3.0 at NTNU, whose HP equipment consisted solely of HP SwitchStacks at that time. The result is code which is heavily biased towards SwitchStacks, to the point that NAV thinks HP devices are always SwitchStacks, no matter what.
While we have been pondering alternative ways to model HP SwitchStacks (and consequently, Cisco switch clusters, which are basically the same thing), NTNU has entirely stopped using SwitchStacks. Today, they're experiencing bad side effects of the existing HP-related code in NAV. They're using some HP devices for routing, which NAV cannot handle at all (because of said "HP=SwitchStack only" view). No router ports are collected for these routers. Also, they seem to have many errors in topology information when HP devices are involved.
Realizing that NTNU have stopped using SwitchStacks, we also do not know of anyone else who does, so now we are considering dropping support for SwitchStacks entirely from NAV. This way, the existing NAV code can treat HP devices like everything else. Preliminary tests of these changes at NTNU show promising results.
So my question to the users of NAV is: Does anyone actually use virtually stacked HP switches? Will anyone miss support for this if removed from NAV?
If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5.
Morten Brekkevold wrote:
Hi everyone,
for quite some time we've been aware of many fundamental problems with the way support for HP SwitchStacks has been implemented in NAV.
HP SwitchStack support was implemented in NAV 3.0 at NTNU, whose HP equipment consisted solely of HP SwitchStacks at that time. The result is code which is heavily biased towards SwitchStacks, to the point that NAV thinks HP devices are always SwitchStacks, no matter what.
While we have been pondering alternative ways to model HP SwitchStacks (and consequently, Cisco switch clusters, which are basically the same thing), NTNU has entirely stopped using SwitchStacks. Today, they're experiencing bad side effects of the existing HP-related code in NAV. They're using some HP devices for routing, which NAV cannot handle at all (because of said "HP=SwitchStack only" view). No router ports are collected for these routers. Also, they seem to have many errors in topology information when HP devices are involved.
Realizing that NTNU have stopped using SwitchStacks, we also do not know of anyone else who does, so now we are considering dropping support for SwitchStacks entirely from NAV. This way, the existing NAV code can treat HP devices like everything else. Preliminary tests of these changes at NTNU show promising results.
So my question to the users of NAV is: Does anyone actually use virtually stacked HP switches? Will anyone miss support for this if removed from NAV?
If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5.
I have not seen any feedback on the issue, so I guess another blueprint (or bug fix) for 3.5 should be committed by you, Morten!
- Vidar
On Tue, 09 Sep 2008 20:44:47 +0200 Vidar Faltinsen vidar.faltinsen@uninett.no wrote:
If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5.
I have not seen any feedback on the issue, so I guess another blueprint (or bug fix) for 3.5 should be committed by you, Morten!
Here it is: https://blueprints.launchpad.net/nav/+spec/remove-hp-switchstack-hack
On Tue, 09 Sep 2008 20:44:47 +0200 Vidar Faltinsen vidar.faltinsen@uninett.no wrote:
If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5.
I have not seen any feedback on the issue, so I guess another blueprint (or bug fix) for 3.5 should be committed by you, Morten!
Blueprint is posted here: https://blueprints.launchpad.net/nav/+spec/remove-hp-switchstack-hack
Just hope I have time to finish it in time for 3.5.