Remove Span.Status from API

[iNikem]

It was proposed in open-telemetry/oteps#123 (comment) and subsequent discussion that we should drop Span.Status from the spec. If there is an agreement on that, I can create a PR.

[anuraaga]

There have been many PRs related to errors so would help if you could summarize the current state of what we have if Status is removed. For example, is there a generic way of knowing whether a span is a success or failure? From what I can tell, presence of exception is that, but I'm not sure

[Oberon00]

Other affected areas would be:

1. Semantic conventions: Most will get shorter, but the gRPC one will then need a definition how to transport the status code.
2. Protocol: Since the trace area is declared stable (beta?), these cannot be immediately removed but should probably be marked deprecated.
3. Of course all the language SIGs are affected too.

[Oberon00]

@anuraaga There is no generic way to detect if a span has failed. The status is also not really suitable for this, except if you also consider things such as HTTP 404 as errors.

Still, I think a generic error=true or error=name_of_attribute_with_detailed_info (e.g. error=http.status_code) could be introduced before removing the status iff we can find agreement on such a thing.

Exceptions are not the same as errors. Often a span with at least one exception will be failed, but all of them could be handled too. Also, errors can occur without exceptions.

[iNikem]

Presence of exception does not necessarily mean span was a failure. This was discussed in #697. And I have just discovered that spec does not have any error=true attribute, so something should be proposed to replace status... Not as easy as I thought :)

[iNikem]

The simplest replacement would indeed be generic error=<boolean> field or attribute.

[Oberon00]

Could we create a separate issue for discussing how to indicate errors generically, once status is removed? Or maybe #599 is the place to discuss this.

[iNikem]

I am afraid we cannot just remove status without offering any way to signal that this span signifies an error. The simplest way forward, assuming that we have #697 in its current form, is the following:

• Introduce simple boolean attribute/field error
• Remove status
• Continue a discussion in Add proper error reporting before OpenTelemetry goes GA #599 if need something more

[iNikem]

During todays Errors WG meeting it was agreed:

• To remove Span.status field from API and spec
• To mark Span.status as deprecated in OTLP
• To introduce new boolean field "error" to spec, API and OTLP
• To provide a migration advice to existing customers from status to error

As a separate step to start discussion about adding severity notion to Span reusing log severity concept

[iNikem]

A discussion about severity on Span events is happening in #698

[kbrockhoff]

Just a top level boolean failed field should be enough to identify the Span as having an error should be sufficient as a quick check. If this is true then the span attributes can be checked for further info. The other change that needs to be made is to add a gRPC semantic convention to report gRPC status code since this will now not be in status.