Add feature flagging semantic conventions

[beeme1mr]

Resolves #2532

Changes

Added semantic conventions for representing feature flags as spans. This can be used to determine the impact a feature has on a request.

Related issues

• Semantic Convention for Feature Flagging #2532
• Define OTel Semantic Convention for Feature Flagging open-feature/spec#30

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: beeme1mr / name: Michael Beemer (f1aa873)

[tigrannajaryan]

This needs an issue in this repository (a reference to an issue in another repository is useful but not sufficient) and then follow the issue workflow. Ideally this should have happened before the PR is created so that we know we want it in the OpenTelemetry.

[tigrannajaryan]

This needs an issue in this repository (a reference to an issue in another repository is useful but not sufficient) and then follow the issue workflow. Ideally this should have happened before the PR is created so that we know we want it in the OpenTelemetry.

You can wait a bit and see if there are approvers commenting on this PR who think the PR is a good idea then we can move forward without an issue.

[beeme1mr]

Hi @tigrannajaryan, sorry for not following protocol. I'm happy to close this PR until it has gone through the proper channels. However, I'm not sure what the proper channel is. The contributing doc that you sent says "significate changes" require an OTEP and that small changes can be made directly via a PR. This change seems to fall somewhere in-between those two extremes.

[beeme1mr]

I just noticed that you clarified the process a PR. I'll open an issue tomorrow. Thanks!

[reyang]

May I get a short summary regarding why feature-flagging needs to be part of semantic conventions? Is there an example (I read through the linked issue and couldn't find a clear explanation)?

[dyladan]

May I get a short summary regarding why feature-flagging needs to be part of semantic conventions? Is there an example (I read through the linked issue and couldn't find a clear explanation)?

If feature flag keys and values are consistently reported, it will enable splitting traces and metrics by these values for usecases like A/B testing, feature rollouts, and similar. In order for this to work it must be consistent across all microservices, potentially in multiple languages and/or using multiple feature flag services.

[tigrannajaryan]

Hi @tigrannajaryan, sorry for not following protocol. I'm happy to close this PR until it has gone through the proper channels. However, I'm not sure what the proper channel is. The contributing doc that you sent says "significate changes" require an OTEP and that small changes can be made directly via a PR. This change seems to fall somewhere in-between those two extremes.

@beeme1mr no problem, we need the contributing documentation to be more clear. I think it is fine to keep this PR open.

[reyang]

If feature flag keys and values are consistently reported, it will enable splitting traces and metrics by these values for usecases like A/B testing, feature rollouts, and similar. In order for this to work it must be consistent across all microservices, potentially in multiple languages and/or using multiple feature flag services.

If the user has System X calling into Cloud Provider Y which in turn calls back to System Z, and they use different A/B testing / feature flag system, what would be the expectation? Or this PR is specific about open-features and it's compatible systems, not about other systems?

[dyladan]

If feature flag keys and values are consistently reported, it will enable splitting traces and metrics by these values for usecases like A/B testing, feature rollouts, and similar. In order for this to work it must be consistent across all microservices, potentially in multiple languages and/or using multiple feature flag services.

If the user has System X calling into Cloud Provider Y which in turn calls back to System Z, and they use different A/B testing / feature flag system, what would be the expectation? Or this PR is specific about open-features and it's compatible systems, not about other systems?

They would just report span attributes consistent with the feature flag system they're using. The attributes are general enough to be used with any feature flag system. I'm not sure I see what the problem is.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[dyladan]

This is not stale

[beeme1mr]

Marking this as a draft until #2532 is resolved.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[dyladan]

Not stale

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[beeme1mr]

Still waiting for an official response on #2532

[dyladan]

Updated to add a log version

[beeme1mr]

Hi @tigrannajaryan and @jsuereth, does the recent changes made by @dyladan address your concerns?

[jsuereth]

This answers my main concerns on log/trace usage. Just a minor nit / visibility concern left.

[dyladan]

Can someone with permission please run the link check again? It failed on jsonlines.org which is not a dead link

[dyladan]

Link check is passing locally and appears to be on a file we haven't touched

[dyladan]

@tigrannajaryan @SergeyKanzhelev I think all the feedback has been addressed and there are 5 green approvals. I think this can probably be merged