Define/clarify ownership of go.opentelemetry.io

[dmathieu]

This follows last week's incident on go.opentelemetry.io.
This incident was caused by the newly added CAA DNS entry which prevented Google AppEngine from renewing the certificate.

We're looking into ways to avoid this kind of issues from happening again, and an unknown we have is "who owns that service?".
It seems the de-facto folks currently owning this are the ones in CODEOWNERS, which is @open-telemetry/go-maintainers and @open-telemetry/collector-maintainers.

However, we see two ownership levels for this service:

• Ownership of the data the service serves. The packages handled there, and the repository they point to.
• Operations ownership, stability of the app and its hosting.

While we thing each SIG using a package should have ownership of the canonical URL provided here (👋 @open-telemetry/ebpf-profiler-maintainers @open-telemetry/collector-contrib-maintainers @open-telemetry/go-instrumentation-maintainers @open-telemetry/ebpf-instrumentation-maintainers ), we're not so sure we are the rightful owners for the operations of this app.

Last week's incident happened because a DNS entry was added to the root of the opentelemetry.io domain.
If the Collector and Go SIGs have ownership of operations, we would like to be able to monitor every DNS change that happens at that level, so we can be on the lookout for potential issues.
We also don't have the bandwidth to do so, and don't necessarily want to go through that noise.

We therefore wonder whether it would make sense to have ownership transition to the comms SIG (I'm not finding any GitHub team), and possibly the @open-telemetry/governance-committee (as owners of the admin keys).

Right now, this app is a snowflake, as it runs on AppEngine, and as far as we know, there is no other app within the OTel org that does the same.
We're looking into moving to netlify to streamline the app.
But feedback on this move is was prompted this discussion, as moving platforms for the sake of technology is a good step, but not as important as clarifying who owns what and ensuring we are not forgotten when DNS changes like the one that caused this incident happen.

[pellared]

This seems to be currently under the responsibility of @open-telemetry/governance-committee.
From the Governance Committee charter:

Establish processes regarding other project resources/assets, including artifact repositories, build and test infrastructure, web sites and their domains, blogs, social-media accounts, etc.

It also states:

GitHub repository management, membership, and hosting.

I’m not sure what “hosting” means in the context of GitHub, and I think it would be good to clarify.

Personally, I’m not convinced it’s ideal for the Governance Committee to own these technical aspects of OpenTelemetry.
In my view, the @open-telemetry/governance-committee role is closer to product management, while the @open-telemetry/technical-committee role is engineering management.
It seems more natural for engineering-related concerns (security, operations, infrastructure, etc.) to be owned by the TC, with the GC focusing more on product-level direction like defining and prioritizing the roadmap for OpenTelemetry.

[trask]

Establish processes regarding other project resources/assets, including artifact repositories, build and test infrastructure, web sites and their domains, blogs, social-media accounts, etc.

I think the key phrase here is "Establish processes regarding ...", which doesn't mean owning the technical aspects.

That said, ownership for all OpenTelemetry assets is (or at least should be) defined in assets.md. It's pretty adhoc in terms of who volunteers to own what.

As an open source project, managing operations of production services is definitely challenging (I just commented the same in another context).

We're looking into open-telemetry/opentelemetry-go-vanityurls#87 to streamline the app.

This sounds like a great idea and would then naturally fall under the same ownership as Netlify.