Update assembler.yml to add EDOT docs

[theletterf]

Adding opentelemetry to the assembly list.

[theletterf]

@bmorelli25 @Mpdreamz This adds the EDOT docs to the Reference section, first level, as agreed (I believe).

I'd like to get both of your approvals before moving forward. The sooner we get the existing docs live, the better, but we can decide when to do it.

[theletterf]

+CC @mlunadia @akhileshpok

[Mpdreamz]

LGTM are we good on the path_prefix being /reference/edot I personally think /reference/opentelemetry is better ?

[Mpdreamz]

@KOTungseth @shainaraskas I wonder if we need a docs-content://reference/opentelemetry landing page that can act as the /reference/opentelemetry landing page.

That way we can nest Elastic Distributions of OpenTelemetry (EDOT) as a child of that under /reference/opentelemetry/distributions and maybe update its navigation title to Elastic Distributions

That way the navigation would be

OpenTelemetry
   Elastic Distributions

Which will allow us to perhaps nest ECS/Semantic Conventions and other OpenTelemetry initiatives in the future.

As suppose to having EDOTs as top level.

[theletterf]

That's interesting. For context:

• OpenTelemetry is the upstream, open source tooling and semantic conventions. We use it and contribute to it, but we don't own it. If the first level of resources is meant to contain general areas, it'd be OK.

• EDOT are OpenTelemetry distributions. We own and maintain them. Conceptually, they're similar to Logstash, APM agents, etc. I've heard we'd like to pull those up to the first level. If that's the case, I'd use EDOT instead of OpenTelemetry.

In any case, given the strategic importance of OTel, I'd rather have it as a first level item in the Reference nav.

[Mpdreamz]

See comment on PR.

[Mpdreamz]

That's interesting. For context:

OpenTelemetry is the upstream, open source tooling and semantic conventions. We use it and contribute to it, but we don't own it. If the first level of resources is meant to contain general areas, it'd be OK.

EDOT are OpenTelemetry distributions. We own and maintain them. Conceptually, they're similar to Logstash, APM agents, etc. I've heard we'd like to pull those up to the first level. If that's the case, I'd use EDOT instead of OpenTelemetry.

In any case, given the strategic importance of OTel, I'd rather have it as a first level item in the Reference nav.

I am still advocating for OpenTelemetry to be top level but I wonder if OpenTelemetry will encompass more then our current Distributions in the future.

E.g ECS <=> Semantic Convention mappings, new Security efforts?, centralized config.

[theletterf]

I am still advocating for OpenTelemetry to be top level but I wonder if OpenTelemetry will encompass more then our current Distributions in the future. E.g ECS <=> Semantic Convention mappings, new Security efforts?, centralized config.

Good point, yes. If we don't mind OpenTelemetry having only a child for now, then I'd say to go for it!

Edit: (I don't know if I should edit the navigation and assembler files differently in that case.)

[shainaraskas]

I don't know enough about the OTel roadmap to know if we need to make room for nesting. However, if the URLs wouldn't be impacted, we could also just nest it when we have other stuff to talk about, so we don't have an empty overview page and only one child in the short term.

[Mpdreamz]

if the URLs wouldn't be impacted,

They would be, since /reference/opentelemetry is now claimed by the elastic/opentelemetry repos.

I'm happy to asssume all opentelemetry documentation will live there moving forward in which case the url structure would not be impacted.

[theletterf]

I don't know enough about the OTel roadmap to know if we need to make room for nesting.

I can think of several things we could host under OpenTelemetry that are not EDOT:

• Conceptual docs about OpenTelemetry and Elastic
• Hosted Collector documentation
• Configuration and management features
• OTel Integrations
• Migration guides for LogStash, Beats, etc.
• ECS to OTel

@bmorelli25 May I go ahead and merge?

[colleenmcginnis]

Are we ready to implement the redirects from the old GitHub pages docs to these new docs? In my opinion, we should do both things as close together as possible to prevent user confusion around which docs to look at. I'm not sure if that's a blocker, though.

[theletterf]

Shouldn't be much of a blocker in the sense that having the good links live would help us implement and test the remaining redirects in a short time frame, but I agree with you that these should happen close, and with EAH going on that's not possible. So I'm putting this one on hold while I open the redirects PR for the old docs and possibly a PR for Kibana links (if any).