Documentation: Developer best practices when building SSoT plugin

[FragmentedPacket]

Topics:

• Scoping of models loaded initially from both Nautobot and the remote system needs to match to avoid unintended creates/deletes
• naming patterns for Jobs?
• Adapter customization
• Limit x model
  • can become confusing because of dependency (such as it doesn’t make sense to sync Interfaces but not Devices, but it might make sense to sync Devices but not Interfaces)
• Limit x objects of a model
  • Figure out What filters to support
  • maybe using dynamic group

Adding @h4ndzdatm0ld and @glennmatthews for any further insight.

[chadell]

I would add also in this the need to properly communicate in ALL our SSoT plugins that they are not usable out-of-the-box for all the use-cases for an integration, some tuning would be needed until more customization is available. Not sure how to drive it yet

[chadell]

Adding testing best practices for models would help too. @Kircheneer is working on it right now, so we could add it as documentation but also as a testing for the current Job examples (lead by example!)

[Kircheneer]

Some documentation for job testing will be found in the Nautobot docs with 1.3 and also https://github.com/nautobot/nautobot/pull/1617

[Santhusha-bit]

Can I work on this issue?

[Kircheneer]

Can I work on this issue?

@Santhusha-bit yes - I am not currently doing any work here and its unassigned, so you should be good to go!

[Kircheneer]

Another item to consider could be performance profiling/optimization. Interesting items:

• How to structure queries for the Nautobot ORM adapter side so they are as fast as possible
• How to use the upcoming job CPU job profiling feature in Nautobot
• Using post_run to escape the atomic transaction

[Kircheneer]

That ⬆️ is done with #104