Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove duplicate meta file #219

Merged
merged 1 commit into from
Jun 27, 2023

Conversation

prudhvigodithi
Copy link
Contributor

@prudhvigodithi prudhvigodithi commented Jun 27, 2023

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 opensearch-project/opensearch-build#3616 and opensearch-project/.github#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.

Signed-off-by: Prudhvi Godithi <[email protected]>
@saratvemulapalli saratvemulapalli merged commit cb2cde5 into opensearch-project:main Jun 27, 2023
@dblock
Copy link
Member

dblock commented Jun 28, 2023

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
Copy link
Contributor Author

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 opensearch-project/.github#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
Copy link
Member

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
Copy link
Member

dblock commented Jun 30, 2023

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
Copy link
Contributor Author

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
Copy link
Member

gaiksaya commented Jul 5, 2023

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
Copy link
Member

dblock commented Jul 6, 2023

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

@gaiksaya
Copy link
Member

gaiksaya commented Jul 7, 2023

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
Copy link
Member

dblock commented Jul 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants