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

Generalize search.remote settings to cluster.remote #33413

Merged
merged 12 commits into from
Sep 6, 2018

Conversation

jasontedor
Copy link
Member

@jasontedor jasontedor commented Sep 5, 2018

With features like CCR building on the CCS infrastructure, the settings prefix search.remote makes less sense as the namespace for these remote cluster settings than does a more general namespace like cluster.remote. This commit replaces these settings with cluster.remote with a fallback to the deprecated settings search.remote.

Deprecating a some setting specializations (e.g., list settings) does
not cause deprecation warning headers and deprecation log messages to
appear. This is due to a missed check for deprecation. This commit fixes
this for all setting specializations, and ensures that this can not be
missed again.
With features like CCR building on the CCS infrastructure, the settings
prefix search.remote makes less sense as the namespace for these remote
cluster settings than does a more general namespace like
cluster.remote. This commit replaces these settings with cluster.remote
with a fallback to the deprecated settings search.remote.
@jasontedor jasontedor added review :Distributed/CCR Issues around the Cross Cluster State Replication features labels Sep 5, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@jasontedor
Copy link
Member Author

This PR is based on #33412; it was discovered in this work that list settings are not properly deprecated.

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I do think we need a note about this in the migration docs?

@jasontedor
Copy link
Member Author

@martijnvg Yup! I will do that in a separate PR targeting 6.5.0 only (for deprecation) and 7.0.0 (for removal).

@s1monw
Copy link
Contributor

s1monw commented Sep 5, 2018

I have some questions before I go into reviews:

  • how do we upgrade existing settings, is there a plan?
  • if we don't upgrade existing settings how do we make sure we can remove the BWC code at any point?
  • would it make sense to just us a more flexible AffixKey and discuss depreciation and upgrades in a separate issue?

* master:
  Fix deprecated setting specializations (elastic#33412)
  HLRC: split cluster request converters (elastic#33400)
  HLRC: Add ML get influencers API (elastic#33389)
  Add conditional token filter to elasticsearch (elastic#31958)
  Build: Merge xpack checkstyle config into core (elastic#33399)
  Disable IndexRecoveryIT.testRerouteRecovery.
  INGEST: Implement Drop Processor (elastic#32278)
  [ML] Add field stats to log structure finder (elastic#33351)
  Add interval response parameter to AutoDateInterval histogram (elastic#33254)
  MINOR+CORE: Remove Dead Methods ClusterService (elastic#33346)
@jasontedor
Copy link
Member Author

how do we upgrade existing settings, is there a plan?

Yes, my plan is to address this in a follow-up indeed.

if we don't upgrade existing settings how do we make sure we can remove the BWC code at any point?

This question is moot since I plan to automatically upgrade the settings.

would it make sense to just us a more flexible AffixKey and discuss depreciation and upgrades in a separate issue?

I would rather not as there are only a handful of settings here, it's straightforward enough to manage them individually. Are you okay with this?

@s1monw
Copy link
Contributor

s1monw commented Sep 5, 2018

I would rather not as there are only a handful of settings here, it's straightforward enough to manage them individually. Are you okay with this?

++ LGTM

@jasontedor jasontedor merged commit d71ced1 into elastic:master Sep 6, 2018
jasontedor added a commit that referenced this pull request Sep 6, 2018
With features like CCR building on the CCS infrastructure, the settings
prefix search.remote makes less sense as the namespace for these remote
cluster settings than does a more general namespace like
cluster.remote. This commit replaces these settings with cluster.remote
with a fallback to the deprecated settings search.remote.
@jasontedor jasontedor deleted the remote-cluster branch September 7, 2018 17:32
@javanna
Copy link
Member

javanna commented Sep 26, 2018

@jasontedor when I add the deprecated settings to the config file against master, I get the deprecation warning but the setting seems to be ignored, it does not do anything. You can repro this by adding some unreachable cluster, if you use the new settings the node won't start, with the older setting the node starts. If the remote cluster is reachable, using the deprecated settings I can never connect to it through ccs, _remote/info always returns empty.

@jasontedor
Copy link
Member Author

@javanna Thank you! I opened #34090.

jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Feb 7, 2019
Fallback settings were introduced in elastic#33413 where the
`search.remote.*` settings were generalized to `cluster.remote.*`.
This commit removes both the fallback settings and the upgraders
that were introduced in elastic#33537
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/CCR Issues around the Cross Cluster State Replication features >feature v6.5.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants