Change of approach: use deterministic UUIDs for records imported into Nautobot #28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #21
This is a change of data modeling approach to address the recurring issues caused by the fact that many NetBox data records can only be uniquely identified by their primary key and have no uniquely-identifiable natural key. Instead of relying on Nautobot to randomly allocate UUID primary keys to imported records (which makes it impossible for us to develop a consistent mapping between NetBox and Nautobot data records based on PK alone), we now deterministically generate UUIDs for any Nautobot records that we create as part of the import process, allowing us to identify NetBox records and their corresponding Nautobot records by PK alone.
Of course it's never quite that simple. 😁
ContentType
model is automatically generated by Django, and we have no control over its primary-key values. So forContentType
records, we retain the old behavior of mapping NetBox to Nautobot based on natural keys for this model.Group
model is a Django native model and so still uses integer primary keys. So we have to handle that case specially as well.But overall, this makes for a mostly simpler, definitely more robust approach.
Fixes #21, and should also fix #11, #19, #25, #26, #27 as well - I'll reach out to the submitters to verify each of these.
Also fixes #24.
Note: I've added a test case for re-running the sync a second time without any changes to the source data or the NetBox database, which helped me catch some errors in developing this changeset. Currently that test "passes" (as in it doesn't fail or error out) but it does log a number of warning and error messages during the process that I want to investigate and fix as a separate issue(s) and PR(s), as the resync case is not well-tested previously and demonstrably has some problems.