-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Fix handling of mandatory meta plugins #28710
Fix handling of mandatory meta plugins #28710
Conversation
This commit fixes an issue with setting plugin.mandatory to include a meta-plugin. The issue here is that the names that we collect are the underlying plugins, not the meta-plugin. We should not use the underlying plugins instead using the names of non-meta plugins and the names of meta-plugins. This commit addresses this. The strategy here is that when we look at the installed plugins on the filesystem, we keep track of which ones are meta-plugins and carry this information up to where check which plugins are installed against the mandatory plugins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I left a minor comment and a question.
* Extracts all installed plugin directories from the provided {@code rootPath} expanding meta plugins if needed. | ||
* Represents a meta-plugin and the {@link Bundle}s corresponding to its constituents. | ||
*/ | ||
static class MetaBundle implements BundleCollection{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: missing space after BundleCollection
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jimczi I will correct this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed 368f5f7.
pluginsList.add(bundle.plugin); | ||
} | ||
seenBundles.addAll(bundles); | ||
pluginsNames.add(plugin.name()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that a plugin inside a meta
plugin cannot be set as mandatory ? I don't know if this is a problem or not though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct. I think this is okay though, it’s limited to the user-facing plugins (what they can install and uninstall). Do you agree with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed, thanks for asking.
* master: Enable selecting adaptive selection stats Remove leftover mention of file-based scripts Fix threading issue on listener notification (elastic#28730) Revisit deletion policy after release the last snapshot (elastic#28627) Remove unused method Track deletes only in the tombstone map instead of maintaining as copy (elastic#27868) [Docs] Correct typo in README.textile (elastic#28716) Fix AdaptiveSelectionStats serialization bug (elastic#28718) TEST: Fix InternalEngine#testAcquireIndexCommit Add note on temporary directory for Windows service Added coming annotation and breaking changes link to release notes script Remove leftover PR link for previously disabled bwc tests Separate acquiring safe commit and last commit (elastic#28271) Fix BWC issue of the translog last modified age stats
This commit fixes an issue with setting plugin.mandatory to include a meta-plugin. The issue here is that the names that we collect are the underlying plugins, not the meta-plugin. We should not use the underlying plugins instead using the names of non-meta plugins and the names of meta-plugins. This commit addresses this. The strategy here is that when we look at the installed plugins on the filesystem, we keep track of which ones are meta-plugins and carry this information up to where check which plugins are installed against the mandatory plugins. Relates #28710
Thanks @jimczi. |
This reverts commit 62c5723. Relates elastic/elasticsearch#28710
This commit fixes an issue with setting plugin.mandatory to include a meta-plugin. The issue here is that the names that we collect are the underlying plugins, not the meta-plugin. We should not use the underlying plugins instead using the names of non-meta plugins and the names of meta-plugins. This commit addresses this. The strategy here is that when we look at the installed plugins on the filesystem, we keep track of which ones are meta-plugins and carry this information up to where check which plugins are installed against the mandatory plugins. Relates elastic#28710
Commit 7a051f3 reverted the use of a more specific plugin name for the mandatory plugin check (e.g. specifying `mandatory.plugin=x-pack` instead of ``mandatory.plugin=x-pack-security`), however, this was more specific names are still required for benchmarking release versions <6.3. Selectively use a more specific name for the mandatory plugin check depending on the Elasticsearch version. Relates: 7a051f3 Relates: elastic/elasticsearch#28710
Commit 7a051f3 reverted the use of a more specific plugin name for the mandatory plugin check (e.g. specifying `mandatory.plugin=x-pack` instead of ``mandatory.plugin=x-pack-security`), however, this was more specific names are still required for benchmarking release versions <6.3. Selectively use a more specific name for the mandatory plugin check depending on the Elasticsearch version. Relates: 7a051f3 Relates: elastic/elasticsearch#28710
Commit 7a051f3 reverted the use of a more specific plugin name for the mandatory plugin check (e.g. specifying `mandatory.plugin=x-pack` instead of ``mandatory.plugin=x-pack-security`), however, more specific names are still required for benchmarking release versions <6.3. Selectively use a more specific name for the mandatory plugin check depending on the Elasticsearch version. Also add test cases for both scenarios. Relates: 7a051f3 Relates: elastic/elasticsearch#28710
Commit 7a051f3 reverted the use of a more specific plugin name for the mandatory plugin check (e.g. specifying `mandatory.plugin=x-pack` instead of ``mandatory.plugin=x-pack-security`), however, more specific names are still required for benchmarking release versions <6.3. Selectively use a more specific name for the mandatory plugin check depending on the Elasticsearch version. Also add test cases for both scenarios. Relates: 7a051f3 Relates: elastic/elasticsearch#28710
Commit 7a051f3 reverted the use of a more specific plugin name for the mandatory plugin check (e.g. specifying `mandatory.plugin=x-pack` instead of ``mandatory.plugin=x-pack-security`), however, more specific names are still required for benchmarking release versions <6.3. Selectively use a more specific name for the mandatory plugin check depending on the Elasticsearch version. Also add test cases for both scenarios. Relates: 7a051f3 Relates: elastic/elasticsearch#28710
Commit 7a051f3 reverted the use of a more specific plugin name for the mandatory plugin check (e.g. specifying `mandatory.plugin=x-pack` instead of `mandatory.plugin=x-pack-security`), however, more specific names are still required for benchmarking release versions <6.3. Selectively use a more specific name for the mandatory plugin check depending on the Elasticsearch version. Also add test cases for both scenarios. Relates: #446 Relates: 7a051f3 Relates: elastic/elasticsearch#28710
This commit fixes an issue with setting plugin.mandatory to include a meta-plugin. The issue here is that the names that we collect are the underlying plugins, not the meta-plugin. We should not use the underlying plugins instead using the names of non-meta plugins and the names of meta-plugins. This commit addresses this. The strategy here is that when we look at the installed plugins on the filesystem, we keep track of which ones are meta-plugins and carry this information up to where check which plugins are installed against the mandatory plugins.
Relates #28022