You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a very interesting project for me, who's currently in the discovery phase of implementing Netbox (or similar) into our environment.
I see us as using Netbox as a Source Of Truth. In other words, Netbox should determing the desired state of the environment, not merely reflect the current state of the environment, and all information that goes into Netbox must therefore be vetted to ensure that it's True.
But as the repository description already tells us:
The NetBox documentation makes it clear the tool is intended to act as a "Source of Truth". The automated import of live network state is strongly discouraged. While this is sound logic we've aimed to provide a middle-ground solution for those who desire the functionality.
On a first glance, this would seem to make Netbox-Sync unsuitable for our use in this scenario, but when I think about it a little more, I think there's still a useful place for Netbox-Sync in this kind of paradigm.
For initially populating information: Somehow all the pre-existing hardware information and virtual machines has to be input into Netbox. Netbox-Sync already does this by design, and as such it could be used, without modification, at least for initially populating the data. An administrator could then review the data input by Netbox-Sync and determine whether the data that has been inventoried represents a desired state, and change anything that doesn't look right to reflect an actual desired state.
For detecting differences between documentation and reality: It would be useful to be able to detect changes between the desired state (which would be Netbox) and the actual state (which would be gathered by Netbox-Sync from data sources such as Redfish or vSphere). From what I can tell in documentation, this can already be done by running Netbox-Sync as a "dry run" and then examining the output. This could be used to catch changes in hardware configuration, VM configuration, or similar, and would serve as a type of monitoring.
For reconciling documentation and reality: This is where Netbox-Sync is currently lacking (by design). As far as I can tell, there's no way to tell Netbox-Sync which changes that it wants to make into Netbox are actually valid, and reflect a true desired state. This leaves the administrator to have to manually edit the Netbox state to reflect the actual state to make those differences go away, or to run Netbox-Sync in a "wet" mode and change back anything that's wrong after reviewing the output. Neither option is great.
So my idea for a way to extend Netbox-Sync to allow it to be used in a Source of Truth paradigm would therefore be to add an option to Netbox-Sync which generates a machine-readable list of changes that Netbox-Sync wants to make to Netbox. The administrator would then go into that list of changes, and could then choose to approve specific changes, and thus act as a human gatekeeper for any data discovered by Netbox-Sync, and allow the human to decide what changes should go in or not.
(Another way to accomplish the same thing would be to add a "yes/no" query to every API call that performs a change, but I have a feeling that while that'd probably be easier to implement, it would detract significantly from ease of use.)
In this way, Netbox-Sync would fill two purposes: Monitoring the actual configuration and inventory, and alert the operator, and then allow the operator to optionally reconsile Netbox with reality.
So, my question is, before I dive too deep into this rabbit hole, is there any pre-existing work to use Netbox-Sync in a "Source of Truth" paradigm, or perhaps any other ideas to do something similar? Or is there something I've not considered?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello!
This is a very interesting project for me, who's currently in the discovery phase of implementing Netbox (or similar) into our environment.
I see us as using Netbox as a Source Of Truth. In other words, Netbox should determing the desired state of the environment, not merely reflect the current state of the environment, and all information that goes into Netbox must therefore be vetted to ensure that it's True.
But as the repository description already tells us:
On a first glance, this would seem to make Netbox-Sync unsuitable for our use in this scenario, but when I think about it a little more, I think there's still a useful place for Netbox-Sync in this kind of paradigm.
For initially populating information: Somehow all the pre-existing hardware information and virtual machines has to be input into Netbox. Netbox-Sync already does this by design, and as such it could be used, without modification, at least for initially populating the data. An administrator could then review the data input by Netbox-Sync and determine whether the data that has been inventoried represents a desired state, and change anything that doesn't look right to reflect an actual desired state.
For detecting differences between documentation and reality: It would be useful to be able to detect changes between the desired state (which would be Netbox) and the actual state (which would be gathered by Netbox-Sync from data sources such as Redfish or vSphere). From what I can tell in documentation, this can already be done by running Netbox-Sync as a "dry run" and then examining the output. This could be used to catch changes in hardware configuration, VM configuration, or similar, and would serve as a type of monitoring.
For reconciling documentation and reality: This is where Netbox-Sync is currently lacking (by design). As far as I can tell, there's no way to tell Netbox-Sync which changes that it wants to make into Netbox are actually valid, and reflect a true desired state. This leaves the administrator to have to manually edit the Netbox state to reflect the actual state to make those differences go away, or to run Netbox-Sync in a "wet" mode and change back anything that's wrong after reviewing the output. Neither option is great.
So my idea for a way to extend Netbox-Sync to allow it to be used in a Source of Truth paradigm would therefore be to add an option to Netbox-Sync which generates a machine-readable list of changes that Netbox-Sync wants to make to Netbox. The administrator would then go into that list of changes, and could then choose to approve specific changes, and thus act as a human gatekeeper for any data discovered by Netbox-Sync, and allow the human to decide what changes should go in or not.
(Another way to accomplish the same thing would be to add a "yes/no" query to every API call that performs a change, but I have a feeling that while that'd probably be easier to implement, it would detract significantly from ease of use.)
In this way, Netbox-Sync would fill two purposes: Monitoring the actual configuration and inventory, and alert the operator, and then allow the operator to optionally reconsile Netbox with reality.
So, my question is, before I dive too deep into this rabbit hole, is there any pre-existing work to use Netbox-Sync in a "Source of Truth" paradigm, or perhaps any other ideas to do something similar? Or is there something I've not considered?
Beta Was this translation helpful? Give feedback.
All reactions