Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transceivers should have their own class instead of counting as modules #1154

Closed
jmbredal opened this issue Jan 17, 2017 · 2 comments · Fixed by #2386
Closed

Transceivers should have their own class instead of counting as modules #1154

jmbredal opened this issue Jan 17, 2017 · 2 comments · Fixed by #2386
Assignees
Labels
enhancement nav-ref Fronted by the NAV user reference committee
Milestone

Comments

@jmbredal
Copy link
Collaborator

jmbredal commented Jan 17, 2017

Transceivers such as GBICs are classified in ENTITY-MIB::entPhysTable as modules, and are therefore detected by NAV as such. We've received a lot of feedback that transceivers do not quite fit with NAV's module concept. A suggestion is that Transceiver should be a new model in NAV, and be exempt from the typical moduleUp/down alerts that NAV generates. The rationale for this is that these units are plugged in and out at will and failures would be detected using other means.

A suggest way around this in the collection phase is to use the entPhysTable hierarchy to "see" that a transceiver module is connected to a port instead of a slot, and call this module a transceiver, rather than a module.

Conversely, with some vendors/models, modules may actually connect to ports, such the case is with FEX modules on the Cisco Nexus platform. How can we differentiate between the two? This will likely be a difficult balance to strike.


Imported from Launchpad using lp2gh.

@jmbredal jmbredal added nav-ref Fronted by the NAV user reference committee New labels Jan 17, 2017
@lunkwill42 lunkwill42 assigned stveit and johannaengland and unassigned stveit Mar 28, 2022
@lunkwill42
Copy link
Member

The essential code path to intervene in is in this method:

def _process_modules(self, entities):
# map entity indexes to module containers
module_containers = {}
modules = entities.get_modules()
for ent in modules:
entity_index = ent[0]
device = self._device_from_entity(ent)
module = self._module_from_entity(ent)
module.device = device
module_containers[entity_index] = module
self._logger.debug("module (entPhysIndex=%s): %r", entity_index, module)
return module_containers

A new method could be written to verify whether a module is a "proper" module or a transceiver, and filter out the transceiver ones.

@lunkwill42
Copy link
Member

Also, essentially, I think this issue can be split into two parts:

  1. Just stop classifying transceivers as modules
  2. Add a new classification system to NAV

Number 2 might not be necessary. I would defer that decision to nav-ref.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement nav-ref Fronted by the NAV user reference committee
Development

Successfully merging a pull request may close this issue.

4 participants