relocate and/or add SSoT to Extensibility navbar item

[jedelman8]

It is not intuitive to think that SSoT (Data Sources and Targets) would be under "Plugins". We have a DATA SOURCES section under "Extensibility." We should leverage that for each data source in SSoT.

Data Sources

• Git Repositories (already exists)
• ServiceNow
• IP Fabric
• Device42

Any enabled/configured SSoT source/target would show. As a byproduct, this helps showcase and brand data sources/targets.

Today, Git repositories is a data source for core functions, e.g. Jobs, Config Contexts, but could also be a target, e.g. Golden Config backups. So, if we want to be more nuanced, we should consider adding a Data Targets section under Extensibility (this is following current paradigms without introducing more menu items we way want in the future for Data Management). Otherwise, we can just call any integration a Data Source.

It may be for now the Dashboard/History/Logs stay where they are.

[jdrew82]

A few questions for this:

1. Would we consider this a breaking change? I might consider it one since it's moving where the information is in the UI so could be confusing to users.
2. We don't currently have any navigation/URL work done in the integrations. Those are all collected together in the SSoT dashboard automagically.

[jedelman8]

This is what I was thinking to add this in a first iteration:

• No change in the current UI (this is still a decent dashboard / central place that may work fine where it is for now not breaking any UI workflows and links)
• For each data source and target (each integration installed), a new entry is added to the Extensibility > Data Sources menu under Git Repositories
• Each new entry links to each direct page, e.g. in the case of infoblox /plugins/ssot/data-sources/plugins/nautobot_ssot.integrations.infoblox.jobs/InfobloxDataSource/

If we did this, I wouldn't think it'd be considered a breaking change as it is improving overall UX and discoverability.

Other thoughts as I alluded to earlier:

• I think what is above is a nice first step to improve UX
• Going forward, we need to see IF we need to rally around Data Sources (and then show directionality on the respective page) or we keep Data Targets longer term (data-sources and data-targets are currently in URLs). If we keep both longer term, we need to see if they should really be somewhere else in the navbar too. Personally, I like these to be in one menu section within the navbar for where it is so we don't add another section called Data Targets. If we break them out and have a top-level item for Data Management or some other name (moving it from Extensibility), having a sources and targets section could work. Again, I think this can happen iteratively. My 2c.

[Kircheneer]

Do we have any real-world use case for data targets with SSoT? I have not seen one so far.

[jedelman8]

Sure. Any data enrichment to a remote data source and any data Nautobot is the SoR for and sends to a target. They make sense but going back to UI, if the same tool as a source and a target, ideally it is not shown twice.

[jdrew82]

Do we have any real-world use case for data targets with SSoT? I have not seen one so far.

Infoblox and ServiceNow are the only integrations that I'm aware of that currently have a DataTarget pushing data from Nautobot to the other SoR.

Sure. Any data enrichment to a remote data source and any data Nautobot is the SoR for and sends to a target. They make sense but going back to UI, if the same tool as a source and a target, ideally it is not shown twice.

I would agree that we probably want to reduce duplication. Perhaps it might make more sense then to instead of calling the section DataSources, call it something like Systems of Record? If a SoR has both a Source and Target it'd need it's own page to allow you to choose which way the data is being transferred?

[jedelman8]

Not sure on the name change, but I believe there are more custom integrations to consider than just the ones in the repo.

[jdrew82]

Not sure on the name change, but I believe there are more custom integrations to consider than just the ones in the repo.

But we can only directly influence where these particular integrations are placed. The name change was more to allow the intention to be a more abstracted away from defining whether it's an import or export of data.