-
Notifications
You must be signed in to change notification settings - Fork 772
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
[api-logs] Define OTEL1000 & OTEL1001 diagnostics and decorate APIs #4963
Conversation
….Api using .NET8 ExperimentalAttribute.
Codecov Report
Additional details and impacted files@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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. |
docs/diagnostics/OTEL1000.md
Outdated
We are exposing these APIs to solve these issues and gather feedback about their | ||
usefulness. | ||
|
||
## Log Bride API |
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @martinjt fixed 👰♀️ -> 🌉
There was a problem hiding this comment.
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 😏
src/Shared/DiagnosticDefinitions.cs
Outdated
|
||
internal static class DiagnosticDefinitions | ||
{ | ||
public const string UrlFormat = "https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/diagnostics/{0}.md"; |
There was a problem hiding this comment.
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?
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unintended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya
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. |
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. |
Relates to #4433
Changes
OTEL1000
&OTEL1001
.Details
I decided to split things into two categories:
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.