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

[api-logs] Define OTEL1000 & OTEL1001 diagnostics and decorate APIs #4963

Merged
merged 22 commits into from
Dec 8, 2023

Conversation

CodeBlanch
Copy link
Member

@CodeBlanch CodeBlanch commented Oct 18, 2023

Relates to #4433

Changes

  • Added diagnostic definitions for OTEL1000 & OTEL1001.
  • Decorated experimental log APIs in OpenTelemetry.Api using the new .NET 8 ExperimentalAttribute.

Details

I decided to split things into two categories:

  • OTEL1000: LoggerProvider & LoggerProviderBuilder
  • OTEL1001: Log Bridge API

I did that because I think we may want to release the first category stable before the other. More details can be found in the md files I added.

@CodeBlanch CodeBlanch requested a review from a team October 18, 2023 21:35
docs/diagnostics/OT1000.md Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented Oct 19, 2023

Codecov Report

Merging #4963 (749ee6e) into main (93fd7d3) will decrease coverage by 0.09%.
The diff coverage is n/a.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4963      +/-   ##
==========================================
- Coverage   83.42%   83.33%   -0.09%     
==========================================
  Files         297      297              
  Lines       12380    12380              
==========================================
- Hits        10328    10317      -11     
- Misses       2052     2063      +11     
Flag Coverage Δ
unittests 83.33% <ø> (-0.09%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
...c/OpenTelemetry.Api/Logs/LogRecordAttributeList.cs 68.14% <ø> (ø)
src/OpenTelemetry.Api/Logs/LogRecordData.cs 100.00% <ø> (ø)
...nTelemetry.Api/Logs/LogRecordSeverityExtensions.cs 100.00% <ø> (ø)
src/OpenTelemetry.Api/Logs/Logger.cs 100.00% <ø> (ø)
src/OpenTelemetry.Api/Logs/LoggerProvider.cs 100.00% <ø> (ø)
...rc/OpenTelemetry.Api/Logs/LoggerProviderBuilder.cs 100.00% <ø> (ø)

... and 7 files with indirect coverage changes

@github-actions
Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Oct 28, 2023
@CodeBlanch CodeBlanch changed the title [api-logs] Define OT1000 & OT1001 diagnostics and decorate APIs [api-logs] Define OTEL1000 & OTEL1001 diagnostics and decorate APIs Nov 1, 2023
@github-actions github-actions bot removed the Stale Issues and pull requests which have been flagged for closing due to inactivity label Nov 2, 2023
We are exposing these APIs to solve these issues and gather feedback about their
usefulness.

## Log Bride API
Copy link
Member

Choose a reason for hiding this comment

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

I'm fairly confident you mean "bridge" not "bride"

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks @martinjt fixed 👰‍♀️ -> 🌉

Choose a reason for hiding this comment

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

I'm fairly confident you mean "bridge" not "bride"

Way to ruin a perfectly serviceable proposal to the logging API 😏


internal static class DiagnosticDefinitions
{
public const string UrlFormat = "https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/diagnostics/{0}.md";
Copy link
Member

Choose a reason for hiding this comment

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

Maybe consider an index page?

https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/experimentat-features/README.md#{0}

This would allow us to delete the individual md files as experimental features are released or perhaps abandoned. The index page could still contain the master list of features over time and the links to could be adjusted as necessary to a prior tag.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think we could ever delete one. Because some shipped code out there will still be pointing to it. All we can do is update say the OTEL1000.md file to note at the top (something like): "This was released as stable in vX.Y.Z and is no longer marked experimental going forward." Or perhaps: "This feature was completely removed in vX.Y.Z and is no longer available going forward."

Should we have individual files or one big one? 🤷 Seems easier to maintain them individually but not sure about that.

Looks like StyleCop has 3 levels. An index showing the categories. An index for each category. And then individual files. When I get a warning from StyleCop in VS (just tested CA1311) it links me directly to the individual file.

Copy link
Member

Choose a reason for hiding this comment

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

I envisioned there would still be individual files, but they could be deleted and links on the index page could be updated to point to a prior permalinked tag/commit. I too noted that codes for other things (stylecop/xunit/csharp), typically link to a dedicated page. Main reason I was considering a different approach is that experimental features are typically short lived. Though no strong opinion 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.

OK you convinced me this was useful so I implemented it. Take a look at latest and LMK. I also renamed things from "Experimental Feature" to "Experimental API" in the code & docs. I thought that would help differentiate these from the experimental features we typically hide behind envvars.

Copy link
Member

Choose a reason for hiding this comment

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

Cool, looks good! Though bear with me through a little more bikeshedding...

I think the name of the folder diagnostics may get confused with other things. I suggest an organization like:

docs/
└── codeanalysis/
    ├── experimental-apis/
    │   ├── index.md
    │   ├── OTEL1000.md
    │   └── OTEL1001.md
    └── some-future-category/
        └── OTEL2000.md

Copy link
Member Author

Choose a reason for hiding this comment

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

@alanwest I pushed some updates. To browse it check out: https://github.com/CodeBlanch/opentelemetry-dotnet/tree/api-log-diagnostics/docs/diagnostics

I kept the "diagnostics" folder (didn't rename to "codeanalysis") and I used "README"s instead of "index"s but otherwise I did what you suggested.

@@ -9,6 +9,8 @@
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<!-- Suppress warnings for repo code using experimental features -->
<NoWarn>$(NoWarn);OTEL1000;OTEL1001</NoWarn>
Copy link
Member

Choose a reason for hiding this comment

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

We discussed in our meeting a few weeks back anticipating some code taxonomy. A few points of reference for further discussion:

They both take the approach that every 100 or 1000 codes represent a new category of warnings/errors. We could do similar. Another option would be to use a different prefix specifically for feature flags since unlike normal codes, they're ephemeral e.g., OTELFF or something.

I have no strong opinions, just sharing additional thoughts.

Copy link
Member Author

Choose a reason for hiding this comment

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

I have been thinking about this but so far haven't come up with anything super useful. We could always just say the 1XXX codes are for experimental features and use other codes (eg 2XXX) for some future category?

@@ -48,4 +48,3 @@ services:
- GF_FEATURE_TOGGLES_ENABLE=traceqlEditor
ports:
- "3000:3000"

Copy link
Member

Choose a reason for hiding this comment

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

unintended?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ya ☹️ I had this file modified locally for a demo I was doing and it got included. I can't seem to get the diff to eliminate it completely.

Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Nov 26, 2023
@github-actions github-actions bot removed the Stale Issues and pull requests which have been flagged for closing due to inactivity label Nov 30, 2023
Copy link
Contributor

github-actions bot commented Dec 7, 2023

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Dec 7, 2023
@github-actions github-actions bot removed the Stale Issues and pull requests which have been flagged for closing due to inactivity label Dec 8, 2023
@CodeBlanch CodeBlanch merged commit f5c1160 into open-telemetry:main Dec 8, 2023
78 checks passed
@CodeBlanch CodeBlanch deleted the api-log-diagnostics branch December 8, 2023 17:31
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.

8 participants