[BUG] Names don't adhere to plugin naming convention

[dblock]

What is the bug?

We have published a plugins naming convention to https://github.com/opensearch-project/opensearch-plugins/blob/main/CONVENTIONS.md#plugin-naming-conventions in #56, but are failing to adhere to these consistently

• index-management-dashboards-plugin
• observability
• security-analytics-dashboards-plugin
• security-dashboards-plugin
• dashboards-maps
• dashboards-visualizations
  ...

What is the expected behavior?

Plugins follow the convention.

1. Evaluate and publish the delta.
2. Update contentions if needed.
3. Align all names to the convention.

• [BUG] Repo name doesn't adhere to plugins naming convention index-management-dashboards-plugin#415
• [BUG] Repo name doesn't adhere to plugins naming convention alerting-dashboards-plugin#372
• [BUG] Repo name doesn't adhere to plugins naming convention security-analytics-dashboards-plugin#187
• [BUG] Repo name doesn't adhere to plugins naming convention security-dashboards-plugin#1232
• [Decide] how do we name , organize and build visualization plugin/ widgets dashboards-visualizations#130 (comment)
• [BUG] Names don't adhere to plugin naming convention alerting#687
• [BUG]Names don't adhere to plugin naming convention ml-commons#847
• [BUG]Names don't adhere to plugin naming convention geospatial#252
• Rename and add a script to update version to match OpenSearch Dashboards dashboards-i18n#22
• [BUG] Names don't adhere to plugin naming convention asynchronous-search#209

[elfisher]

@mnkugler could you help pick this one up?

[mnkugler]

@elfisher sure!

[elfisher]

@elfisher sure!

Thanks!

[mnkugler]

Can anyone comment on the implications of renaming a plugin? For example, how do we handle existing dependencies? With an alias?

[davidlago]

May the first brave team renaming their plugin serve as a tracer bullet for this 🎖️

If this ends up being bigger than a breadbox, we should have the discussion around whether the juice is worth the squeeze especially for plugin repos given that we are thinking of what the next iteration of plugins would be and they might be on a (albeit long) deprecation path. 🤔

[macohen]

Oh man. Renaming plugins sounds like a painful process. But, can we ensure that naming is consistent moving forward? In what cases from the CONVENTIONS.md doc does "These are recommended plugin naming conventions. YMMV." really apply if we do want consistency?

[dblock]

+1 on getting rid of YMMV

[mnkugler]

Here's a summary of the most noticeable deviations from the conventions.

Plugin	Issue (links to the rule in CONVENTIONS.md)
Index Management Dashboard	Remove plugin from the repo name
Alerting Dashboard	Remove plugin from the repo name
Security Analytics Dashboard Plugins	Remove plugin from the repo name
Security Dashboard Plugin	Remove plugin from the repo name
Dashboard Maps	Folder needs to be fixed
Dashboard Maps	Plugin ID needs to be lowercase camelcase
Dashboard Maps	Meta needs to be updated to match the plugin name
Dashboard Visualization	Folder needs to be fixed
Alerting	Folder needs to be fixed
SQL	Folder needs to be fixed
Common Utils	opensearchplugin metadata is missing from build.gradle
Performance Analyzer RCA	opensearchplugin metadata is missing from build.gradle
ML Commons	opensearchplugin metadata is missing from build.gradle
Geospatial	opensearchplugin metadata is missing from build.gradle
i18n	Remove plugin from the repo name
i18n	Plugin ID needs to align with convention with camel case, e.g., i18nDashboards

[amitgalitz]

For current plugins that have already been published to maven without following the convention, will we create a new plugin name and release under a new name?

[dblock]

@amitgalitz Do you have a strong preference one way or another? Feels like 3.0 may be a good time to do this.

[amitgalitz]

@amitgalitz Do you have a strong preference one way or another? Feels like 3.0 may be a good time to do this.

If we are thinking long term, I think 3.0 is a good time to do this as well. Developers should be expecting breaking changes, having to potentially change API, or gradle dependencies during 3.0 bump could make sense.

There are 2 things I can think of at least that we should consider before though.

1. We should find the correct way to let users know of the change to a new release on maven since I don't know of an easy way to link one maven software to a separate maven software and label that as a continuation.

2. We should only actually change plugin names for convention case if we figure out a way to really enforce these naming conventions. Even as recent as 2.4.0 we have new plugins that used the new onboarding issue creation process that still have incorrect plugin names.

[mnkugler]

Dashboard Maps, SQL, Common Util, & Performance Analyzer RCA have all resolved their issues. The following table illustrates the 10 Repos left and their status:

Repo	Issue	Owner	Status	GH Issue
Index Management Dashboard	Remove plugin from the repo name	getsaurabh02	Fix after 2.11 release	issue
Alerting Dashboard	Remove plugin from the repo name	getsaurabh02	Fix after 2.11 release	issue
Security Analytics Dashboard Plugins	Remove plugin from the repo name	praveensameneni	Fix after 2.11 release	issue
Security Dashboard Plugin	Remove plugin from the repo name	davidlago	Fix by 3.0	issue
Dashboard Visualization	Folder needs to be fixed	anirudha	On hold and Ani will come up with a solution	issue
Alerting	Folder needs to be fixed	getsaurabh02	Fix after 2.11 release	issue
ML Commons	opensearchplugin metadata is missing from build.gradle	sean-zheng-amazon	complete	issue
Geospatial	opensearchplugin metadata is missing from build.gradle	vamshin	complete	issue
i18n	Remove plugin from the repo name & Plugin ID needs to align with convention with camel case	seanneumann	Complete	issue
Asynchronous Search	Folder needs to be fixed	dhruvdas	complete	issue

[mnkugler]

Updated chart: Alerting, Index Management, and Security Analytics is planning to work on removing the word “plugin” from the repo name after 2.11 to ensure the best timing for no breaking changes.