-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[CCR] Change APIs to align better with how CCR will be used #33931
Comments
Pinging @elastic/es-distributed |
+1 |
I think that
Additionally, I am not sure if
Next, maybe
with endpoints:
What do you think @bleskes @dliappis @dnhatn @martijnvg? |
I'm good with pause/resume instead of stop/start. IMO we don't need the follow about I'm ok with having it. Re |
If we would make the follow api (which is now create and follow) only accept a http PUT and when we add the ability to turn an existing index into a follow index we also accept a http POST then would that be clear enough? The PUT variant would fail if the follow index already exists and the POST variant would fail if the follow index is missing. I'm 👍 with pause/resume instead of stop/start and the reasoning behind it. Personally I like the symmetry that comes with the shortening from |
@bleskes I had the same thought as you this morning regarding future APIs and had the same thought as @martijnvg as a solution to it: |
I feel the difference between |
Renamed: * `/{index}/_ccr/create_and_follow` to `/{index}/_ccr/follow` * `/{index}/_ccr/unfollow` to `/{index}/_ccr/pause_follow` * `/{index}/_ccr/follow` to `/{index}/_ccr/resume_follow` Relates to elastic#33931
@elastic/es-clients any opinions here? |
What are the semantics behind I agree with @boaz that the difference is a bit too subtle. If we reuse the There are other API's that accept both |
Thanks for the feedback everyone. I feel that our proposed use of So let us move forward with:
and reserving but not currently implementing
|
* Renamed CCR APIs Renamed: * `/{index}/_ccr/create_and_follow` to `/{index}/_ccr/follow` * `/{index}/_ccr/unfollow` to `/{index}/_ccr/pause_follow` * `/{index}/_ccr/follow` to `/{index}/_ccr/resume_follow` Relates to #33931
* Renamed CCR APIs Renamed: * `/{index}/_ccr/create_and_follow` to `/{index}/_ccr/follow` * `/{index}/_ccr/unfollow` to `/{index}/_ccr/pause_follow` * `/{index}/_ccr/follow` to `/{index}/_ccr/resume_follow` Relates to #33931
The unfollow API changes a follower index into a regular index, so that it will accept write requests from clients. For the unfollow api to work the index follow needs to be stopped and the index needs to be closed. Closes elastic#33931
The unfollow API changes a follower index into a regular index, so that it will accept write requests from clients. For the unfollow api to work the index follow needs to be stopped and the index needs to be closed. Closes #33931
The unfollow API changes a follower index into a regular index, so that it will accept write requests from clients. For the unfollow api to work the index follow needs to be stopped and the index needs to be closed. Closes #33931
* Renamed CCR APIs Renamed: * `/{index}/_ccr/create_and_follow` to `/{index}/_ccr/follow` * `/{index}/_ccr/unfollow` to `/{index}/_ccr/pause_follow` * `/{index}/_ccr/follow` to `/{index}/_ccr/resume_follow` Relates to #33931
The unfollow API changes a follower index into a regular index, so that it will accept write requests from clients. For the unfollow api to work the index follow needs to be stopped and the index needs to be closed. Closes #33931
The names of the current CCR APIs don't match well with what they are doing and the use cases CCR needs to support.
Based on what ccr does and the use cases it needs support there is a need for the following primitives:
It should be possible to stop and than start following a leader index with the same follow index, so that parameters that control certain characteristics of the persistent tasks following leader shards can be changed to improve replication throughput.
Currently there are the following APIs:
The follow changes should be made in order to better align CCR with the supported use cases:
index.xpack.ccr.following_index
setting and ccr custom index metadata in the IndexMetaData of the follow index. After this; when the index is opened then it will not longer use theFollowingEngine
.The text was updated successfully, but these errors were encountered: