search

open-telemetry / community

OpenTelemetry community content
https://opentelemetry.io
Apache License 2.0
717 stars 216 forks source link

Project Infrastructure SIG #2096

Open austinlparker opened 1 month ago

austinlparker commented 1 month ago

This proposal creates a new SIG for project tooling, to aid in the maintenance and development of org-wide tools for OpenTelemetry.

svrnm commented 1 month ago

Big +1 for this one and happy to participate.

A question on scope: does "tooling" also include package management (pypi, maven, homebrew, crates, npm, ...) and best practices around them? This is currently owned by the individual SIGs, which should remain that way, but there might be some best practices across them as well we would like to look into (how is code published, by whom, using which mechanism, etc.), which also taps into what SIG security is doing.

austinlparker commented 1 month ago

Big +1 for this one and happy to participate.

A question on scope: does "tooling" also include package management (pypi, maven, homebrew, crates, npm, ...) and best practices around them? This is currently owned by the individual SIGs, which should remain that way, but there might be some best practices across them as well we would like to look into (how is code published, by whom, using which mechanism, etc.), which also taps into what SIG security is doing.

I think we would want to look at what's currently being used, see if there's opportunities for de-duplication, and perhaps provide best practices around things like tooling for secret management or permissions -- but yeah, I think SIGs should continue to manage their own stuff for the most part? That said, the more we can provide 'out of the box' for SIGs the better imo.

trask commented 1 month ago

I think we would want to look at what's currently being used, see if there's opportunities for de-duplication, and perhaps provide best practices around things like tooling for secret management or permissions -- but yeah, I think SIGs should continue to manage their own stuff for the most part

👍

related: #1293

svrnm commented 1 month ago

but yeah, I think SIGs should continue to manage their own stuff for the most part? That said, the more we can provide 'out of the box' for SIGs the better imo.

Similar to what Docs, Security, End-User are doing this is a "SIG-to-SIG Service" approach, some SIGs might be not interested, but some other things would be happy to be taken off the burden to do package management on their own. For some package managers (like homebrew, linux distros, etc.) a centralized approach might also be helpful.

It might not be the first thing this SIG tackles, but I would like to have it as part of the charter. For my day-to-day job I have looked into some of those already (pypi, homebrew, ansible, crates, ...) and also helped to define some best practices, I am happy to provide this here as well.

austinlparker commented 3 weeks ago

Another note/example of a project that would be really swell for this SIG to tackle - an OTLP/JSON validator in the browser to help people figure out why their OTLP may be malformed.

jaronoff97 commented 1 week ago

I would love to help out here given the work we began on this issue! Happy to assist in whatever way i can here.

MSNev commented 4 days ago

As part of semantic conventions there is already a separate Semantic Convention Tooling SIG (7am Wednesdays), this sounds like the same or at least similar.

austinlparker commented 4 days ago

As part of semantic conventions there is already a separate Semantic Convention Tooling SIG (7am Wednesdays), this sounds like the same or at least similar.

There's a different scope for the two SIGs.

MSNev commented 4 days ago

At the very least it seems like what is being proposed is an overall wrapper for what is occurring in that SIG, as we are developing and discussing the "project" tools that every SIG will use for managing not just semantic conventions but also code generation from the semantic conventions. We are also actively looking for additional contributors / maintainers of the project tools being constructed.

MSNev commented 4 days ago

Build Tools: https://github.com/open-telemetry/build-tools/tree/main/semantic-conventions Weaver: https://github.com/open-telemetry/weaver Triage Project board: https://github.com/orgs/open-telemetry/projects/84 Weaver Project board: https://github.com/orgs/open-telemetry/projects/74

austinlparker commented 4 days ago

At the very least it seems like what is being proposed is an overall wrapper for what is occurring in that SIG, as we are developing and discussing the "project" tools that every SIG will use for managing not just semantic conventions but also code generation from the semantic conventions. We are also actively looking for additional contributors / maintainers of the project tools being constructed.

Sure, I'm sure these two SIGs will coordinate, but there's still a need for project-wide sustaining engineering on things other than semconv code gen. If you would prefer that this SIG subsumes the semconv one, that's a possibility, but I feel like it'd make more sense for that SIG to work independently so it's not blocking adoption.

austinlparker commented 1 day ago

LGTM.

Would it be in scope of this new SIG to consider tooling in support of docs processing (of any form, including for tech docs, specs, etc), and their publication via websites?

From reading the proposal here, I'm not sure that such docs-related tooling is in scope, but if it is, I'm willing to contribute. If it's not in scope, that's fine, but IMHO, there might be a need for shared resources for docs.

I think it'd be in scope, yes.