-
Notifications
You must be signed in to change notification settings - Fork 331
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
SetupStaticPublishing and SetupDynamicPublishing returns Tracer with Shutdown function #2566
Conversation
@mgencur: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/retest-required |
Codecov Report
@@ Coverage Diff @@
## main #2566 +/- ##
==========================================
- Coverage 81.40% 81.31% -0.09%
==========================================
Files 163 163
Lines 9740 9753 +13
==========================================
+ Hits 7929 7931 +2
- Misses 1574 1585 +11
Partials 237 237
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
We want to move away from OpenCensus - I don't think we should be returning the concrete type. See: #2561 (comment) |
@dprotaso The downstream repositories are still using OpenCensus.
Anyways, we might end up with different needs. Its hard to predict future.
|
@dprotaso I've pushed a new commit and provided the Tracer type with the generic Shutdown function. WDYT? |
05c76b0
to
94a40f4
Compare
} | ||
return nil | ||
return oct, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to wrap the created object oct
and hide the life cycle management in pkg/tracing other than returning it and delegating the management to other components?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. Components that are creating the tracer will do some work and they need to shutdown the tracer at the end (before their own shutdown). And they do it by calling Shutdown throught the tracing.Tracer interface. So the components will now depend only on the pkg/tracing package.
If you have other thoughts how this could be done please let me know.
There's now knative/eventing#6474 which shows how this would be used.
…acer * The caller can then call Finish() to properly flush buffered Spans before shutdown
Otherwise proceed futher and let globalOct.closer to be closed which actually flushes the remaining Spans.
94a40f4
to
b6902ba
Compare
case <-ctx.Done(): | ||
return ctx.Err() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason why we skip performing the shutdown when the context is cancelled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a common way to allow for interrupting a long running functions through the context. OpenTelemetry uses this approach as well for interrupting the Shutdown function. I don't have a strong opionion about this - we could also keep continuing the shutdown until the end. The context would not be used in this implementation then.
// just ensures that if generated, they are collected appropriately. This is normally done by using | ||
// tracing.HTTPSpanMiddleware as a middleware HTTP handler. The configuration will be dynamically | ||
// updated when the ConfigMap is updated. | ||
func SetupDynamicPublishing(logger *zap.SugaredLogger, configMapWatcher configmap.Watcher, serviceName, tracingConfigName string) error { | ||
func SetupPublishingWithDynamicConfig(logger *zap.SugaredLogger, configMapWatcher configmap.Watcher, serviceName, tracingConfigName string) (Tracer, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are changing the interface and we want to change all the invocation of SetupDynamicPublishing
to SetupPublishingWithDynamicConfig
, could we change to SetupPublishingWithDynamicConfigAndInitialValue
directly? As I reported in issue #2557, SetupDynamicPublishing
does not work properly since it doesn't call oct.ApplyConfig(cfg) at the first time.
If you agree, I think we don't need method SetupPublishingWithDynamicConfig
because we will not use it any more. We just need method SetupPublishingWithDynamicConfigAndInitialValue
.
@dprotaso your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since knative/eventing#6456 is not yet implemented and SetupDynamicPublishingWithInitialValue
is not referenced yet I think it makes sense to do this:
- Keep the current PR as it is and only have the latest/newest
SetupPublishingWithDynamicConfigAndInitialValue
- If the current PR is merged soon enough the new function can be used directly in a PR for knative/eventing
- If there is a PR for knative/eventing merged before the current one I will put back the backwards-compatible function here so as to not break downstream
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, mgencur The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
FYI - |
@dprotaso @daisy-ycguo Thanks for reviews and merging! |
…acer
before shutdown
This is incompatible change that will require updates in many repositories. I can either prepare those PRs so that they can be merged when this change propagates to those repositories or I can keep the old implementation and also provide a new impl that returns the OpenCensusTracer. Whatever works best.
Initially, I will provide an example PR for knative/eventing that will show the required updates.
Changes
/kind enhancement
Fixes #2475
Release Note
Docs