Replies: 11 comments
-
|
Hi, thank you for your contribution. I guess, you're looking at it from the wrong side. The Plugin filters devices. In fact, you can use the same filter criteria in the "Devices" section in order to get a list of devices that whould be shown in the topology view. If you have not saved any device coordinates in a coords group, the device positions are calculated by a physics engine (vis-network in our case). Location boxes then follow this calculated icon positions. The boxes depend on device coordinates and nothing else. Your proposal would first filter locations, let a physics engine calculate the spreading of that boxes without any intersection and add device icons into the boxes after that. Since we use the device filter approach, we would have to re-think and rewrite the whole plugin (with all drawbacks of this approach). As you can think yourself, this won't happen. Personally I use it like that:
|
Beta Was this translation helpful? Give feedback.
-
|
OK... So... I have to eat a little crow here. I kept plugging away at this and re-read your reply multiple times thinking that I must be missing something here... and I was indeed. So, I apologize for not having caught this the first go around. (and hence why I deleted the previous comments) What happened is that I didn't have it set to save coordinates thinking at first this was with respect to GPS coordinates or something and not the Topology Views canvas rendering coordinates. So, with that fixed... now devices at least lock in place once they are moved and don't snap back like before. Also... After fiddling with what you stated about clicking and moving the box... I eventually figured out that after clicking the box you don't try to drag the box itself, but rather click on one of the devices within the box to move the collection of devices all at once (which in turn moves the box). I can now manually reposition them so that they don't overlap one another. And that alone is a HUGE victory. So, thank you. All that said... there's still the main issue at hand that prompted me to open this feature request... there is absolutely zero parent-child relationship for locations... or for sites... that are being represented. So, at present, the way the location boxes appear to be derived is simply if a device is within that location and a box is drawn around it. There's enough additional code to draw all devices that share the same location box into a single box. However, that's where the code appears to stop. So, what could/should be done to resolve this is to look if that location box has any parent locations associated to it and tally those up and draw all of them too. If multiple location boxes share the same parent... then the location boxes should be nested inside that parent box. Since this functionality already appears to be present in the sense that all location boxes for a site are grouped inside the site box (the same happens for multiple racks in a single location)... and the site box seems to dynamically resize to keep all child location boxes inside its boundaries (and the location box will resize to keep all the racks inside the box)... I don't anticipate that this would be a huge revamping of the code... just an extra recursive layer of searching for and combining any parent boxes. I say recursive only because I don't know of any limits at present for how many levels deep that locations are allowed to have a parent-child relationship with. I've already tested to 3 layers deep (building>Floor>room)... but, I don't know how far one can actually go before something breaks in NetBox. On a good note though.. Netbox does appear to honor a strict one to many relationship that does not allow for loops to be created (e.g. a grandchild being listed as the parent of it's grandparent). I've tested by trying to set the building location as having a parent of one of the rooms and when you click save it throws an error stating "Cannot assign self or child location as parent." That said... any recursive search function shouldn't find itself stuck in an endless loop. Technically... This same change could take place with sites and "site groups" too. But, an explicit option for "Group Site Groups" doesn't presently exits. To me, the option of "Group Sites" rather implies that site groups should therefore be rendered too IMHO. That said, I'm not sure if you would want me to take that up as an independent feature request or address that all here within this one? Your call I guess. |
Beta Was this translation helpful? Give feedback.
-
I agree that this is not intuitive. Problem is, that the drag function is part of the vis-network physics engine. The boxes itself are part of our own code. It wouldn't be impossible to implement an own drag function but I think that it would be tedious work for a relatively small benefit. But if someone would like to take work on it... Regarding your proposal: If I understand correctly you propose to add location boxes for parent locations. While I understand your intention, I don't find it logical. The logical way is to do it the other way round and that's how it is implemented. The same logic applies for devices in general. If you filter devices by location with a high level, all devices in nested locations will be included recursivly. Following your logic, we would filter devices by a child location and all devices in parent locations would be included. Obviously, that's not the case. Generally speaking I tend to follow the logical concepts of NetBox. The topology view should always be a visual equivalent of the textual display. Otherwise, we risk developing against NetBox, which may lead to incompatibilities and high programming effort. |
Beta Was this translation helpful? Give feedback.
-
|
I think you are perhaps misunderstanding the request. Maybe I'm stating it wrong? Or, maybe I'm the one mistaken on understanding how the current engine works to understand how this is some earth-shattering change. But, let's try this one more time. Here's a current situation.... I have a site ("Site A") that has a main office building ("Main Building") as well as a detached garage ("Garage") on the property. A location is created for both the Main Building and Garage. That Main Building location has a device that is assigned to it at that location level... for this example we'll say it's a piece of the ISP demark equipment or something that was bolted on the outside of the building. The building itself is a single-story building with a basement. So, a location was created for each floor as a child to the building location ("Basement" and "1st Floor"). In the Basement is another piece of ISP equipment... a fiber splice box or something that's bolted on the wall. Off in the corner of the basement, a small room is framed in and considered the main "IT Closet"... a location is created for that room and is a child location to the Basement location. In that room we have a UPS sitting on the floor and is thusly assigned to the room location. There's also a small 24U rack ("Rack") with all the building's IT equipment inside (firewall, switch, server, etc.). On the first floor, in the office conference room is a single Wi-Fi access point. That room is created as a location ("Conference Room") and is a child to the 1st Floor location. Circling back... that detached Garage is just one big open space, is a single floor, and has a Wi-Fi access point as well... which is simply assigned to the building location. To this point we would have the following structure and parent-child relationships:
So, I now run a query in Topology Views to show me all the equipment at that site and ask it to group sites, locations, and racks. Well... the way Topology Views is currently implemented... there would be a single red box for the site. So far so good. Inside that site would be multiple blue boxes for each Location that has a device assigned to that location. So, we would see a box for locations 1, 1(a), 1(a)(1), 1(b)(1), and 2.... 5 location boxes... even though there are actually 6 locations (more on that in a bit). These location boxes are drawn as their own independent boxes and do not show any relationship to one another. And there would be a single green box for the rack that is properly nested inside the IT closet (Location 1(a)(1)) box. If we move the equipment inside any of these location boxes around, the box itself will move to follow it... but, again, the location boxes themselves have no relationship to each other and will move independently of each other (this is undesirable). By contrast, if the equipment is moved far enough, the Site box will resize itself and scale as needed to contain all the location boxes inside (This is desirable). Similarly, if we move the equipment inside of the rack around, the rack box itself scales/resizes to ensure it contains all the equipment... AND... the location for the rack will also resize/scale to ensure the rack box stays within the location box (both of which are desirable behaviors). All that said, rather than the proper parent-child relationship as shown in the previous list above, you more or less end up with a rendering that has a hierarchy that looks like this...
What I'm asking for in this feature request is that similar to how the boxes for locations are clearly given a proper parent-child relationship to the site... and the equipment rack is clearly given a parent-child relationship to the location... please, Please, PLEASE honor the parent-child relationship for locations to each other. Start drawing location boxes inside of other location boxes if one location box is a child to the other. And if/when that box is resized, force the parent box to resize as needed to continue to contain that child box. Second on the wish list.... In the above example, the 1st Floor location box was never drawn because it did not contain any direct child devices... only a child location... the conference room... which incidentally had a valid device to be drawn. What I'm asking for is that if any locations are drawn because they contain a device... check to see if that location is a child to another location... and if so, draw that location too as a parent. What I am NOT asking for (at this time) is to simply draw every location available regardless of devices being drawn (i.e. drawing empty location boxes). I could see a use case for this. But, it's beyond the needs of the main point of this request. So... with all of that said... There's obviously pre-existing code that's in play for creating the parent-child relationship from Site to Locations... and I presume it's the same code that honors the parent-child relationships between locations and racks. So, just reuse that same code to enforce parent-child relationships from Locations to Locations. Second to that... there would be some new code that would need to be added that checks for the existence of a parent location and to draw said parent even if that parent is otherwise empty of devices that have been filtered for rendering. And, as the number of parents/grandparents/great-grandparents would be unknown... the search for parents would thus have to be a recursive search to identify and draw all parents up the chain/tree. This should only be an upward search for parent objects though. The only reason to look downward for child locations would be if you wish to enable additional functionality to draw empty locations (similar-ish to the option of saying you want to draw unconnected devices). In total, I don't see this being a monumental task. it should not require a huge amount of code, nor a complete re-work to how any existing features are implemented. This should reuse some of the existing code already in play for parent-child relationships. And, a small addition of code to identify parent locations that would otherwise have gone un-drawn. I also want to touch on something you stated in your response... " all devices in parent locations would be included" ... I'm NOT asking to have devices drawn that would have otherwise been filtered by the search simply because the location is being drawn. Far from it. I'm not asking for any additional devices to be drawn. Only that additional location boxes be drawn... and only if those locations are parents to other locations that are already being drawn because of the filtered devices. As an example of this using the above equipment scenario presented. Say we do a filter for that site to only show the Wi-Fi access points. The way Topology Views would currently render this would look as follows:
What I would expect instead with the proposed implementation would be as follows:
So, as you can see... the list of devices drawn stays unchanged. But, the parent-child relationship query would look upstream to the Conference Room location and subsequently draw the 1st Floor and Main Building location boxes in a nested manner that honors their relationships. Hopefully this is clearer on what I'm asking for. I don't believe what I'm asking for will in any way break or dishonor the structure of NetBox. If anything, I believe what I'm asking for is actually a more accurate representation of what NetBox has within its structure considering the parent-child relationship of locations is a native feature of NetBox. If anything... I would take up the position that the current implementation of Topology Views rendering of locations is a disservice to the native structure of NetBox as it ignores the parent-child relationship of locations. |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about the last paragraph in my previous comment... the fact that the current implementation of Topology Views does not honor the parent-child relationship of locations as a core implementation of the NetBox architecture. I'm half inclined to ask if the label for this thread could be changed from "Feature" to "Bug" instead. I'm not asking to implement something that's outside of the scope of core NetBox capability... to fabricate something new and unique to Topology Views as a "value add". I'm asking to fix an inaccurate representation of the core NetBox object relationships. Which... thinking about it... would really be a bug fix, would it not? |
Beta Was this translation helpful? Give feedback.
-
|
Wow, that's a... errr... huge text... :-) A few screenshots would have helped a lot more. I created the mentioned locations and devices in my dev environment and this is what it looks like: Locations, filtered by Site A: The device list shows all information we have got to work with. Again, we don't (and don't intend to) draw a hierachical view of locations. Instead we just draw devices. The grouping functions just group devices that belong to the exact same location.
And I'm half inclined to convert this thread into a discussion. You think that your point of view is correct. I don't. It's definitely not a bug, because it works as intended.
If upstream supports your point of view and changes the representation, we will follow. |
Beta Was this translation helpful? Give feedback.
-
Sorry. I have a propensity to be verbose. It's a curse.
To that end... and even by your own screenshots... Topology Views are not honoring the visual text display since the locations themselves within the list are honoring a parent-child hierarchy. (see below screen shot with the single and double dots indenting the location name to indicate that it is a child item. For what it's worth... this same indent technique is used under Site Groups as well.... which Topology Views also doesn't represent/depict.).
Topology Views at present only partially honors the full hierarchy within Netbox. It honors the fact that the locations belong to a site... and it honors the fact that racks belong to a location. But, it does not honor that locations have a parent-child relationship too. As for a picture "to tell a thousand words"... after fiddling around a bit in Photoshop, I mashed together something that resembles what it would/could/should look like if the parent-child hierarchy is fully honored...
granted... placement in the objects in the picture isn't fantastic. This isn't an art contest after all. ;) I just quickly mashed that together. The point is though... visually... it is an accurate representation of the hierarchical structure of Sites>Locations>Racks with a full representation of the parent-child relationships of all the locations. And... Since it's been mentioned more than once... and you wanted pictures... Here goes as it comes to Site Groups... which suffers from the same issue as Locations. Here's a test I created of Site Groups and associated test sites....
Please take note of the fact that Site Groups use the very same dot notation in front of their name to indicate a nested parent-child relationship/hierarchy. Now... going into Topology Views and asking it to show the site group "Major University" and to "Group Sites" dumps out just a non-relationship rendering of the sites...
I tried to keep the above image as clean and simple as I could by only adding a single device at a site without any locations or racks. I trust you can let your imagination fill in the details of having much more inside each site box. Using some PhotoShop magic... this is what the render would/should/could look like if the Site Group hierarchy would have been honored...
I only bother to mention the Site Groups part here because I can only presume that whatever the fix for Locations will be a very similar if not identical fix for Site Groups.
Point me to whomever you wish and I will gladly state my case to them. Although... I would like to point out the part about "...changes the representation..." and "The topology view should always be a visual equivalent of the textual display.".... I think it has already been established with the screenshots (that even you yourself provided) showing that the indented dots in the list represent a child status. So... <shrug>... Let me know how you want to proceed. Again... I'm happy to talk to whomever is needed to set this straight. |
Beta Was this translation helpful? Give feedback.
-
|
Just a little something extra... In addition to the dot notation in the text view of the site groups... take note of the number of sites listed for each site group. The numbers shown add up to their respective parent in that list. Which in its own way is further reinforcement of the parent-child relationship hierarchy that exists. Running through the math.... So Cal (3) + No Cal (2) = Cal Schools (5)... and Cal (5) + Flor (2) + NY (1) = Maj Univ (8). The same happens in the list of Locations and device count. But it's a bit tricky since some devices are assigned directly to a location in addition to the devices located in child locations under that specific location. But... if you look at your table of locations, and then look at my PhotoShop representation of how it could/should be drawn... the numbers in that table add up exactly as shown. For example... the IT Closet is showing 4 devices... the UPS directly assigned to the location plus the 3 devices in the rack. The Basement location shows 5 devices... the 4 in the IT closet plus the one Fiber Splice Box device assigned directly to the Basement location. So on and so on until you get to the site level for a total of 8 devices for the site (1 in the garage and 7 in the main building). So... as it pertains to your previous statement of
I think that the mathematical summaries as textually displayed is just one extra reason why nested location and site boxes need to be drawn to accurately represent the true parent-child hierarchy relationships as depicted in the text displays for both Locations and Site Groups. The addition of these boxes will show the nature of how these numbers are derived. |
Beta Was this translation helpful? Give feedback.
-
^^^ |
Beta Was this translation helpful? Give feedback.
-
|
If you won't fix it... then you may as well remove the function that draws the boxes all together since in its current form it is a misleading/incomplete (arguably incorrect) representation. Furthermore, without digging too deep, I've noticed other feature requests that have already been submitted that echo essentially this same request for parent/child relationships to be honored (of which they were arbitrarily closed). So, it's not like I'm the only one who's a) taken notice of this and b) taken the time to submit a request for it. I'm just (by the looks of it) the only one who's been persistent enough to repeatedly poke you over and over and over about it. #poke-poke 😉 If it helps motivate you... I'll gladly PayPal you a $100 bounty to implement it as requested. I'm not above remunerating for someone's work. I'm well aware that fee doesn't mean free lunch. For that matter... I would be happy to do it myself if 1) I was not so rusty in coding Python, 2) I had a more thorough grasp on the current code base as it is implemented. But, by time I deal with getting up to speed I will have easily spent 10x as much time as you would have in implementing the solution. And, what I implement would very likely not be as clean as your code implementation. (#FrankenCode) Heck... if my skills were focused in this area, my hunch is that in the time that's been already spent going back and forth about this request, I would have been able to implement it myself. But, alas, my skills are honed in other areas of IT. So... Again... I'm happy to pay a bounty... or horse-trade for something if that's more your preference. Your call. 💰or 🐎? |
Beta Was this translation helpful? Give feedback.
-
|
You completely get me wrong again and again. My intention is not monetary. My intention is not to annoy you either. My intention is that I think I'm right. None of your arguments have changed that. I contribute to this project in my spare time without getting any money, just because I like it like that. Open source is great. I like open source so much because it makes you independent. Independent of developers who do everything wrong, for example. And here's the good news: You could fork this plugin and change anything you dislike. Or you let others do that and pay them. Perhaps many people find your version much better and you're even doing them a favour. I might even be one of them myself one day. That's completely okay because that's what open source is about. The only thing you can't do is dictate your rules to this project. |
Beta Was this translation helpful? Give feedback.
-
NetBox version
v4.07
Topology Views version
v4.0
Feature type
Change to existing functionality
Proposed functionality
At present, if you select to group by location, the boxes that are drawn
That said....
Use case
As an example, a site has a 3-story building with a parent location created for each floor and child locations created for each room on those floors. We'll say that devices are placed only in the individual rooms. With that said, when the topology is drawn with location boxes, there should be a location box for each floor (that does not overlap with any of the other boxes for the other floors), and child location boxes for each room (not overlapping one another), and then the devices inside of each room (assuming the room even has a device... don't draw a location if the location has no devices or child locations with devices).
External dependencies
None
Beta Was this translation helpful? Give feedback.
All reactions