Add endpoint for the NetboxEntity model

[stveit]

Fixes #3378

Quick implementation of an endpoint for getting NetboxEntity data.

Filters can easily be expanded by adding more fields to filterset_fields.
The data you get out can be modified via the serializer. I've added an Inline serializer for device so you get the serialnumber directly for each entity since that will probably be useful for syncing to netbox. If you need more netbox data then that can be added as inline in a similar way

Added two simple tests. Not huge test coverage but will at least act as a blueprint to make more tests if needed

[github-actions]

Test results

   12 files     12 suites   11m 59s ⏱️
2 210 tests 2 210 ✅ 0 💤 0 ❌
6 105 runs  6 105 ✅ 0 💤 0 ❌

Results for commit b746445.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
2 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[johannaengland]

Looks good, just nitpicks

[lunkwill42]

Looks good to me. Just minimal doc nitpicks, methinks...

[lunkwill42]

Though, I must confess I'm not a fan of throwing around the magic numbers of entPhysicalClass outside of the NAV DB storage or MIB system.

I might be interested in having the NetboxEntity model updated to use a choice mapping for the field, so the MIB enumerations can easily be translated to symbolic names from the MIB, even in the API (I find it a bit weird that API clients would need to contend with the fact that chassis = 3).

It's hard for us to control whether the MIB is updated and adds new enumerations values, though, and I'm not sure if Django models can specify that a field is allowed to take integers we have no mapping for... any idea, @hmpf ?

[hmpf]

It's hard for us to control whether the MIB is updated and adds new enumerations values, though, and I'm not sure if Django models can specify that a field is allowed to take integers we have no mapping for... any idea, @hmpf ?

Not enough context. What's mapping to what? In Django there's hardcoded choices with IntegerField(choices=..), postgres has enums (and AFAIK there's no good wrapper for that in Django as of now) and SQL has lookup tables, but then you need to fill the table with new values all the time. Using a lookup table is the most braindead and safe answer if you expect new values. With Django you don't even need a foreign key but can use a validator that speaks manually to the table (bleah).

I don't have the context to know how many tables or if proxying would work or if any other data is needed per table.

[hmpf]

A lookup table can be (natural key=primary key, mappings*) or (primary key, natural key, mappings*), the latter would hide the actual magical number but the field would need its own index.

[hmpf]

On reload/restart of nav you could have something that looks up the magic number and its mappings in the relevant MIB(s) and alters the lookup table accordingly.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
2 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[johannaengland]

I'm happy, but leaving this in "Ready for Review" for @lunkwill42 or @hmpf for the entPhysicalClass details

[lunkwill42]

👍

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (f31f832) to head (b746445).
⚠️ Report is 115 commits behind head on master.

Additional details and impacted files

@@      Coverage Diff       @@
##   master   #3404   +/-   ##
==============================
==============================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lunkwill42]

A lookup table can be (natural key=primary key, mappings*) or (primary key, natural key, mappings*), the latter would hide the actual magical number but the field would need its own index.

Upon closer examination, I don't think we need the lookup table after all. We already have a value mapping in the Django Model field, NetboxEntity.physical_mapping - and apparently Django doesn't restrict the value to the set of defined choices.

We should probably modify the endpoint slightly to include also the human-readable name of the classifier, @stveit