Deprecate topology maps feature #2259

@DanSheps commented on GitHub (Jan 4, 2019):

@snowie-swe, I don't think device groups are the answer to the problem you are trying to solve as that is already covered under:

Sites/Rack Groups
or
Device Types

@DanSheps commented on GitHub (Jan 4, 2019): @snowie-swe, I don't think device groups are the answer to the problem you are trying to solve as that is already covered under: Sites/Rack Groups or Device Types

adam commented

@jeremystretch commented on GitHub (Jan 4, 2019):

Please keep comments on-topic.

@jeremystretch commented on GitHub (Jan 4, 2019): Please keep comments on-topic.

adam commented

@tb-killa commented on GitHub (Jan 5, 2019):

Please provide (easier) API endpoint(s) for external applications to generate their own topology maps using data sourced from NetBox.

@tb-killa commented on GitHub (Jan 5, 2019): Please provide (easier) API endpoint(s) for external applications to generate their own topology maps using data sourced from NetBox.

adam commented

@hhsn commented on GitHub (Jan 6, 2019):

@jeremystretch
please don't remove this feature unless there is better replacement as Netbox user the "topology maps" feature with all issue exist still can help us to trace and understand some issues.

Thanks.

@hhsn commented on GitHub (Jan 6, 2019): @jeremystretch please don't remove this feature unless there is better replacement as Netbox user the "topology maps" feature with all issue exist still can help us to trace and understand some issues. Thanks.

adam commented

@kopacko commented on GitHub (Jan 8, 2019):

Please do NOT remove the topology function. It may be a pain but has a very clear and concise use. If it cannot be updated until later on down the road, so be it. But removing it entirely would be detrimental to many of my clients of whom I have converted to Netbox.

@kopacko commented on GitHub (Jan 8, 2019): Please do NOT remove the topology function. It may be a pain but has a very clear and concise use. If it cannot be updated until later on down the road, so be it. But removing it entirely would be detrimental to many of my clients of whom I have converted to Netbox.

adam commented

@jeremystretch commented on GitHub (Jan 8, 2019):

If it cannot be updated until later on down the road, so be it.

This is one of the points identified above. It's not going to be improved, at any point, because it's not a primary focus of NetBox development.

@jeremystretch commented on GitHub (Jan 8, 2019): > If it cannot be updated until later on down the road, so be it. This is one of the points identified above. It's not going to be improved, at any point, because it's not a primary focus of NetBox development.

adam commented

@hhsn commented on GitHub (Jan 9, 2019):

If it cannot be updated until later on down the road, so be it.

This is one of the points identified above. It's not going to be improved, at any point, because it's not a primary focus of NetBox development.

we would like to know if there other tools can render topology based on netbox information.

@hhsn commented on GitHub (Jan 9, 2019): > > > > If it cannot be updated until later on down the road, so be it. > > This is one of the points identified above. It's not going to be improved, at any point, because it's not a primary focus of NetBox development. we would like to know if there other tools can render topology based on netbox information.

adam commented

@TheNetworkGuy commented on GitHub (Jan 9, 2019):

If it cannot be updated until later on down the road, so be it.

This is one of the points identified above. It's not going to be improved, at any point, because it's not a primary focus of NetBox development.

we would like to know if there other tools can render topology based on netbox information.

Using the Netbox API to render maps shouldn't be that difficult. In its most simplest form just query all cables / devices and link them together in a HTML page using something like Graphviz.

@TheNetworkGuy commented on GitHub (Jan 9, 2019): > > > If it cannot be updated until later on down the road, so be it. > > > > > > This is one of the points identified above. It's not going to be improved, at any point, because it's not a primary focus of NetBox development. > > we would like to know if there other tools can render topology based on netbox information. Using the Netbox API to render maps shouldn't be that difficult. In its most simplest form just query all cables / devices and link them together in a HTML page using something like Graphviz.

adam commented

@tb-killa commented on GitHub (Jan 10, 2019):

@jeremystretch : What about replacing the Deprecate topology maps feature in detail "Graphviz" with the JS based site topology map (#1827) ? This would allow to work without external dependencys and doesnt need special configurations.

@tb-killa commented on GitHub (Jan 10, 2019): @jeremystretch : What about replacing the Deprecate topology maps feature in detail "Graphviz" with the JS based site topology map (#1827) ? This would allow to work without external dependencys and doesnt need special configurations.

adam commented

@DanSheps commented on GitHub (Jan 10, 2019):

@tb-killa That still adds development overhead to Jeremy and John, the primary maintainers, which is what they are trying to limit.

@DanSheps commented on GitHub (Jan 10, 2019): @tb-killa That still adds development overhead to Jeremy and John, the primary maintainers, which is what they are trying to limit.

adam commented

@tb-killa commented on GitHub (Jan 10, 2019):

@DanSheps Yes this will adds first development overhead but i think if graphviz is removed and the replacement with "vis.js" is implemented we can stay with it. The Problem with Graphviz are multiple sourced .. first the dependencys and second the configurations for generate the "maps".
Here the Users could do stupid stuff while "code" the result.

I think netbox should remove graphviz but allow simple connection drawing (connection-shower) inside the gui themselve to get a simple overview.
At this "vis.js" implementation like mentioned before would be the best, because here you doesnt could configure .. only show actually connections in nice looking and movable Art.

I agree that the completed #1827 Implementation are overheaded and i´m not the fan of this "add device" stuff implemented by this addon.

@tb-killa commented on GitHub (Jan 10, 2019): @DanSheps Yes this will adds first development overhead but i think if graphviz is removed and the replacement with "vis.js" is implemented we can stay with it. The Problem with Graphviz are multiple sourced .. first the dependencys and second the configurations for generate the "maps". Here the Users could do stupid stuff while "code" the result. I think netbox should remove graphviz but allow simple connection drawing (connection-shower) inside the gui themselve to get a simple overview. At this "vis.js" implementation like mentioned before would be the best, because here you doesnt could configure .. only show actually connections in nice looking and movable Art. I agree that the completed #1827 Implementation are overheaded and i´m not the fan of this "add device" stuff implemented by this addon.

adam commented

@jeremystretch commented on GitHub (Jan 10, 2019):

replacement with "vis.js"

conflicts with

The core maintainers don't have the time or interest in developing the feature any further.

I don't want to speak for John, but I won't be committing any more effort to the feature.

@jeremystretch commented on GitHub (Jan 10, 2019): > replacement with "vis.js" conflicts with > 4. The core maintainers don't have the time or interest in developing the feature any further. I don't want to speak for John, but I won't be committing any more effort to the feature.

adam commented

@sleeplessnight2 commented on GitHub (Jan 18, 2019):

Please do NOT remove the topology function. It may be a pain but has a very clear and concise use. If it cannot be updated until later on down the road, so be it. But removing it entirely would be detrimental to many of my clients of whom I have converted to Netbox.

I got the same opinion. You do not need to develop it, but do not remove it.

If those little "non-core bonuses" were, where would it be - apart from the design - a difference to the other alternatives?

Often it is the small extras that make a system particularly valuable. Everyone can do "simple"...

@sleeplessnight2 commented on GitHub (Jan 18, 2019): > Please do NOT remove the topology function. It may be a pain but has a very clear and concise use. If it cannot be updated until later on down the road, so be it. But removing it entirely would be detrimental to many of my clients of whom I have converted to Netbox. I got the same opinion. You do not need to develop it, but do not remove it. If those little "non-core bonuses" were, where would it be - apart from the design - a difference to the other alternatives? Often it is the small extras that make a system particularly valuable. Everyone can do "simple"...

adam commented

@DanSheps commented on GitHub (Jan 22, 2019):

What if this module was deprecated over the next few major releases, so there is an understanding that this won't be developed further. That would give the community time to develop a replacement.

@DanSheps commented on GitHub (Jan 22, 2019): What if this module was deprecated over the next few major releases, so there is an understanding that this won't be developed further. That would give the community time to develop a replacement.

adam commented

@tb-killa commented on GitHub (Feb 21, 2019):

I would prefer if this is implemented :
https://github.com/digitalocean/netbox/issues/969

you could remove this graphviz stuff because we could build URLs with device informations and let the own application external get via API the needing informations to draw or render the needing visuals.

@tb-killa commented on GitHub (Feb 21, 2019): I would prefer if this is implemented : https://github.com/digitalocean/netbox/issues/969 you could remove this graphviz stuff because we could build URLs with device informations and let the own application external get via API the needing informations to draw or render the needing visuals.

adam commented

@dgomes87 commented on GitHub (Mar 12, 2019):

While I agree it could use some work, but that developing it further doesn't seem ideal, I disagree with removing it in the near future. As you mention in points 5 and 6 a dedicated app, and ideally fed through the API, would be ideal. The issue is, is there such an app, easily accessible to users of netbox who are not developers? For example in my organization we're all just a bunch of datacenter technicians, we don't do in-house development, messing with the API and finding or developing a third party app to replace a feature that already exists in netbox (as basic as it may be) is not at all in our job descriptions and the time will never be allocated/approved to doing so. I would be curious how many other organizations are in the same boat.

I think this is the kind of scenario where a system for plugins would be justified, to allow people to develop and easily distribute functionality for netbox without having issues every time there is an update.

@dgomes87 commented on GitHub (Mar 12, 2019): While I agree it could use some work, but that developing it further doesn't seem ideal, I disagree with removing it in the near future. As you mention in points 5 and 6 a dedicated app, and ideally fed through the API, would be ideal. The issue is, is there such an app, easily accessible to users of netbox who are not developers? For example in my organization we're all just a bunch of datacenter technicians, we don't do in-house development, messing with the API and finding or developing a third party app to replace a feature that already exists in netbox (as basic as it may be) is not at all in our job descriptions and the time will never be allocated/approved to doing so. I would be curious how many other organizations are in the same boat. I think this is the kind of scenario where a system for plugins would be justified, to allow people to develop and easily distribute functionality for netbox without having issues every time there is an update.

adam commented

@fernandolcx commented on GitHub (May 19, 2019):

LibreNMS has a VERY NICE topology map feature.

@fernandolcx commented on GitHub (May 19, 2019): LibreNMS has a VERY NICE topology map feature. ![image](https://user-images.githubusercontent.com/38504809/57984182-a150f600-7a2f-11e9-9ca8-d4be50fba276.png)

adam commented

@aaroneg commented on GitHub (Jun 20, 2019):

I agree, for what it's worth. If it's not a feature that will be fleshed out fully, it should be dropped.

@aaroneg commented on GitHub (Jun 20, 2019): I agree, for what it's worth. If it's not a feature that will be fleshed out fully, it should be dropped.

adam commented

@hellerve commented on GitHub (Jul 23, 2019):

Is it reasonable to assume that this could be realized through a plugin as described by #3351?

@hellerve commented on GitHub (Jul 23, 2019): Is it reasonable to assume that this could be realized through a plugin as described by #3351?

adam commented

@jeremystretch commented on GitHub (Jul 23, 2019):

@hellerve Sure, seems like an ideal use case for a plugin.

@jeremystretch commented on GitHub (Jul 23, 2019): @hellerve Sure, seems like an ideal use case for a plugin.

adam commented

@hellerve commented on GitHub (Jul 23, 2019):

@jeremystretch That sounds great and like it could alleviate some of the community pains of this feature getting dropped :)

@hellerve commented on GitHub (Jul 23, 2019): @jeremystretch That sounds great and like it could alleviate some of the community pains of this feature getting dropped :)

adam commented

@tamatsuna commented on GitHub (Dec 6, 2019):

It is convenient to be able to use this easily.
https://github.com/codeout/inet-henge

@tamatsuna commented on GitHub (Dec 6, 2019): It is convenient to be able to use this easily. https://github.com/codeout/inet-henge

adam commented