Isn't it hypocritical to say not to automatically import data from the network, but then release NetBox Discovery?

[deliciouslytyped]

The NetBox maintainers seem to take a strong stance against automatically importing data from the network, and also provide this as guidance. For example this is stated at: https://netboxlabs.com/docs/netbox/en/stable/introduction/ "As such, automated import of live network state is strongly discouraged." This point seems to be repeated across various issues and discussions over time in many places.

However then they go and release NetBox Discovery: https://netboxlabs.com/news/netbox-labs-announces-new-netbox-discovery-and-netbox-assurance-products/ .

Isn't that hypocritical? What am I missing here?

I personally am currently in the process of a greenfield deployment of DCIM tooling in a small legacy cluster that we don't currently have any cataloging for, and it's my job to get the (documentation) system bootstrapped. It would be helpful to have convenient tooling for getting the initial data into NetBox so that it can become a source of truth.

[beevek]

Hi! You derived (half of) the answer in your last point. Step one of implementing a source of truth is getting initial data into it. One of the most effective patterns we see in the wild is "establishing a baseline" from current operational state from which you shift to leveraging NetBox as source of truth, and that is one of the two key use cases of NetBox Discovery (what we call "Day 1" data ingestion). The other key use case is ongoing "Day 2+" visibility into operational/config drift - NetBox Discovery couples with NetBox Assurance (or if you don't want to use that, with your own processes/approaches) to help identify deviations from the intent in NetBox in the operational state of the infrastructure, so you can fix them.

Our recommendation remains to use NetBox as a source of truth for capturing intent, not a repository for operational state on an ongoing basis. The one pattern I'll mention that might feel like an exception but isn't is augmenting the intent in NetBox with additional "shared authority" data from adjacent systems (e.g. synchronizing some data from other sources of truth to augment information for which NetBox is authoritative, like additional metadata about devices from a CMDB, for example). This pattern can ensure NetBox's data is aligned with that of other sources of truth, enable more expedient use of NetBox as a source of truth for use cases like config generation, etc. That's a little far afield from NetBox Discovery but I wanted to mention it just for the avoidance of doubt regarding some other patterns we see in the wild that we think make sense.

[deliciouslytyped]

Thanks for replying! It may be nice to try to clarify this position in the standard NetBox documentation, and perhaps provide some guidelines for usecases of such adjacent tooling - in the main NetBox docs.