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

Http Client API #309

Closed
wants to merge 12 commits into from
Closed

Conversation

lalitb
Copy link
Member

@lalitb lalitb commented Aug 31, 2020

This PR brings the HTTP client API to be used across various exporters ( eg zipkin, azure monitor ) to communicate with remove telemetry servers.

  • Need to discuss/review on the location of these headers. Not sure if they are right place.

TBD:

  • Documentation on usage
  • Sample implementation.

@lalitb lalitb requested a review from a team August 31, 2020 11:47
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Aug 31, 2020

CLA Check
The committers are authorized under a signed CLA.

@codecov
Copy link

codecov bot commented Aug 31, 2020

Codecov Report

Merging #309 into master will increase coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #309      +/-   ##
==========================================
+ Coverage   94.55%   94.56%   +0.01%     
==========================================
  Files         146      146              
  Lines        6610     6629      +19     
==========================================
+ Hits         6250     6269      +19     
  Misses        360      360              
Impacted Files Coverage Δ
sdk/include/opentelemetry/sdk/metrics/controller.h 90.32% <0.00%> (-6.46%) ⬇️
...pi/include/opentelemetry/context/runtime_context.h 95.83% <0.00%> (-4.17%) ⬇️
sdk/include/opentelemetry/sdk/metrics/instrument.h 93.84% <0.00%> (-0.36%) ⬇️
api/include/opentelemetry/trace/span_context.h 100.00% <0.00%> (ø)
sdk/test/trace/tracer_test.cc 99.09% <0.00%> (+0.01%) ⬆️
sdk/src/trace/span.cc 84.33% <0.00%> (+3.56%) ⬆️
sdk/src/trace/tracer.cc 73.52% <0.00%> (+4.56%) ⬆️
sdk/src/trace/span.h 100.00% <0.00%> (+100.00%) ⬆️

@lalitb
Copy link
Member Author

lalitb commented Aug 31, 2020

CLA Check

  • ❌The commit (e67bba8 ,9bf7c419dfcc4ee81bf36a7d3b2e8bb4c7a56497 ,f6bd12a7a57f930db7ffab6097d62be04eb640fe ,c58d316c8afed28370df5a2f5ef6daa3746003cd ,d7fa6c965217bffd4f81453874e82e783a87e81a ,041191eca1a2b11f4442f06138b0e4a4fe419ca2 ,71eaa9922613a9ed3e2b4e859a227dd0f24b5c37) is missing the User's ID, preventing the EasyCLA check. Consult GitHub Help to resolve. For further assistance with EasyCLA, please submit a support request ticket.

Have raised request for this.

virtual void set(nostd::string_view const &name, nostd::string_view const &value) = 0;

// Inserts a name/value pair
virtual void add(nostd::string_view const &name, nostd::string_view const &value) = 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the exact difference between add and set? Will add allow having multiple values for a single header? Will set fail if an element with the given name doesn't yet exist?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should refactor this. Original idea was that:

  • add - appends to multimap.
  • set - either adds or replaces if header already exists.

Maybe we should converge on alternate names for that.

I'm not sure if we really want to employ nostd::string_view here though. It's in SDK, which won't have ABI-stability requirement..... Unless we want to runtime dynamically inject an instance of HTTP stack.

// Returns:
// If there are multiple headers with same name, it returns any one of the value
// (implementation defined) Empty string if there is no header with speicfied name..
virtual nostd::string_view const &get(nostd::string_view const &name) const = 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

We usually don't pass string_views as reference in other parts of the API.

// must be set by the caller. The request object can then be sent
// using SendRequestAsync(). If you are not going to use the request object
// then you can delete it safely using its virtual destructor.
virtual HttpRequest *CreateRequest() = 0;
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 return a std::unique_ptr here?

// latter case, the OnHttpResponse() callback is called before this
// method returns. You must keep the callback object alive until its
// OnHttpResponse() callback is called.
virtual void SendRequest(HttpRequest *request, HttpResponseCallback *callback) = 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

Moving the request as an unique pointer would enforce the conditions you documented above (taking ownership and no modification after the call): std::unique_ptr<HttpRequest>&& request.

Copy link
Member Author

Choose a reason for hiding this comment

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

All the raw pointers would be converted to shared_ptr/unique_ptr in new PR. In this case, I don't see need to move semantics as <unique_ptr> would anyway transfer the ownership.

{
public:
// Inserts a name/value pair, and removes elements with the same name.
virtual void set(nostd::string_view const &name, nostd::string_view const &value) = 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are the method names lower case here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Will fix this.

enum class HttpResult : uint8_t
{
// Response has been received successfully from target server.
HttpResult_OK = 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

Please conform the the Google C++ Style Guide. Here's the part for enums.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Will fix this.

Copy link
Contributor

@maxgolov maxgolov left a comment

Choose a reason for hiding this comment

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

I'd like to block merging this until we sort out some (minor) legal Q 😄 ... We can continue iterations / discussions on this.

[](const std::string &s1, const std::string &s2) -> bool {
std::string str1(s1.length(), ' ');
std::string str2(s2.length(), ' ');
auto lowerCase = [](char c) -> char { return tolower(c); };
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing std:: before tolower(c);?

Copy link
Contributor

Choose a reason for hiding this comment

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

We may want to use this implementation into some form of header-only common utility class, since the same pattern is being used more than once elsewhere.


// HttpHeaders implementation
class HttpHeaders : http_api::HttpHeaders,
std::multimap<std::string, std::string, decltype(CaseInsensitiveComparator)>
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this std::multimap based on nostd::string_view according to insert() called in add() below?

Copy link
Contributor

@maxgolov maxgolov Sep 2, 2020

Choose a reason for hiding this comment

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

I'd actually advocate again that we can just use std::string here in SDK for the sake of simplicity and compat with older compilers, just using plain standard C++11 (or maybe C++14) classes, so that external components do not have to take a dependency on nostd. There is no ABI stability guarantee for exporters. We discussed it in prior SIG meetings that we are not providing ABI stable interface in SDK, for exporters, and thus, using nostd here is a bit of an overkill.

In short: there is no requirement to use nostd inside the SDK, because there is no ABI-stability requirement/guarantee within the SDK code.

Copy link
Contributor

Choose a reason for hiding this comment

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

We definitely shouldn't store nostd::string_view in the multimap.

There are some slight advantages of using nostd::string_view over std::string as type for parameters in function calls, as this allows users to pass both std::string and const char* without creating an intermediate std::string. But I don't have a strong preference for it in this API, which will not be on a performance critical path.

Copy link
Member Author

Choose a reason for hiding this comment

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

This would be changed in new PR. string_view class won't be used anymore. Although agree on string_view advantage as stated by @pyohannes

};

// The HttpHeaders class contains a set of HTTP headers.
class HttpHeaders
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a place where do use HttpHeaders in API? Does it mean we need to have a transform somewhere from std::multimap<std::string, std::string> used within the SDK - to ABI-safe HttpHeaders implementation used in API surface? Can you provide some concrete example where we require this in API?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see a use case for this in the API.

@lalitb
Copy link
Member Author

lalitb commented Sep 7, 2020

@maxgolov @reyang @pyohannes @ThomsonTan Thank you all for the review comments. I would abandon this PR due to the current non-clarity of the copyright issue as some part is coming from Microsoft's MIT licensed code base. I am in process of re-writing the API and would be raising the new PR in couple of days. I would be respond to relevant comments ( which holds good in new PR too) in this PR before abandon.

@g-easy
Copy link
Contributor

g-easy commented Sep 8, 2020

Need to discuss/review on the location of these headers

Should these headers be in the SDK rather than the API?

IMO the API is just for instrumentation calls and the no-op default implementation thereof.

@lalitb
Copy link
Member Author

lalitb commented Sep 8, 2020

Need to discuss/review on the location of these headers

Should these headers be in the SDK rather than the API?

IMO the API is just for instrumentation calls and the no-op default implementation thereof.

@g-easy Yes, that's the plan for new PR. Would be moving both interface / implementation to SDK.

@jajanet jajanet mentioned this pull request Sep 14, 2020
@reyang reyang added the pr:do-not-merge This PR is not ready to be merged. label Sep 25, 2020
@lalitb
Copy link
Member Author

lalitb commented Oct 20, 2020

Closing for copyright issues, new PR raised : #370

@lalitb lalitb closed this Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:do-not-merge This PR is not ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HTTP client API for exporter developers
6 participants