search

nautobot / nautobot-app-ssot

Single Source of Truth for Nautobot
https://docs.nautobot.com/projects/ssot/en/latest/
Other
37 stars 38 forks source link

Filter source objects to diff #37

Open chadell opened 2 years ago

chadell commented 2 years ago

Proposed Functionality

By default, diffsync is executed for all the objects in the source and target adapted. We could apply filtering to only sync objects that match some criteria.

Filtering objects to execute diffsync could help to simplify some cases when only one or a few objects need to be evaluated for a sync.

Use Cases

As a network engineer, I would like to define filter criteria in the SSoT execution so the loading of objects in the source and destination datasets are restricted, and the whole process is narrowed down to a specific scope. For instance, Nautobot and an external Asset Management system contain 1000s of Sites/Location, but when a change on a specific one happens I would like to run the SSoT only for this location, from both the source and destination. So, the loading function should take into account the filtering for both adapters, and load only the related information. If the location contains Devices, and Devices contain Interfaces, I would only be interested on comparing this related data, leaving all the rest out of the comparison.

chadell commented 1 year ago

Consider Mappings implementation in servicenow-ssot as an idea to incorporate custom checks: table_query

Kircheneer commented 1 year ago

Possible implementation plan:

Provide a way to pass filters into an adapter per model that specifies which objects we are interested in. This could initially be enforced in $adapter.add, but also available as a field inside of the adapter for custom implementations to use in the load part prior to the add part. This usage in the load part would need to be documented well to communicate this to potential users.

Kircheneer commented 1 year ago

May also be worth exploring dynamic groups to achieve this behaviour on the Nautobot side. This would require more models to be supported with dynamic groups (https://github.com/nautobot/nautobot/issues/1822).

lampwins commented 1 year ago

I am finding this is commonly implemented via dynamic groups today (for the models that they support) in that a job input var is used to allow selection of a group and then that group's queryset is used by the adaptor.

Kircheneer commented 1 year ago

Relates to #229