Proposal: Add a version semantic attribute

[austinlparker]

This proposes a resource (or sub-resource) that can identify the version of another resource.

[tigrannajaryan]

The Resource currently allows to specify arbitrary key/value pairs. Is there a need to have Version as a structured element rather than as a key/value pair with a pre-defined key value such as "version"? I am curious as to how version is different than other defining attributes of a resource.

[tigrannajaryan]

Why not "semver": "1.0.0"?

[z1c0]

Is this meant in addition to existing resource objects?
e.g.

{
	"type": "container",
	"labels": {
           ....
	},
       "version" : {
       ....
       }
}

(example from OpenCensus: https://github.com/census-instrumentation/opencensus-specs/blob/master/resource/Resource.md#exporter-translation)

[austinlparker]

The biggest rationale I had for making the Version a structured element was to support the notion that there can be multiple types of version strings that may have different meaning to a consumer. For example, it's quite frequent to tag releases in cloud native systems with their git SHA rather than a semver string.

That said, I think it'd also work to simply say version is a key on each resource and any string can be set as the value, at which point it'd be incumbent on a backend to figure out ways to differentiate between them.

[toumorokoshi]

Regardless of the medium, I think version will play a big factor, especially in metrics.
Working through the problem myself I was thinking Resource would be a great place to put it, considering it's a static context collection that's available to reference.

I feel like if it's going to be defined in the spec, we should have some clear uses cases. What will this RFC enable us to do?

[yurishkuro]

@austinlparker there's a simpler way to achieve that with just the version attribute of the resource - by using a naming scheme, e.g. version=semver:1.2.3 or version=git:8ae73a.

I am curious if the type of version actually matters, i.e. what exactly would one do differently knowing that the version is semver vs. git sha?

[bogdandrutu]

For TC members please vote:
I am proposing to "rejected" this otep based on the suggestions from #38 (comment).

@bogdandrutu @yurishkuro @carlosalberto @SergeyKanzhelev

[austinlparker]

I'd rather modify it per Yuri's comments, they make sense.

[bogdandrutu]

@austinlparker that will become a simple semantic convention for the version resource label or Span attribute

[austinlparker]

Yes, but wouldn't changes to semantic conventions also go through the RFC process?

[bogdandrutu]

I would say this is a very simple change that I would be happy to just review in the specs repo.

My 2c: Let's try to keep a balance between what is required in RFC vs a small change/improvement in specs.

[austinlparker]

I originally brought this up in the spec repo and it was suggested as an RFC (see open-telemetry/opentelemetry-specification#235). If y'all want it to go back there fine, but other people are making refs to this.

[bogdandrutu]

Disclaimer: I am pretty new in the RFC model, but my understanding is that RFC are required when some important and complicated changes are proposed. Not trying to say that this is not important, but it becomes a very simple change if we follow Yuri's comment.

[bogdandrutu]

In the current form I am happy to approve this, but I feel that you did a lot more work to get some minor change in the semantic conventions. I would like to hear others opinion, but don't want to block your work because I think it is good work.

[yurishkuro]

I recommend changing this to APPROVED status, to reduce friction.

[carlosalberto]

Looks fine to me either way - probably we should do as @yurishkuro says and approve it to reduce friction, and try to have this kind of relatively straightforward changes as Specification Issues instead (for the next times, that is).

Probably we could also add a small note on that, as part of the RFC process docs?

[austinlparker]

assigned 0038 and marked as approved per comments

[bogdandrutu]

Can we please get this reviewed by one more approver?

[tigrannajaryan]

LGTM