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

use faas.instance instead of faas.id in gcp detector #4198

Merged
merged 7 commits into from Sep 5, 2023

Conversation

dashpole
Copy link
Contributor

Context: GoogleCloudPlatform/opentelemetry-operations-go#679

faas.id is being removed in newer versions of the semantic conventions. faas.id is meant to be the URI of the google cloud resource (e.g. projects/my-project/locations/us-central1/functions/my-function), but we were using it to store the instance id.

The correct resource attribute to use in this case is the faas.instance attribute, which has the description:

The execution environment ID as a string, that will be potentially reused for other invocations to the same function/function version.

That matches what the instance ID is in GAE, Google Cloud Run, and Google Cloud Functions.

Since faas.id has been removed, we will need to undergo a breaking change regardless. It is probably better to do so now, rather than wait until contrib is updated.

@dashpole dashpole requested a review from a team as a code owner August 14, 2023 18:19
@codecov
Copy link

codecov bot commented Aug 14, 2023

Codecov Report

Merging #4198 (22d9b30) into main (53f4e7e) will increase coverage by 0.0%.
The diff coverage is 100.0%.

Impacted file tree graph

@@          Coverage Diff          @@
##            main   #4198   +/-   ##
=====================================
  Coverage   79.4%   79.4%           
=====================================
  Files        166     166           
  Lines      10363   10363           
=====================================
+ Hits        8230    8233    +3     
+ Misses      1998    1996    -2     
+ Partials     135     134    -1     
Files Changed Coverage
detectors/gcp/detector.go 100.0%

Copy link
Contributor

@MrAlias MrAlias left a comment

Choose a reason for hiding this comment

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

Given this is a stable detector, is there something we need to do according to the semconv world to provide backward compatibility here?

@dashpole
Copy link
Contributor Author

I think this would be covered by https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#semantic-conventions-stability. It says:

Changes to semantic conventions in this specification are allowed, provided that the changes can be described by schema files.

That would seem to imply we are required to publish a schema file with this detector describing the change. But then it also contradicts that with:

There is a moratorium on relying on schema transformations for telemetry stability.

Each language implementation MUST take these versioning and stability requirements, and produce a language-specific document which details how these requirements will be met. This document SHALL be placed in the root of each repo and named VERSIONING.

It does say we are bound by our VERSIONING.md file in otel-go. The otel-go versioning policy doesn't seem to say anything about detectors except that they are a module, and follow semver.

We shouldn't have made this package stable given it implements the detection experimental semantic conventions, but that ship sailed... Options I can think of:

  1. Stay on the current version of the semantic conventions ~forever
  2. Release a v2 of the package with the change
  3. Deprecate the existing NewDetector function, and add a new function that uses newer semantic conventions
  4. Make the breaking change with the rationale that it maintains API stability.

Copy link
Contributor

@MrAlias MrAlias left a comment

Choose a reason for hiding this comment

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

Moving forward with option (4) based on SIG discussion

@dashpole
Copy link
Contributor Author

Discussed in the Sig meeting. We will go with option 4. We need to update to not break users: #4261 (comment).

@dustinmoris
Copy link

What's delaying the merge of this PR at this point?

CHANGELOG.md Outdated Show resolved Hide resolved
dashpole and others added 2 commits September 5, 2023 10:08
Co-authored-by: Robert Pająk <pellared@hotmail.com>
@MrAlias MrAlias added this to the v0.43.1 milestone Sep 5, 2023
@MrAlias MrAlias merged commit 417fc12 into open-telemetry:main Sep 5, 2023
27 checks passed
@dashpole dashpole deleted the fix_gcp_faas branch September 5, 2023 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants