Remove duplicate meta file

[prudhvigodithi]

Description

Remove duplicate .meta file from the root folder as the meta files for OS is under plugins/.meta and OSD is under dashboards-plugins/.meta

Fix few broken links for the linkchecker to pass.

Issues Resolved

Part of https://github.com/opensearch-project/opensearch-build/issues/3616 and https://github.com/opensearch-project/.github/issues/167

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[dblock]

The intent of the top-level meta was to have a sum of all plugins, especially that there used to be duplicates where an OpenSearch plugin and a Dashboards plugin were in the same repo.

[prudhvigodithi]

Thanks @dblock, its not always updated and updating at two places might cause missing at one place, this plugin list is used during the release issue creation (and for other automations). Removed the top .meta mainly for https://github.com/opensearch-project/.github/issues/167 to avoid confusion for an release manager taking up the release.

Another point I have noticed is sometimes the plugin list has the plugin that is not yet ready for a release (ex oci-object-storage), so using them for automation might fail acknowledging the release label etc. Should we maintain a new meta list that is always updated with the plugins that go for a release and folder level plugins/.meta dashboards-plugins/.meta can have all the plugins that are created but not yet for release?

@bbarani @peterzhuamazon @gaiksaya

[gaiksaya]

Yeah even for compatibility check which is using plugins/.meta file, oci-object-storage is one of the component. Any way to filter out what projects are actually active / part of release and which are upcoming?

[dblock]

The real problem is that multiple versions of OpenSearch have different plugins. So using this list from an upstream is never going to work - I suggest using the previously released version manifest in opensearch-build for your original purpose of getting the "list of plugins".

[prudhvigodithi]

Ya this .meta list is not the right way to move forward, we need to create a release issue in OpenSearch and OpenSearch Dashboards repo as well, whereas in .meta the list only confines to the plugins, a release manager might miss to create a release issue in core repos.

[gaiksaya]

Ya this .meta list is not the right way to move forward, we need to create a release issue in OpenSearch and OpenSearch Dashboards repo as well, whereas in .meta the list only confines to the plugins, a release manager might miss to create a release issue in core repos.

@prudhvigodithi @dblock But manifest might not be the source of truth as plugins are added incrementally. Does it make sense to have 1.x, 2,x and 3.x default manifests with all plugins in the list? Many times we remove components from the manifest to unblock a build (for now), not ready, etc. so might be misleading at the start of the release cycle.

[dblock]

What do you think about a solution where the list of plugins always exists in the build manifest, https://github.com/opensearch-project/opensearch-build/issues/3707?

[gaiksaya]

What do you think about a solution where the list of plugins always exists in the build manifest, opensearch-project/opensearch-build#3707?

This also makes sense. Would it be too much confusing? Placeholder / non-placeholder?

[dblock]

What do you think about a solution where the list of plugins always exists in the build manifest, opensearch-project/opensearch-build#3707?

This also makes sense. Would it be too much confusing? Placeholder / non-placeholder?

We can discuss it in that proposal.