Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial DistributedContext implementation. #92

Merged
merged 23 commits into from
Aug 29, 2019

Conversation

a-feld
Copy link
Member

@a-feld a-feld commented Aug 16, 2019

This PR fixes issue #91 by attempting to implement the distributed context api specification.

The work is based somewhat on the opentelemetry-ruby implementation.

This PR hasn't yet implemented the propagator APIs for DistributedContext. The intent is that when this PR is ready for review a stub will have been implemented for propagators in distributed context.

Copy link
Member

@reyang reyang left a comment

Choose a reason for hiding this comment

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

I've left comments on the parsing logic.
We might want to refer to the draft CorrelationContext spec.

Copy link
Member

@toumorokoshi toumorokoshi left a comment

Choose a reason for hiding this comment

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

IMO the one change needed is to adhere to ABCs for unimplemented APIs.

As an aside, I think #89 and this PR are going to conflict a bit around the context singleton specifically. I think options are:

  1. we merge this PR in and unifying propagator formatters #89 might refactor this context var depending on how that turns out.
  2. we remove the distributedcontext singleton specifically (keep the classes which all look awesome) and have unifying propagator formatters #89 handle adding the appropriate context var.

I'm okay with either. looks great!


from opentelemetry import distributedcontext as dctx_api

_CURRENT_DISTRIBUTEDCONTEXT_CV = contextvars.ContextVar(
Copy link
Member

Choose a reason for hiding this comment

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

I think we should use the existing context object that exists in the API: https://github.com/open-telemetry/opentelemetry-python/blob/master/opentelemetry-api/src/opentelemetry/context/__init__.py

There will be a need to supplement raw contextvars with other mechanisms to support python 3.4 up to 3.7

def get_current_context(self) -> typing.Optional[DistributedContext]:
return self._cv.get(default=None)

@contextmanager
Copy link
Member

Choose a reason for hiding this comment

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

nice!

@a-feld a-feld force-pushed the distributed-context branch 2 times, most recently from 036d8ac to 701fccd Compare August 21, 2019 16:46
@carlosalberto
Copy link
Contributor

I'm wondering if we could keep EntryKey and EntryValue as strings, as we have been simplifying things in other parts of the API (in such case, validation would need to happen in other parts, such as when Entry is created).

@a-feld
Copy link
Member Author

a-feld commented Aug 21, 2019

I'm wondering if we could keep EntryKey and EntryValue as strings, as we have been simplifying things in other parts of the API (in such case, validation would need to happen in other parts, such as when Entry is created).

@carlosalberto That's basically what's happening 😄

EntryKey and EntryValue are effectively strings. The __new__ will return the validated string, avoiding allocation while allowing the interpreter to keep optimizations like string interning.

The benefit of the current approach is that the type checker can ensure that only validated strings are passed into the API while maintaining the optimizations provided by using raw str types.

@carlosalberto
Copy link
Contributor

@a-feld Oh yes! but I was talking of even removing this part - for example, we don't have such class for SpanId, but we simply use ints all over the place. Something to consider (maybe @c24t has some input next week ;) )

(although the checking is indeed very nice!)

@a-feld a-feld marked this pull request as ready for review August 26, 2019 22:48

PROPAGATOR = HTTPTextFormat()


Copy link
Member

Choose a reason for hiding this comment

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

minor: remove extra line

Copy link
Member

@reyang reyang left a comment

Choose a reason for hiding this comment

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

LGTM.

Copy link
Member

@Oberon00 Oberon00 left a comment

Choose a reason for hiding this comment

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

There are a few small things I noticed that should be fixed before merging this.

@Oberon00
Copy link
Member

IMO the one change needed is to adhere to ABCs for unimplemented APIs.

-- @toumorokoshi in #92 (review)

I'm still not so sure about that policy (did we officially decide on it?). But I'm sure we decided that the API package must be usable as no-op implementation without loading any implementation from elsewhere.

Copy link
Member

@mauriciovasquezbernal mauriciovasquezbernal left a comment

Choose a reason for hiding this comment

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

Just some details I found when reading this PR.

UNLIMITED_PROPAGATION = -1

def __init__(self, entry_ttl: int) -> None:
self.entry_ttl = entry_ttl

Choose a reason for hiding this comment

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

Given that currently only NO_PROPAGATION and UNLIMITED_PROPAGATION are allowed should be a check for that?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure there's much value in doing a runtime check for these values, especially considering the intended purpose is to actually support positive integers in the future.

@a-feld
Copy link
Member Author

a-feld commented Aug 28, 2019

@toumorokoshi Your review is pending with requested changes. I'm thinking that option 1 mentioned in the review comment (merge this PR and revisit #89 ) may be the easiest path forward. Thoughts?

@reyang reyang dismissed toumorokoshi’s stale review August 29, 2019 15:48

Discussed in the community meeting, we can follow up in another PR / issue.

@reyang reyang merged commit 12415f9 into open-telemetry:master Aug 29, 2019
@a-feld a-feld deleted the distributed-context branch August 29, 2019 16:14
@reyang
Copy link
Member

reyang commented Aug 29, 2019

@GeorgeJoy FYI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants