[v2 schema] Decide what public Attribute Groups are and how they work in the weaver model.

[jsuereth]

Today, we have some very important parts of Semantic Conventions that we haven't figured out how to use in weaver's model going forward.

code.*, exception.*, thread.* are attributes that may be attached to any log or span. Today they are defined as raw attribute_group with no signal attached. These are already generated by OpenTelemetry instrumentation, relied on by users and too useful to ignore.

We need to sort out how we will model these going forward in V2 schema, particularly:

• What should live-check do when encountering a signal with these extra attributes?
• Will we allow these attribute groups on metric signals?
• Will we allow these attribute groups on entities? If yes Are they descriptive?
• Should emit place these attributes on all spans/events it generates?
• How would "out of the box" codegen interact with these attributes?
  • Will we allow "typesafe" Span/Event creation to allow extra attributes?
  • Will we require "allowed attribute groups" defined per-signal?
• How do we want documentation of attribute groups to work going forward? Can we just keep it as is (current plan)

[lmolkova]

What should live-check do when encountering a signal with these extra attributes?

If these attributes are explicitly referenced on the signal - nothing. If they aren't - issue info advice.
No special treatment necessary

Will we allow these attribute groups on metric signals?

Yes, why not? they'd explicitly appear in metric definition as any other metric attributes.

Will we allow these attribute groups on entities? If yes Are they descriptive?

Yes, you can refine whether they are descriptive or identity.
I think the question is whether this is a group-ref property or an attribute-ref property. Any reason to limit it to group-property?

Should emit place these attributes on all spans/events it generates?

No, only if the group is explicitly referenced on a specific signal

How would "out of the box" codegen interact with these attributes?

Basic codegen should think about these attributes as any other referenced attribute.
Complex codegen would need to treat them as a single type with nested properties. Are we ready to define this? no!

The TL;DR:
Do we know exactly how public groups will be used? No, except for docs
Will we need more logic around them in the future, especially for codegen? Yes

The proposal:
Let's allow signals to reference public groups in the same way as private groups. As a result, it's just a set of attributes. It should not block us from evolving smart codegen to leverage grouping, adding types on top and so on.

[jsuereth]

Will we allow these attribute groups on metric signals?
Yes, why not? they'd explicitly appear in metric definition as any other metric attributes.

Stability - adding attributes onto a metric can break existing alerts. This is why we're more strict on attribute additions in our stability rules for metrics than other signals.

For context my question is do we allow these attributes to be seen on metrics without an explicit ref_group, the way we would want for things like thread or exception on spans/events.

[lmolkova]

Stability - adding attributes onto a metric can break existing alerts. This is why we're more strict on attribute additions in our stability rules for metrics than other signals.

Good point. If metric includes a public group, we should not be able to add a new attribute to that group (unless it's opt-in). It raises a good question of whether it makes any sense at all to even allow referencing public groups on metrics.

For context my question is do we allow these attributes to be seen on metrics without an explicit ref_group, the way we would want for things like thread or exception on spans/events.

I think we don't want to show arbitrary public attribute groups without explicit references on any of the signals.

So what I'm proposing is that public attribute groups have no special meaning except being sets of attributes and being public (in the current iteration). The actual meaning would come if and when we get to the type system.

[jsuereth]

The actual meaning would come if and when we get to the type system.

I think it's a matter of when right now, we just have bigger fish to fry.

Ok - let's keep public attribute groups as a "organization only" aspect you can use for docs for now, and I'll update the documentation and comments as such. We should revisit this as we good to expose the right model. I hope we can do so without it being "breaking" change, but I don't envision any problems right now.