Skip to content
This repository was archived by the owner on May 23, 2023. It is now read-only.

Set the scope_manager RFC to Test.#122

Closed
carlosalberto wants to merge 3 commits intoopentracing:masterfrom
carlosalberto:carlos/scope_manager_test
Closed

Set the scope_manager RFC to Test.#122
carlosalberto wants to merge 3 commits intoopentracing:masterfrom
carlosalberto:carlos/scope_manager_test

Conversation

@carlosalberto
Copy link
Copy Markdown
Contributor

Initial take on the ScopeManager RFC.

Notes:

  • Used 'thread or execution unit' in order to abstract things such as coroutines.
  • Mentioned Scopes are not thread-safe.
  • Mentioned the null the value (it hadn't been mentioned before in the Specification).
  • Light take on the recent start_active_span() vs start_active_scope() debate.
  • Used ScopeManager.active() (as opposed to ScopeManager.activeSpan()). Prone to change based on further discussion.

Please provide feedback ;)

@tedsuo @palazzem @pavolloffay @pglombardo @yurishkuro @jpkrohling @indrekj @mwear @felixbarny @cwe1ss @adriancole

Comment thread specification.md Outdated

There should be no parameters.

**Returns** a `Scope` instance containing the active `Span`, or else `null` if there's none for the current thread or execution unit.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This says it returns a Scope, but the title implies returning a Span.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes, think we should tune that in.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think it should be Scope, regardless the name we have in our implementations.

Copy link
Copy Markdown
Member

@tedsuo tedsuo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM

Comment thread specification.md Outdated

There should be no parameters.

**Returns** the used `ScopeManager` instance to set and retrieve the active `Span`. The mentioned active instance is additinaly used by default as the implicit parent for newly created `Span`s, in case no **references** were provided.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"the active Span" -> "the active Scope"? or in general I think it should be clear that the ScopeManager retrieves a Scope that contains the active Span. Thoughts?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think it makes more sense to make it clear at all moments that Scope objects are being returned/used.

Comment thread specification.md Outdated

This operation does the same as **Start a new `Span`**, in addition to setting the newly created `Span` as the active instance for the current thread or execution unit through the contained `ScopeManager` instance.

It is **highly** encouraged that the name for this operation includes a `Scope` sufix, in order to make clear the type of the returned instance.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scope sufix -> Scope suffix?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name of the method or name of the span?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, method name ;) Will clarify that.

Comment thread specification.md Outdated

### `ScopeManager`

The `ScopeManager` interface sets and retrieves the active `Span`, working along the `Scope` container interface.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to my previous comment. Here I guess the behavior is clear, but I think we may need to change something in the other paragraph.

Comment thread specification.md Outdated

This operation does the same as **Start a new `Span`**, in addition to setting the newly created `Span` as the active instance for the current thread or execution unit through the contained `ScopeManager` instance.

It is **highly** encouraged that the name for this operation includes a `Scope` sufix, in order to make clear the type of the returned instance.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name of the method or name of the span?

Comment thread specification.md Outdated

There should be no parameters.

**Returns** a `Scope` instance containing the active `Span`, or else `null` if there's none for the current thread or execution unit.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to resolve opentracing/opentracing-java#267 before adding this to the spec

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it's more a related effort - as part of this very PR, we need to discuss what is described in #267 (as well as opentracing/opentracing-ruby#36).

But yes, in practical terms, we need to figure those two issues above before finally merging this PR 😉

Comment thread specification.md Outdated

### `Scope`

The `Scope` interface acts as a simple container for the active `Span`,and it not guaranteed to be thread-safe. It has the following capabilities:
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and it not guaranteed

@indrekj
Copy link
Copy Markdown

indrekj commented Oct 11, 2018

Maybe not directly related to this PR but anyway:

The doc explains the behavior of Scope / ScopeManager, but I feel like it's missing the why: Why is scope / scope manager needed? Why wouldn't Tracer#activate(span) :: span work instead? I've been experimenting with opentracing spec for elixir and the scope manager part is confusing to me atm. There's likely an answer in some old PR but it's hard to find it.

I've implemented the scope manager part in ruby zipkin OT and we've used it in production for some time now. So far I haven't encountered a use case where a simple activate(span) :: span & deactivate() without Scope container wouldn't work as well.

@carlosalberto
Copy link
Copy Markdown
Contributor Author

Hey @indrekj @pavolloffay @palazzem @tylerbenson @tedsuo

I've updated the document with minor corrections and updating it based on the latest OT Java iteration (making some operations optional). Let me know.

@carlosalberto
Copy link
Copy Markdown
Contributor Author

Hey @indrekj

Why is scope / scope manager needed?

We essentially the concept has been to separate the active Span handling from the Tracer, API-wise. Now, as we have iterated, the idea has been to provide shortcuts for the most common operations - but stuff is still expected to be in the ScopeManager instance ;)

@carlosalberto
Copy link
Copy Markdown
Contributor Author

Hey all!

I think I've updated all the requested bits of this PR, and I think it's ready to go. If you have some time over the next days, let me know - else I will be merging it soon (remember it's still an ongoing effort and can be changed/updated later).

Comment thread rfc/scope_manager.md
# Scope Manager

**Current State:** Draft
**Current State:** Test
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @carlosalberto,
I think you should not remove two ending spaces here.
They are required to split lines.

When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return.

Currently, you have Current State and Author on the same line.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't a blank line between them do the same? Linters do not like trailing spaces (they even show up as red in git diff).

Alternatively, in this case it's appropriate to us bullet points for the metadata.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't a blank line between them do the same?

No, it wouldn't. The result won't be the same.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linters do not like trailing spaces

I know, but it's an issue of those linters and git.
It's not a Markdown issue.

@yurishkuro yurishkuro closed this May 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants