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

remove access to patching elasticsearch client directly as it is not supported anymore by elasticsearch #3399

Merged
merged 5 commits into from
Jan 29, 2024

Conversation

ekump
Copy link
Contributor

@ekump ekump commented Jan 24, 2024

2.0 Upgrade Guide notes

In 1.x, both the ElasticSearch "client" and ElasticSearch "transport" can be configured:

Datadog.configure_onto(client, **options)
Datadog.configure_onto(client.transport, **options)

But the ElasticSearch "client" is not available across all versions of the ElasticSearch gem, which makes configuration unreliable, while the "transport" is.

In 2.0, only ElasticSearch "transport" can be configured:

Datadog.configure_onto(client.transport, **options)

Could use a hand in crafting a proper upgrade note for this one

What does this PR do?
Removes the ability to instrument a client object of Elasticsearch as the client object is not available as of Elasticsearch 8.0. Instrumenting the transport object is available in all versions.

Motivation:
Makes ES integration consistent between versions

Additional Notes:

How to test the change?

For Datadog employees:

  • If this PR touches code that signs or publishes builds or packages, or handles
    credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
  • This PR doesn't touch any of that.

Unsure? Have a question? Request a review!

@ekump ekump requested a review from a team as a code owner January 24, 2024 22:17
@github-actions github-actions bot added integrations Involves tracing integrations tracing labels Jan 24, 2024
@ekump ekump force-pushed the ekump/es-remove-client-self-access branch from a1aa6d2 to 1dc782c Compare January 24, 2024 22:17
@ekump ekump force-pushed the ekump/es-remove-client-self-access branch from 97c2673 to 821f631 Compare January 26, 2024 21:52
if version_greater_than_8
Datadog.configure_onto(client.transport, service_name: service_name)
else
Datadog.configure_onto(client.transport.transport, service_name: service_name)
Copy link
Contributor Author

@ekump ekump Jan 26, 2024

Choose a reason for hiding this comment

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

@marcotc @TonyCTHsu When I added back this test to allow custom config on the transport object it initially failed. Turns out that prior to ES 8.0 client.transport refers to the client instance. client.transport.transport refers to the transport instance. With ES > 8.0 client.transport refers to the transport instance. So when I changed the patch of perform_request to not check Datadog.configuration_for(self, :service_name) and only do Datadog.configuration_for(transport, :service_name) it was getting back nil on ES 7.0 since there is a discrepancy between what we set with configure_onto and what we get with configuration_for.

As I see it we have 3 options:

  1. Keep my changes as they are, and update the docs to explain that if you are on ES < 8.0 you need to configure_onto client.transport.transport. This makes our code simpler, but our docs slightly more complicated.
  2. Keep my code changes, update the this test to skip ES < 8.0, and update our documentation to say we don't support custom configuration for transport below ES 8.0
  3. Change the code so that if ES < 8 we support configuration on the client object, but not support it for 8.0+ and remove the deprecation warning.

I think option 1 is the best balance of user-friendliness and code simplicity.

@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (277b90f) 98.10% compared to head (3ac27d8) 98.08%.
Report is 54 commits behind head on 2.0.

Additional details and impacted files
@@            Coverage Diff             @@
##              2.0    #3399      +/-   ##
==========================================
- Coverage   98.10%   98.08%   -0.02%     
==========================================
  Files        1252     1252              
  Lines       72342    72339       -3     
  Branches     3387     3386       -1     
==========================================
- Hits        70974    70957      -17     
- Misses       1368     1382      +14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -126,6 +127,25 @@ def datadog_configuration
# rubocop:enable Metrics/MethodLength
# rubocop:enable Metrics/AbcSize

# Patch to support both `elasticsearch` and `elastic-transport` versions
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@TonyCTHsu Is this the pattern we want to follow in situations where the instance we're trying to instrument may be different between versions of an integration? I didn't see any other direct examples of this (We do patch pinning in mongodb for different reasons).

I have two questions/concerns:

  1. Is the complexity / indirection we're adding to our code worth the tradeoff of simpler configuration?
  2. Are we potentially confusing users by masking ES implementation details like this? client.transport refers to a different object depending on ES version and we're providing a way to configure on an instance of that object. I could see the merit of an argument that we shouldn't be changing that object behind the scenes.

I lean slightly towards not doing this, but I don't have a strong opinion. At the end of the day either the library or the user has to set a different instance depending on ES version.

CC: @delner @marcotc in case you have any thoughts on a general strategy for these types of situations. We should probably agree on a pattern so we are consistent the next time it occurs. Some context.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Closing the loop on this: Spoke to @marcotc and @TonyCTHsu and we all agreed with this pattern.

@ekump ekump merged commit 89c9083 into 2.0 Jan 29, 2024
151 checks passed
@ekump ekump deleted the ekump/es-remove-client-self-access branch January 29, 2024 18:36
@TonyCTHsu TonyCTHsu added this to the 2.0 milestone Feb 20, 2024
@ivoanjo ivoanjo added the 2.0 label Mar 14, 2024
@TonyCTHsu TonyCTHsu modified the milestones: 2.0, 2.0.0.beta1 Mar 22, 2024
@marcotc marcotc mentioned this pull request Apr 2, 2024
2 tasks
@TonyCTHsu TonyCTHsu mentioned this pull request Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.0 integrations Involves tracing integrations tracing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants