Friendly reminder we have
otel spec issue scrub 🧽 mtg on Friday morning 8:30a PDT.
We also have 2 outstanding P1
prioritylabel on purpose so it does not muck with reports of existing issue tracking of changes to the spec. essentially, i copied the line items from google sheet OpenTelemetry GA Planning to github project OpenTelemetry GA High Level Items so they can be tracked in github with assignees and status across linked github issues to other language SIGs. i’ll take a few minutes at the spec sig mtg tomorrow to give quick summary about these issues and how they will be tracked, but i’ll go over more detail in depth at the next maintainers meeting.
@tigrannajaryan @bogdandrutu from the topic of our last collector SIG mtg, i’m looking for a timeslot to triage the 148 collector issues. to keep friendly with european timezone, trying for early morning pacific time. i can suggest 2 windows of times:
we’ll likely need several sessions to make a dent in the number of issues. do either/both of these times work? if so, i can setup a zoom call. else, propose an alternative time to work towards.
repeated int64 ..., but it won't. since that is the case it would be better for us to just send non-homogenous arrays in attributes because otherwise we have to scan every list of attributes added to a span and check the "type" (have no types, so also a pain)
Friendly reminder we have
otel spec issue scrub 🧽 mtg tomorrow, Friday morning 8:30a PST.
Currently, our 3 outstanding P1
After a Span is ended, it usually becomes non-recording and thus IsRecording SHOULD consequently return false for ended Spans. Note: Streaming implementations, where it is not known if a span is ended, are one expected case where IsRecording cannot change after ending a Span.
When implementing this and writing the End method to set the recording state, how do I tell if the span is in a streaming implementation or not?
Don't set the span status description if the reason can be inferred from http.status_code.
Following on from our collector SIG issue scrub meetings from last week, we’ve completed:
Thanks to those who attended (see sig mtg doc).
Keeping the momentum, I propose 2 more sessions this week:
Which I’ll add to the otel calendar tomorrow with same people as invitees unless there is a more suitable time slot I should schedule.
@jsuereth here is where the spec says metric labels and span attributes must have identical meanings: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/common/common.md#recommendations-for-opentelemetry-authors
Semantic conventions exist for four areas: for Resource, Span and Log attribute names as well as Metric label keys. In addition, for spans we have two more areas: Event and Link attribute names. Identical namespaces or names in all these areas MUST have identical meanings. For example the http.method span attribute name denotes exactly the same concept as the http.method metric label, has the same data type and the same set of possible values (in both cases it records the value of the HTTP protocol's request method as a string).
Appreciate your support for the below issue,
I built my open telemetry demo as the below steps,
Thanks for your time and consideration.
otel spec issue scrub 🧽at 8:30a PST, so we could use the remaining time to go over the metrics issues. i’ve added to the agenda cc @jmacd