Add more tests, fix compliance to semantics

[alertedsnake]

Description

A whole bunch of reworking the tests

I've updated tests to use proper handler names - In the real world, the interceptor is always going to be passed a HandlerCallDetails object with the method field set to something valid... previously these tests set this to an empty string, but that's not what happens in a real case. So I've updated the tests to do that right, but also made sure that the span processing allows this to be unset, just in case someone was expecting this behavior to be present.

I've added more checks into the existing tests, now we're checking that span attributes are set as expected.

Fixed a few bugs in the tests where things which were intended to be checked, actually were not.

And finally, I've added a test to catch the gRPC abort() and verify the error status in the span.

Updated status codes to be compliant with specifications

The previous PR I made had the gRPC status codes using the English names for the status, but the spec has been clarified to require the integer value.

Also, the specs say to not use span.set_status() for a non-error condition, so I've added a check for that in a few places.

Added additional attributes

Also as the spec has been clarified, I've added the rpc.method and rpc.service attributes.

Fixes #173
Fixes #139

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

As most of this is either test changes or changes covered by new or existing tests, I've just run a bunch of tests :)

Does This PR Require a Core Repo Change?

• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[alertedsnake]

(And now replying properly with my real github account)

Confirmed a slight issue - I'm setting the span.status.description field to the error description, but it seems that's expected to be type: detail in the case of an exception, which is a bit harder to do with gRPC, since any abort is raised as a bare Exception even when it isn't technically. I suppose I could make this end up something like StatusCode.NAME: description (with name and description set appropriately).

Anyone know where the canonical doc on that format is?

This shows up because of this line here: https://github.com/open-telemetry/opentelemetry-python-contrib/blob/master/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py#L252

I did notice #154 and was pondering tackling that as well, so if this is considered an error, I can fix it there instead :)

[alertedsnake]

Ah, I know what to do, hang on.

[alertedsnake]

I should mention that the lint test runs fine locally...

[toumorokoshi]

This shows up because of this line here: https://github.com/open-telemetry/opentelemetry-python-contrib/blob/master/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py#L252

I think this is just an incorrect assumption that was made because the default exception handling logic in the SDK is to format the exception that way.

Really exceptions should be recorded as events, so the datadog_exporter should actually use that to extract it instead.

The python code already does this.

I'd recommend for now just modifying the datadog_exporter to not make that assumption, and filing a bug against it so it can be fixed in the future.

What do you think?

[toumorokoshi]

LGTM! IT would be great if you could file that issue on the dd exporter, but all of your changes are correct and technically the DD issue could occur regardless of merging this change in.

[toumorokoshi]

I should mention that the lint test runs fine locally...

regarding this, have you updated your version of PIP? There's a new version that now has strict ordering and also results in detecting conflicting dependencies consistency. I see the linting failing because of install conflicts, at the CI probably updates to the latest version of pip every time.

I see this in the tox lint output:

ERROR: Cannot install opentelemetry-exporter-datadog[test]==0.17.dev0 and opentelemetry-exporter-prometheus-remote-write[test]==0.16.dev0 because these package versions have conflicting dependencies.

The conflict is caused by:
    opentelemetry-exporter-datadog[test] 0.17.dev0 depends on opentelemetry-api==0.17.dev0
    opentelemetry-exporter-prometheus-remote-write[test] 0.16.dev0 depends on opentelemetry-api==0.16.dev0

I think you just need to rebase your commit to fix that. your branch has 16.dev0 as the prometheus writer version. head of the main branch looks to be 0.17.dev0.

[alertedsnake]

I think you just need to rebase your commit to fix that. your branch has 16.dev0 as the prometheus writer version. head of the main branch looks to be 0.17.dev0.

Oh! That's a good clue, thanks for catching that, I'll try it.

[alertedsnake]

I'd recommend for now just modifying the datadog_exporter to not make that assumption, and filing a bug against it so it can be fixed in the future.

What do you think?

Good call. I've already started working on the Datadog exporter to add metrics (#154), so I'll file an issue and then fix it while I'm in there.

[alertedsnake]

Good call. I've already started working on the Datadog exporter to add metrics (#154), so I'll file an issue and then fix it while I'm in there.

https://github.com/open-telemetry/opentelemetry-python-contrib/blob/master/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py#L182

Ooh boy, got my work cut out for me :)