Clarify what to do on non-reversible telemetry schema downgrades

[mx-psi]

On the specification for telemetry schemas an example is provided where a piece of telemetry is downgraded from 1.2.0 to 1.1.0 or upgraded from 1.0.0 to 1.1.0. It is therefore implicit in the example that telemetry schemas transformations must allow both upgrades and downgrades.

However, the currently published 1.8.0 transformation rules do not allow for an unambiguous downgrade, at least with the information in the schema file:

opentelemetry-specification/schemas/1.21.0

Lines 123 to 129 in 7b6de1f

	1.8.0:
	spans:
	changes:
	- rename_attributes:
	attribute_map:
	db.cassandra.keyspace: db.name
	db.hbase.namespace: db.name

Here, two attributes, db.cassandra.keyspace and db.hbase.namespace were merged into db.name, and therefore in the presence of telemetry data using db.name with a schema newer than 1.7.0 it is not possible to determine how to downgrade this attribute to 1.7.0 or lower. Note that it may be possible to do such downgrade by considering the value of db.system, but this is not specified in the schema file.

This kind of two-to-one renaming also does not seem to be explicitly forbidden by the specification:

opentelemetry-specification/specification/versioning-and-stability.md

Lines 233 to 239 in 4229197

	Changes to semantic conventions in this specification are allowed, provided that
	the changes can be described by schema files. The following changes can be
	currently described and are allowed:
	- Renaming of span, metric, log and resource attributes.
	- Renaming of metrics.
	- Renaming of span events.

since this change can be described by a telemetry schema file, even if it is not reversible (this relates to #3513).

There are therefore three open questions:

1. Should we introduce restrictions on renaming such as "telemetry schema defined transformations should be unambiguous"?
2. What should a schema-aware backend or the Collector processor do to handle this edge case?
3. Should the 1.8.0 rule even be there if it's not compliant with the specification?

[mx-psi]

This is explicitly mentioned in the OTEP:

The only exception is when 2 or more different attributes in the previous version are renamed to the same attribute in the new version. In that case the reverse transformation is not possible since it would be ambiguous. When the reverse transformation is not possible it is considered an incompatible change. In this case the MAJOR version number of the schema SHOULD be increased in the new version.

IMO we should explicitly state this as part of the rules that govern what changes we allow on semantic conventions, and also specify the behavior for backends/processors that support this when running into this edge case.

[mx-psi]

Relates to #2680 (for questions 1 and 3, 2 is not addressed by it)

[pyohannes]

The only exception is when 2 or more different attributes in the previous version are renamed to the same attribute in the new version. In that case the reverse transformation is not possible since it would be ambiguous. When the reverse transformation is not possible it is considered an incompatible change. In this case the MAJOR version number of the schema SHOULD be increased in the new version.

IMO we should explicitly state this as part of the rules that govern what changes we allow on semantic conventions, and also specify the behavior for backends/processors that support this when running into this edge case.

The problem actually runs much deeper. Given a simple non-conflicting transformation:

1.8.0: 
   spans: 
     changes: 
       - rename_attributes: 
           attribute_map: 
             db.cassandra.keyspace: db.name

db.name is an existing attribute, so when doing a reverse transformation you can't just rename all db.name keys to db.cassandra.keyspace (as db.name is used across all databases).

So basically, any transformation that transform an attribute key to another already existing attribute key is practically non-reversible.

[tigrannajaryan]

We have a couple options:

• Enforce what the OTEP says: bump major version number when changes like this are introduced. Too late for 1.8.0 but we can start enforcing it for future changes.
• Don't bump major version number and override OTEP's decision (it is currently described in an "Experimental" doc in the spec, so we are free to change it). It is already possible to infer it is a non-reversible change. Unclear what the extra utility of major version number change is (clearer message?).

What should a schema-aware backend or the Collector processor do to handle this edge case?

When a non-reversible change happens the Collector can't transform the schema to the previous version. The simplest approach is to detect and do nothing. The data remains unchanged and the SchemaURL remains the same as it was. Whoever is the consumer of the data will have to deal with the fact that the Collector may leave some of the data untransformed.

[tigrannajaryan]

db.name is an existing attribute, so when doing a reverse transformation you can't just rename all db.name keys to db.cassandra.keyspace (as db.name is used across all databases).

So basically, any transformation that transform an attribute key to another already existing attribute key is practically non-reversible.

Good observation. The opposite case of this is already covered by a prohibiting policy here.