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

Add support for custom headers and request-timeout #1070

Merged
merged 9 commits into from
Oct 27, 2020

Conversation

DJRickyB
Copy link
Contributor

@DJRickyB DJRickyB commented Oct 5, 2020

Addresses #567 and #1000
Well it became trivial to add headers and opaque-id support for everything in the course of this refactor so I added that too.

Done:

  • support request-timeout parameter for most operation types
  • support opaque-id parameter for most operation types
  • support headers dict parameter for most operation types
  • document expanded parameter support

@cla-checker-service
Copy link

cla-checker-service bot commented Oct 5, 2020

💚 CLA has been signed

timeout=request_timeout)
else:
await es.transport.perform_request("POST", "/_optimize", timeout=request_timeout)
await es.transport.perform_request(method="POST", url="/_optimize", params=merge_params)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

transport.perform_request() expects the timeout parameter in the params arg. Throws

TypeError: perform_request() got an unexpected keyword argument 'timeout'

Copy link
Contributor

Choose a reason for hiding this comment

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

it looks like you removed the logic here about max_num_segments. Good catch about the timeout though, lets definitely fix that here once you revert the code change that deleted the if stmt

Copy link
Contributor Author

@DJRickyB DJRickyB Oct 16, 2020

Choose a reason for hiding this comment

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

max_num_segments exists in the merge_params and gets applied to the query string by the perform_request method

see test at https://github.com/elastic/rally/pull/1070/files#diff-026a25af4075b17db2736adf14aa844c0aaeb2bc995b4b4ae94c432b0380b51fR1095

@dliappis dliappis requested a review from hub-cap October 14, 2020 09:55
@hub-cap
Copy link
Contributor

hub-cap commented Oct 16, 2020

Hi, @DJRickyB , thank you very much for your contribution! This is good work so far. I have one overall suggestion that might make the code cleaner. It also requires a bit of context.

We hope to one day utilize more than just the timeout in the future, for instance, the opaque-id, so it might make sense to consolidate all of the different Runner implementations to use a single method, such as this method, and use it to populate all of the Runner classes. As is, many of them do some very similar operations with their params to extract the request-params, and maybe we can use a common method to both extract that, as well as ensure we populate the timeout. What do you think of this idea/suggestion?

I have also added just a few minor nits to the pull request that I saw right off the bat, before realizing we could extract the common functionality into the Runners.

Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

Oops! I meant to post that comment into this review, not as just a comment. here are the nits I mentioned in the review itself!

esrally/driver/runner.py Outdated Show resolved Hide resolved
esrally/driver/runner.py Outdated Show resolved Hide resolved
esrally/driver/runner.py Outdated Show resolved Hide resolved
esrally/driver/runner.py Outdated Show resolved Hide resolved
timeout=request_timeout)
else:
await es.transport.perform_request("POST", "/_optimize", timeout=request_timeout)
await es.transport.perform_request(method="POST", url="/_optimize", params=merge_params)
Copy link
Contributor

Choose a reason for hiding this comment

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

it looks like you removed the logic here about max_num_segments. Good catch about the timeout though, lets definitely fix that here once you revert the code change that deleted the if stmt

@DJRickyB
Copy link
Contributor Author

Thank you Michael! Your timing is perfect, I was planning on finishing this PR this weekend. Please pardon the force-push, it's not usually my style but I wanted a way to get prior git history to apply to the comment lines I had touched

@DJRickyB DJRickyB changed the title Addresses #567 Add support for custom headers and request-timeout Oct 19, 2020
@DJRickyB DJRickyB marked this pull request as ready for review October 19, 2020 03:16
@DJRickyB DJRickyB requested a review from hub-cap October 19, 2020 03:16
Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

wow this looks great now! I love how its not touching all the tests. Also, Thank you SO VERY much for making the PR name more descriptive. Just some minor nits now and this will be good to go.

One other thing, go ahead and merge master in git merge upstream/master and run make precommit, and it will show you one line length failure you have. This will fail before the tests will run. Once you are done w this ill make sure our CI infra can run the tests.

esrally/driver/runner.py Outdated Show resolved Hide resolved
"status": "green",
"relocating_shards": 0
})
r = runner.ClusterHealth()
Copy link
Contributor

Choose a reason for hiding this comment

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

we try not to have single value names for variables, lets make this a bit more descriptive

tests/driver/runner_test.py Outdated Show resolved Hide resolved
@DJRickyB DJRickyB requested a review from hub-cap October 20, 2020 22:47
@hub-cap
Copy link
Contributor

hub-cap commented Oct 21, 2020

@elasticmachine ok to test

@hub-cap
Copy link
Contributor

hub-cap commented Oct 21, 2020

grr, my magic incantation is incorrect.

@elasticmachine add to allowlist please

@hub-cap
Copy link
Contributor

hub-cap commented Oct 21, 2020

ok at this point w/ the proper incantation, your PR will now run tests for each commit. If it fails for some reason, go ahead and fix it up (or ask for help if need be), and push, and it should run the tests again.

@DJRickyB
Copy link
Contributor Author

is there somewhere i can push new test tracks to exercise the functionality? good to see it looks like no regressions :)

@hub-cap
Copy link
Contributor

hub-cap commented Oct 22, 2020

If you push some test tracks, it would be rad to just push them to a branch, and then link the commands you use (assuming the repos were checked out locally). Ill test them myself to double check and then we can call this done and merge it. Im off tomorrow, but I should be able to get to them by monday if you push some branches up to your fork of rally tracks.

@hub-cap
Copy link
Contributor

hub-cap commented Oct 26, 2020

Also, I forgot to add, if you are using and existing corpora, you can use the built in rally --test-mode flag which will only ingest a small sample set of data, so your feedback loop is much tighter when testing track changes.

@hub-cap hub-cap self-assigned this Oct 26, 2020
@DJRickyB
Copy link
Contributor Author

DJRickyB commented Oct 26, 2020

Thanks, sorry for the delay. Running with local test tracks and watching with wireshark revealed a couple of misses in params.py based on how parameter parsing for a given operation was set up. The changes I made add 3 None values to the params dictionary for a few types, so now the size check tests have changed in a few places (see failures from your CI).

Edit: going to change the counts tests and update parameters. submitted originally for feedback but the right path became obvious after another cup of coffee

FYI I'm just using this locally: elastic/rally-tracks@d7b1ac4

Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

yay, its merge time!

@hub-cap hub-cap merged commit 90722ac into elastic:master Oct 27, 2020
@hub-cap hub-cap added :Usability Makes Rally easier to use enhancement Improves the status quo labels Oct 28, 2020
@hub-cap hub-cap added this to the 2.0.3 milestone Oct 28, 2020
dliappis added a commit to dliappis/rally that referenced this pull request Nov 23, 2020
Currently in polling mode, the force merge operation uses a very short
timeout (1s) which, in case of slow response times, might actually
cause the operation to not get executed.

Since elastic#1070 we can specify per operation request-timeout and we should
honor that one instead.
dliappis added a commit that referenced this pull request Nov 23, 2020
…#1122)

Currently in polling mode, the force merge operation uses a very short
timeout (1s) which, in case of slow response times, might actually
cause the operation to not get executed.

Since #1070 we can specify per operation request-timeout and we should
honor that one instead.

Co-authored-by: Daniel Mitterdorfer <daniel@mitterdorfer.name>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improves the status quo :Usability Makes Rally easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants