Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change of approach: use deterministic UUIDs for records imported into Nautobot #28

Merged
merged 6 commits into from
Apr 5, 2021

Conversation

glennmatthews
Copy link
Contributor

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. 😁

  • The ContentType model is automatically generated by Django, and we have no control over its primary-key values. So for ContentType records, we retain the old behavior of mapping NetBox to Nautobot based on natural keys for this model.
  • The 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.

@glennmatthews
Copy link
Contributor Author

CI build is failing due to the latest changes in nautobot/nautobot#208. I'll make the appropriate fix ASAP but all tests are passing locally with a Docker image built from an older version of that branch.

README.md Outdated Show resolved Hide resolved
Co-authored-by: Jathan McCollum <jathan@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants