Parent is now always passed in via Context, intead of Span or SpanContext

[codeboten]

Description

As per the spec change open-telemetry/opentelemetry-specification#875, the parent must always be passed via a Context.

Fixes #1139

Type of change

Please delete options that are not relevant.

• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been updated
• Documentation has been updated

[toumorokoshi]

one non-blocking comment on variable naming. I think it's probably one that needs to be addressed, but don't want to stop progress if I don't catch up to this PR.

[toumorokoshi]

I guess this type validation is still valuable. But practically speaking, this would only be an issue if someone directly manipulates the context, and doesn't use the API functions.

Is that a common enough case to even catch here?

Alternatively I suppose this is cheap enough.

[toumorokoshi]

I'm wondering if the variable is worth renaming. "parent" was vague to begin with, and if you look at any descriptions of how tracing works, one would immediately think "parent" refers to the span (since you specifically call the span a child of the parent span).

This would also be useful to rename since new API users will get exceptions when their existing code passes an argument as parent. Rather than get a new slightly confusing error ("why is the API now rejecting this previously valid value?"), they will get an argument not supported error, and look up the docs to see the variable changed.

parent_context is the first thing that comes to mind, but I worry a user would get it confused with the parent SpanContext.

[codeboten]

@toumorokoshi yeah I had a similar thought around the name. Looking at some of the other implementations, it appears parent and parent_context are the current names used. I'm happy to change it to parent_context as it's at least a bit more meaningful than parent. The alternative i can think of would be to just call it context

[toumorokoshi]

Either sounds great!

[ocelotl]

I'd say context is the better name. A Context object passed in this argument may or may not contain a parent Span, making the name parent_context less accurate and context_with_or_without_the_parent_span is a bit long.

[codeboten]

Thanks for the feedback, went with context.

[lzchen]

Now that there is the concept of a Context being passed into span start, I'm wondering if it is valuable to rename span.get_context() to span.get_span_context() to avoid confusion. I know that the Context isn't actually a PART of Span, it probably is only here (during start and use) that it would be confusing. Thoughts?

[lzchen]

And maybe even renaming the variable from parent_context to parent_span_context.

[toumorokoshi]

I would +1 on "get_span_context", although with open-telemetry/opentelemetry-specification#1033 that might not even be necessary.

[codeboten]

I renamed get_context to get_span_context and parent_context to parent_span_context where it made sense. I tested the water with renaming context in the Span to span_context and it turned out to be pretty messy. Not sure if it's worth the rename on that one. Thoughts @lzchen & @toumorokoshi?

[toumorokoshi]

I think that's fine, I don't know if I have a strong opinion on the attribute name on the span.

And I'm completely comfortable with taking these PRs piecemeal too.

[ocelotl]

Just some minor comments

[ocelotl]

I'd say context is the better name. A Context object passed in this argument may or may not contain a parent Span, making the name parent_context less accurate and context_with_or_without_the_parent_span is a bit long.