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

Make EC2 Discovery Plugin Retry Requests #50550

Merged
merged 8 commits into from
Jan 2, 2020

Conversation

original-brownbear
Copy link
Member

Use the default retry condition instead of never retrying in the discovery plugin causing hot retries upstream and
add a test that verifies retrying works.

Closes #50462

Use the default retry condition instead of never retrying in the discovery plugin causing hot retries upstream and
add a test that verifies retrying works.

Closes elastic#50462
@original-brownbear original-brownbear added >non-issue :Distributed Coordination/Discovery-Plugins Anything related to our integration plugins with EC2, GCP and Azure v8.0.0 v7.6.0 labels Jan 2, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (:Distributed/Discovery-Plugins)

import static org.hamcrest.Matchers.is;

@SuppressForbidden(reason = "use a http server")
public class EC2RetriesTests extends ESTestCase {
Copy link
Member Author

Choose a reason for hiding this comment

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

Admittedly quite a bit of code, but I'm hoping we can just extend the REST layer mocking here and dry things up against the fixture step-by-step like we did for S3 and the other cloud providers in the repository tests to get rid of all our complicated mocking of actual AWS SDK classes and just mock on the REST layer.

@@ -79,7 +79,7 @@ static ClientConfiguration buildConfiguration(Logger logger, Ec2ClientSettings c
// Increase the number of retries in case of 5xx API responses
final Random rand = Randomness.get();
final RetryPolicy retryPolicy = new RetryPolicy(
RetryPolicy.RetryCondition.NO_RETRY_CONDITION,
null,
Copy link
Member Author

Choose a reason for hiding this comment

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

Just using the default retry condition here now. We may want to make the retry interval configurable, if only internally for tests. The current settings make the first retry happen after almost 20s but I didn't want to add that complication here yet.

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

I left a question.

I also think we should adjust the behaviour of AwsEc2SeedHostsProvider to respect discovery.ec2.node_cache_time even if the last attempt resulted in an exception and/or an empty list.

@@ -79,7 +79,7 @@ static ClientConfiguration buildConfiguration(Logger logger, Ec2ClientSettings c
// Increase the number of retries in case of 5xx API responses
final Random rand = Randomness.get();
final RetryPolicy retryPolicy = new RetryPolicy(
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we avoid setting our own retry policy at all and use the SDK default? The SDK makes a more nuanced decision about how much to back off based on the error type. If we really want 10 retries then that can be overridden with setMaxErrorRetry(10) instead?

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, that's much nicer. Moved to the default and kept retries at 10 for now in d015576 :)

@original-brownbear
Copy link
Member Author

I also think we should adjust the behaviour of AwsEc2SeedHostsProvider to respect discovery.ec2.node_cache_time even if the last attempt resulted in an exception and/or an empty list.

Wanna do that here or in a follow-up?

if (auth == null || auth.contains(accessKey) == false) {
throw new IllegalArgumentException("wrong access key: " + auth);
}
if (failedRequests.add(exchange.getRequestHeaders().getFirst("Amz-sdk-invocation-id"))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we also check that we retry repeatedly? The first five retries take less than a second.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done :)

@DaveCTurner
Copy link
Contributor

Wanna do that here or in a follow-up?

Yes a follow-up makes more sense.

@original-brownbear
Copy link
Member Author

@DaveCTurner thanks, all points addressed I think :)

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

LGTM

@original-brownbear
Copy link
Member Author

Thanks David!

@original-brownbear original-brownbear merged commit 789f790 into elastic:master Jan 2, 2020
@original-brownbear original-brownbear deleted the 50462 branch January 2, 2020 15:30
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Jan 2, 2020
Use the default retry condition instead of never retrying in the discovery plugin causing hot retries upstream and add a test that verifies retrying works.

Closes elastic#50462
original-brownbear added a commit that referenced this pull request Jan 2, 2020
Use the default retry condition instead of never retrying in the discovery plugin causing hot retries upstream and add a test that verifies retrying works.

Closes #50462
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Jan 3, 2020
Move EC2 discovery tests to using the mock REST API introduced in
elastic#50550 instead of mocking
the AWS SDK classes manually.
Move the trivial remaining AWS SDK mocks to the single test suit that
was using them.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Jan 3, 2020
Follow up to elastic#50550. Cache empty nodes lists (`fetchDynamicNodes` will return an empty list in case of failure)
now that the plugin properly retries requests to AWS EC2 APIs.
original-brownbear added a commit that referenced this pull request Jan 3, 2020
Follow up to #50550. Cache empty nodes lists (`fetchDynamicNodes` will return an empty list in case of failure)
now that the plugin properly retries requests to AWS EC2 APIs.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Jan 3, 2020
Follow up to elastic#50550. Cache empty nodes lists (`fetchDynamicNodes` will return an empty list in case of failure)
now that the plugin properly retries requests to AWS EC2 APIs.
original-brownbear added a commit that referenced this pull request Jan 3, 2020
Follow up to #50550. Cache empty nodes lists (`fetchDynamicNodes` will return an empty list in case of failure)
now that the plugin properly retries requests to AWS EC2 APIs.
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
Use the default retry condition instead of never retrying in the discovery plugin causing hot retries upstream and add a test that verifies retrying works.

Closes elastic#50462
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
Follow up to elastic#50550. Cache empty nodes lists (`fetchDynamicNodes` will return an empty list in case of failure)
now that the plugin properly retries requests to AWS EC2 APIs.
original-brownbear added a commit that referenced this pull request Feb 12, 2020
Move EC2 discovery tests to using the mock REST API introduced in
#50550 instead of mocking
the AWS SDK classes manually.
Move the trivial remaining AWS SDK mocks to the single test suit that
was using them.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 12, 2020
Move EC2 discovery tests to using the mock REST API introduced in
elastic#50550 instead of mocking
the AWS SDK classes manually.
Move the trivial remaining AWS SDK mocks to the single test suit that
was using them.
original-brownbear added a commit that referenced this pull request Feb 12, 2020
Move EC2 discovery tests to using the mock REST API introduced in
#50550 instead of mocking
the AWS SDK classes manually.
Move the trivial remaining AWS SDK mocks to the single test suit that
was using them.
@original-brownbear original-brownbear restored the 50462 branch August 6, 2020 18:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Distributed Coordination/Discovery-Plugins Anything related to our integration plugins with EC2, GCP and Azure v7.6.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[discovery-ec2] Plugin doesn't retry EC2 describe instance calls
4 participants