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

Unused NetworkPort isn't unset when NetworkInventory is executed #536

Closed
eduardomozart opened this issue Jul 30, 2024 · 7 comments
Closed
Labels

Comments

@eduardomozart
Copy link
Contributor

Describe the bug

Hello,
An Aruba Instant AP (IAP) Cluster contains a VIP (Virtual IP Address) that is shared among the APs that belongs to the same cluster. Only one AP can assume this AP, but if it's Down, another AP assumes it. This IP is used to manage the cluster. During tests to PR #524, I noticed that when this VIP moves between the cluster, the GLPI isn't correctly updated to reflect this change, even if NetInventory file reflect those changes. VIP is "192.168.0.6" in my environment.

To reproduce

  1. AP01 is the AP that holds the VIP (192.168.0.6). Do a NetInventory task on it, the following is inventoried in the AP01 NetworkPorts: image
  2. AP01 is Down, now AP02 is inventoried and assumes the VIP (192.168.0.6), and NetInventory task reflect this change as expected. image
  3. When AP01 is Up, it reassumes the VIP (192.168.0.6), but even when running NetInventory, the AP02 still shows as holding the IP "192.168.0.6", but it's not, and this change is reflected on NetInventory file.

Expected behavior

The VIP 192.168.0.6 should belong only to one AP instead of two. I believe that what's happening is that NetworkPorts inventory doesn't remove unused ports from NetInventory task, so when a network interface/port is removed, it isn't removed from the asset, so I'm not sure if it's a bug from this plug-in or GLPI core itself (I believe the problem is into the core).

Operating system

Windows

GLPI Agent version

Other (See additional context below)

GLPI version

Other (See additional context below)

GLPIInventory plugin

1.3.5

Additional context

GLPI agent: 1.10
GLPI version: 10.0.16

I noticed that NetDiscovery task doesn't report the VIP (192.168.0.6), but I believe it's only gathered when running SNMP on APs (no problem).

Here's the inventory files:
networkequipment_0_11.xml.txt
networkequipment_0_10.xml.txt

Here's the NetInventory files:
networkinventory_0_11.xml.txt
networkinventory_0_10.xml.txt

@eduardomozart eduardomozart added the bug Something isn't working label Jul 30, 2024
@trasher trasher removed the bug Something isn't working label Jul 31, 2024
@trasher
Copy link
Collaborator

trasher commented Jul 31, 2024

That's not a bug, rather a missing feature.

@trasher
Copy link
Collaborator

trasher commented Jul 31, 2024

Please provide example inventory files so I can take a deeper look.

@eduardomozart
Copy link
Contributor Author

It seems like a bug for me. The NetworkPort relation of the device should be cleanup and replaced by the inventory file, except if they were added by the user. The inventory files and NetInventory files are in the "Additional context" section.

@trasher
Copy link
Collaborator

trasher commented Jul 31, 2024

Thanks for the files, I did not pay attention.

No, that's not a bug, such a thing has never been implemented (even in the old plugin).
I'll take a look, but network ports management is not something easy to change: if that require too much work, I'll not work on it.

Copy link

There has been no activity on this issue for some time and therefore it is considered stale and will be closed automatically in 7 days.

If this issue is related to a bug, please try to reproduce on latest release. If the problem persist, feel free to add a comment to revive this issue.

You may also consider taking a subscription to get professionnal support or contact GLPI editor team directly.

@github-actions github-actions bot added the Stale label Sep 30, 2024
@eduardomozart
Copy link
Contributor Author

Just commenting to not let this issue be closed by GitHub bot.

@github-actions github-actions bot removed the Stale label Oct 1, 2024
Copy link

github-actions bot commented Dec 1, 2024

There has been no activity on this issue for some time and therefore it is considered stale and will be closed automatically in 7 days.

If this issue is related to a bug, please try to reproduce on latest release. If the problem persist, feel free to add a comment to revive this issue.

You may also consider taking a subscription to get professionnal support or contact GLPI editor team directly.

@github-actions github-actions bot added the Stale label Dec 1, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants