Add a new vis_augmenter plugin

[ohltyler]

Signed-off-by: Tyler Ohlsen ohltyler@amazon.com

Description

Adds a new vis_augmenter plugin which will maintain & support different interfaces & types related to plugin integration projects, such as the to-be-renamed 'Feature Anywhere' project. Details on the purpose & responsibilities of this new plugin can be found in the issue.

This PR only sets up the boilerplate code for the new plugin. The additions of the new saved object type and expression function types will be added in later PRs. Breaking it up for readability purposes.

Issues Resolved

Closes #2958

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[kristenTian]

Reminder to update changelog.md so the check passes - Discard this, didn't notice it's feature branch.

[ohltyler]

Reminder to update changelog.md so the check passes

What's the strategy for this for PRs into feature branches? Should it be added to the Unreleased section? And even so, I could imagine a lot of merge conflicts when trying to finally merge this branch into main and subsequently 2.x.

[ohltyler]

@kavilla @joshuarrrr @kristenTian let me know if you have concerns for the name of this plugin. My goal is to have a generic enough name such that this plugin can be used for supporting the ongoing integrations (AD/alerting with visualizations, AD forecasting with visualizations) + future integrations.

I was thinking visualization_plugin_integration or visualization_integration at first, but I figure we may have future integrations potentially with other saved objects, like Dashboards.

[kristenTian]

@kavilla @joshuarrrr @kristenTian let me know if you have concerns for the name of this plugin. My goal is to have a generic enough name such that this plugin can be used for supporting the ongoing integrations (AD/alerting with visualizations, AD forecasting with visualizations) + future integrations.

I was thinking visualization_plugin_integration or visualization_integration at first, but I figure we may have future integrations potentially with other saved objects, like Dashboards.

Do you foreseen plugins other than AD/alerting can also be benefiting from this work? For example ISM or security, or would this just be extended usage for Analytics Plugins?

[ohltyler]

@kavilla @joshuarrrr @kristenTian let me know if you have concerns for the name of this plugin. My goal is to have a generic enough name such that this plugin can be used for supporting the ongoing integrations (AD/alerting with visualizations, AD forecasting with visualizations) + future integrations.
I was thinking visualization_plugin_integration or visualization_integration at first, but I figure we may have future integrations potentially with other saved objects, like Dashboards.

Do you foreseen plugins other than AD/alerting can also be benefiting from this work? For example ISM or security, or would this just be extended usage for Analytics Plugins?

I could see potential with ML commons, such as showing model results on top of visualizations or dashboards. Essentially, I want to avoid having a narrowly-scoped name which would be changed to something more generic in the future, since plugin renaming could cause lots of headaches regarding upgrades, BWC compatibility, etc.

At a high level, this is setting up a framework to persist relationships from arbitrary plugin resources to arbitrary saved objects, as well as how to append or augment data for those saved objects

[joshuarrrr]

Reminder to update changelog.md so the check passes

What's the strategy for this for PRs into feature branches? Should it be added to the Unreleased section? And even so, I could imagine a lot of merge conflicts when trying to finally merge this branch into main and subsequently 2.x.

I'd argue that it doesn't make sense to update the CHANGELOG for feature branch development, and that we can add thoughtful CHANGELOG items when merging the feature branch to main. So my vote would be to just use the Skip-Changelog label for now, and to update the workflow to not include CHANGELOG checks on feature branches.

[ohltyler]

After speaking with @joshuarrrr we've come to agreement to rename this to vis_augmenter. It’s worth keeping it vis-centric rather than too generic, and a little more descriptive in what our feature actually does, which is augmenting a vis rather than simply linking it. Also it will be better to avoid plugin in the plugin name itself since that could cause confusion in what the plugin's purpose is.

[ohltyler]

I'm going to keep #3108 as a standalone PR. I'll rebase it after this is merged; it will be a quick follow-up.

[codecov-commenter]

Codecov Report

Merging #3107 (241c133) into feature/feature-anywhere (808129b) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@                     Coverage Diff                      @@
##           feature/feature-anywhere    #3107      +/-   ##
============================================================
- Coverage                     66.67%   66.67%   -0.01%     
============================================================
  Files                          3219     3219              
  Lines                         61450    61450              
  Branches                       9417     9417              
============================================================
- Hits                          40973    40969       -4     
- Misses                        18232    18234       +2     
- Partials                       2245     2247       +2     

Impacted Files	Coverage Δ
...ic/application/models/sense_editor/sense_editor.ts	64.00% <0.00%> (-1.78%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.