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

[bug/change] In Hierarchical View, Master Subnet show subordinate IPs as Available #114

Open
morganrallen opened this issue Sep 17, 2021 · 7 comments
Assignees
Labels
bug Something isn't working Hacktoberfest Easy issues for attracting Hacktoberfest participants.

Comments

@morganrallen
Copy link

First off this could just be my misunderstanding how this should be displayed, if so some clarification could be helpful anyhow.

I've got 3 subnets

  • 10.10.0.0/16 < master
  • | 10.10.0.0/24
  • | 10.10.1.0/24

image

Viewing from the top it looks like 100% of IPs are available. But coming into one of the subordinate subnets we can see that's not really the case.
image

So not sure what the behavior should be but my immediate feeling is, since this is a subnet hierarchy those should be considered unavailable. If this is correct I can probably take a crack at a patch, I'm hoping this will work out for an upcoming project.

@nemesifier
Copy link
Member

@morganrallen smells like a bug! Thanks for reporting.

@nemesifier nemesifier added the bug Something isn't working label Sep 18, 2021
@nemesifier nemesifier added this to To do (general) in OpenWISP Contributor's Board via automation Sep 18, 2021
@nemesifier nemesifier added this to Backlog in OpenWISP Priorities for next releases via automation Sep 18, 2021
@morganrallen
Copy link
Author

OK cool, I've even dug into this a bit and validating subordinate subnets going up the hierarchy is quite straight forward but ensuring an IP isn't used by a subordinate subnet was going to take a bit more.

@@ -244,9 +273,19 @@ class AbstractIpAddress(TimeStampedEditableModel):
             raise ValidationError(
                 {'ip_address': _('IP address does not belong to the subnet')}
             )
+
+        subnet_list = [self.subnet_id]
+
+        # traverse up the subnet list to gather id to check
+        if self.subnet.master_subnet is not None:
+            ms = self.subnet.master_subnet
+            while ms is not None:
+                subnet_list.append(ms.id)
+                ms = ms.master_subnet
+
         addresses = (
             load_model('openwisp_ipam', 'IpAddress')
-            .objects.filter(subnet=self.subnet_id)
+            .objects.filter(subnet__in=subnet_list)

@nemesifier
Copy link
Member

OK cool, I've even dug into this a bit and validating subordinate subnets going up the hierarchy is quite straight forward but ensuring an IP isn't used by a subordinate subnet was going to take a bit more.

@@ -244,9 +273,19 @@ class AbstractIpAddress(TimeStampedEditableModel):
             raise ValidationError(
                 {'ip_address': _('IP address does not belong to the subnet')}
             )
+
+        subnet_list = [self.subnet_id]
+
+        # traverse up the subnet list to gather id to check
+        if self.subnet.master_subnet is not None:
+            ms = self.subnet.master_subnet
+            while ms is not None:
+                subnet_list.append(ms.id)
+                ms = ms.master_subnet
+
         addresses = (
             load_model('openwisp_ipam', 'IpAddress')
-            .objects.filter(subnet=self.subnet_id)
+            .objects.filter(subnet__in=subnet_list)

Are you talking about validation now?
I thought we were talking about visualization. Can you please clarify your last statement?

@morganrallen
Copy link
Author

I was assuming if the visualization is incorrect than validation is also incorrect and the complete fix would be in multiple locations.

@nemesifier
Copy link
Member

nemesifier commented Sep 21, 2021

I was assuming if the visualization is incorrect than validation is also incorrect and the complete fix would be in multiple locations.

I see, but the logic for visualization and validation is not the same, we dealt recently with one of these issues: #87. if you find issues with validation please open a bug report like that one. In this issue we shall focus on visualization.

So, could you make it extremely clear what the expected outcome would be here?

I guess the expected outcome is that when visualizing the root subnet, we consider the space occupied in the child subnets as occupied also in the root/master subnets.

Right? Or do you have anything else in mind?

@morganrallen
Copy link
Author

I guess the expected outcome is that when visualizing the root subnet, we consider the space occupied in the child subnets as occupied also in the root/master subnets.

Yes, that captures it well. I'll open a separate issue if the IP validation is still an actual issue.

@nemesifier nemesifier added the Hacktoberfest Easy issues for attracting Hacktoberfest participants. label Sep 26, 2021
@pandafy pandafy moved this from To do (general) to To do (Python & Django) in OpenWISP Contributor's Board Sep 30, 2021
@pandafy pandafy added this to the Release 0.3.0 milestone Jan 26, 2022
@nemesifier nemesifier removed this from the Release 0.3.0 milestone Jan 31, 2022
@nemesifier
Copy link
Member

While further investigating this issue I found that another thing we could change is to expand the tree view in the master subnet by default, that is, show the tree instead of need to click on it as in the GIF below:

Peek 2022-11-03 15-24

@nemesifier nemesifier moved this from Backlog to To do in OpenWISP Priorities for next releases Nov 3, 2022
@nemesifier nemesifier changed the title In Hierarchical View, Master Subnet show subordinate IPs as Available [bug/change] In Hierarchical View, Master Subnet show subordinate IPs as Available Nov 3, 2022
@Aryamanz29 Aryamanz29 self-assigned this Dec 9, 2022
@nemesifier nemesifier moved this from To do (Python & Django) to To do (ansible/docker) in OpenWISP Contributor's Board Jan 23, 2023
@nemesifier nemesifier moved this from To do (ansible/docker) to To do (Python & Django) in OpenWISP Contributor's Board Jan 23, 2023
@nemesifier nemesifier moved this from To do to Backlog in OpenWISP Priorities for next releases May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Hacktoberfest Easy issues for attracting Hacktoberfest participants.
Projects
OpenWISP Contributor's Board
  
To do (Python & Django)
Development

No branches or pull requests

4 participants