-
Notifications
You must be signed in to change notification settings - Fork 313
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
Refactor version number checks #1738
Conversation
buildkite build this please after #1739 |
4d89886
to
944d78c
Compare
elif is_serverless(distribution_version): | ||
return "master" |
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.
We only every select the master
branch of rally-tracks
when targeting a serverless cluster.
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 for iterating! That looks much better.
esrally/client/asynchronous.py
Outdated
_mimetype_header_to_compat("Content-Type", request_headers) | ||
# Not applicable to serverless | ||
if not self.is_serverless: | ||
if self.distribution_version is not None and ( |
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.
Can we assume that distribution_version
will be defined now?
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 think we can for the async client, just because we currently only create them in one place where we already know the distribution flavor/version. I mainly did this to be consistent between the two, but I think a better approach is to just check whether the value is a valid identifier as I've done in 5f2db54
esrally/client/factory.py
Outdated
async def on_request_start(session, trace_config_ctx, params): | ||
async_client.on_request_start() | ||
|
||
async def on_request_end(session, trace_config_ctx, params): | ||
async_client.on_request_end() | ||
|
||
trace_config = aiohttp.TraceConfig() | ||
trace_config.on_request_start.append(on_request_start) | ||
trace_config.on_request_end.append(on_request_end) | ||
# ensure that we also stop the timer when a request "ends" with an exception (e.g. a timeout) | ||
trace_config.on_request_exception.append(on_request_end) | ||
|
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.
Would you mind reverting this change? (Move this back up and replace async_client
with RallyAsyncElasticsearch
in the async methods.)
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.
Addressed in 94d8634
esrally/client/synchronous.py
Outdated
_mimetype_header_to_compat("Accept", request_headers) | ||
_mimetype_header_to_compat("Content-Type", request_headers) | ||
if not self.is_serverless: | ||
if self.distribution_version is not None and ( |
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.
Same as above
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.
Addressed in 5f2db54
esrally/tracker/tracker.py
Outdated
).create() | ||
|
||
info = client.info() | ||
console.info(f"Connected to Elasticsearch cluster [{info['name']}] version [{info['version']['number']}].\n", logger=logger) | ||
console.info(f"Connected to Elasticsearch cluster version [{distribution_version}]\n", logger=logger) |
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.
Should we log the flavor too?
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 thought about that, but when you're targeting stateful elasticsearch you just get default
back, which is a little confusing, so I just left it out entirely. Happy to include it if you think it's important 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.
Yes I think it's important to have Rally confirm what sort of cluster it thinks it's benchmarking.
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.
Sure, addressed in 27f1f12. I've kicked off a long running test benchmark too. Will likely merge early next week.
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 for all the iterations! LGTM. Only https://github.com/elastic/rally/pull/1738/files#r1238773617 left, but probably does not warrant another round.
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 thank you for this massive change!
Serverless Elasticsearch doesn't return a
version.number
field from the Info API (/
) , which is actually something we rely on somewhat commonly throughout the codebase.To fix this, we need a clearly defined way of determining whether or not Rally is talking to a Serverless Elasticsearch, this applies for both clients used to target the system under test, as well as any ancillary clients like those used by a remote metrics store.
In order to do so, we'll take two approaches:
is_serverless | bool
property on both existing and new 'serverless' specific clientsis_serverless
property if we need to do something specific for serverlessI think this is a balanced approach, given that serverless has no concept of 'versioning'.
Note:
The underlying client's use ofFixed in abf4320.options()
complicates things, because every call reinstantiates a new copy of itself, but without the ability for us to pass in any custom arguments (e.g.distribution_version
). To work around this we must work out upfront whether or not we'd like the factory to create a serverless or non-serverless client, each of which have a staticis_serverless
attribute.Example tests