Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ted Young
    @tedsuo
    Probably the biggest question that has come up: version the API and SDK together, or separate? Separate would make semver cleaner, but makes a hash out of git tagging in our repos. Separate versions would imply separate repos... but I’m reluctant to propose that as I don’t want to be murdered by a mob. Life seems so much better when it is all in one repo...
    Ted Young
    @tedsuo
    Two other questions have come up. One is the location of “core plugins” like OTLP, jaeger, prom, etc. It seems to me that everything except for OTLP and trace-context would be better served by living in contrib, and getting bundled in as a distro, rather than living in core as part of the SDK. Again, don’t want to create churn, but this does seem like something that would be reasonable to address.
    Ted Young
    @tedsuo

    Last question that keeps popping up is a request for some kind of minimum required deprecation period before removal can take place. I’m reluctant to pick a number out of the air.

    Perhaps a better approach would be to decide how long we are willing to fully support a v1.0 branch of OpenTelemetry before even considering something like a v2.0. But, again, there should be some kind of rationale to the number we pick, and I currently do not have one.

    In general, I would prefer that we get creative about adding new functionality and better interfaces in v1.0, rather than contemplate a v2.0 at this time. But we do have to say something about a timeframe, or the question will continue to come up.

    Ted Young
    @tedsuo
    Otherwise, it looks like things are shaping up well! I’d like to schedule a meeting for Friday morning, 9am Pacific, to resolve any outstanding issues that may block approval. OTEP approvers, please let me know what you need to see addressed for approval tomorrow.
    Daniel Dyla
    @dyladan

    @tedsuo I am a strong proponent of allowing the sdk and api versions to diverge. As far as putting the API in a separate repo, I don't think that's required but I am also not strongly against.

    One is the location of “core plugins” like OTLP, jaeger, prom, etc. It seems to me that everything except for OTLP and trace-context would be better served by living in contrib, and getting bundled in as a distro, rather than living in core as part of the SDK.

    Anything the spec says we MUST have, I think should be in the core repo. Good example is the jaeger propagator. In order to satisfy the environment variable configuration spec, the sdk must depend on it. If it lives in contrib, then you have a case where the core repo depends on a module in contrib which seems backwards to me.

    But we do have to say something about a timeframe, or the question will continue to come up.

    I think if we say something along the lines of "All major versions will be supported for at least 3 years from initial (x.0.0) release, and at least 1 year from the latest minor (x.y.0) release" then we are being clear that it will be supported, while also not closing the door on the idea of a 2.0 in that timeframe. If we want to release a 2.0 while 1.0 is still in the promised support period, we simply have to maintain both. This serves the (i believe positive) purpose of dissuading us from trying to get trigger-happy with major version releases.

    Tristan Sloughter
    @tsloughter
    I thought about separate versioning and decided it'd be too confusing to have major bumps in the SDK. because then you have the Spec version, API version (all 1.x) and SDK some later major version
    I wanted to do it since then we wouldn't need an experimental SDK to house metrics, but worry it is too confusing
    Ted Young
    @tedsuo
    I think that if you can keep the versions the same, that is great. But it’s becoming clear that it should not be a requirement.
    Ted Young
    @tedsuo
    @dyladan I’m not sure if the MUST language automatically means those plugins should be treated differently, just that they must exist. But I’m thinking about this more from the perspective of ownership, and whether moving Prometheus out of the core would make it easier for a “Prometheus SIG” to form around managing the prom algorithms across languages. I don’t think we need to address this as part of the versioning work, but it is something I see coming up.
    Ted Young
    @tedsuo
    Basically, what is our approach to expanding the number of people who can maintain OTel, without having to expand the number of core maintainers, or end up with a bottleneck on reviews, etc.
    Daniel Dyla
    @dyladan
    I'm all for expanding ownership, but the spec states that you should be able to configure some subset of exporters and propagators using environment variables. That implies those exporters and propagators should be shipped with the default sdk. I think the core repo should contain everything needed to implement the spec
    Tristan Sloughter
    @tsloughter
    good point
    Daniel Dyla
    @dyladan
    Anything not required by spec could easily be moved to contrib and we could have looser ownership/maintainership rules around contrib repos than core repos maybe?
    Ted Young
    @tedsuo
    Good point about env vars. Maybe another approach would be to use directory-based CODEOWNER rules. So a prom SIG could have more management abilities about that portion.
    Daniel Dyla
    @dyladan
    github only respects CODEOWNERS entries where the owner has write access to the repo
    Ted Young
    @tedsuo

    Right. I think the question is, would it be feasible to give write access of portions of core to additional maintainers, so they can focus on things like prometheus support, without needing to give them full write access to the entire repo. Or would that just be stressful and difficult for the primary language maintainers.

    To be clear, I’m just spitballing ideas right now, so let me back up a bit.

    I get a sense that maintainers are having to write a lot of code right now, which leaves less time for code review, which makes it harder to parallelize. I’d like to understand how maintainers are feeling about their workload, and focus on improvements to our org structure in the new year.

    If I could materialize more people by snapping my fingers, what type of people would y’all want? And what would make it difficult to manage additional help?

    5 replies
    Ted Young
    @tedsuo
    Thanks good feedback, please keep it coming :)
    Ted Young
    @tedsuo
    For partial write access, I believe setting a branch to protected with the “require review from code owners” would work. You can then assign teams to be code owners of certain directories, and they will not be able to commit code to any other portion of the repo without approval from the primary maintainers.
    (I believe we are currently doing this for the spec)
    Ted Young
    @tedsuo

    /@all FYI, one more meeting about versioning, tomorrow morning at 9:00am pacific. Please attend if you can.
    When: 9:00am Pacific, Dec 11th
    Where: https://zoom.us/j/8203130519
    OTEP: open-telemetry/oteps#143

    I have one more round of edits I will get in before then, to reflect the latest discussion.

    Ted Young
    @tedsuo
    /@all open-telemetry/oteps#143 is now ready for approval.
    Latest changes:
    • Separate versions for API, SDK, Conventions, and Contrib
    • Long term support for prior major API versions, for three years.
    Tristan Sloughter
    @tsloughter
    how are others attaching resources from detectors? my understanding from the spec is that resources are attached to Providers, but I wouldn't want to have to run the detectors multiple times... am I reading it wrong or are implementations doing detection before providers are created so they can be passed in as part of the Provider configuration (instead of the detectors themselves)
    Daniel Dyla
    @dyladan
    JS runs detectors before constructing providers
    Tristan Sloughter
    @tsloughter
    ok, so all providers have the same resources?
    Daniel Dyla
    @dyladan
    it would be possible to construct them with their own resources, but for the average user who runs with the defaults yes
    Tristan Sloughter
    @tsloughter
    ok, thanks
    Tristan Sloughter
    @tsloughter
    the reasonto have contrib in a separate repo is so more users can be added with writable roles, right?
    Tristan Sloughter
    @tsloughter
    also, can I get an opentelemetry-erlang-contrib repo created :). I never remember who to ask, guess I'll ping bogdan next week if no one who can do it sees this before then
    Tristan Sloughter
    @tsloughter
    is there a way to kick the "easycla" check? It is stuck in this PR open-telemetry/opentelemetry-erlang#175
    Bartlomiej Obecny
    @obecny
    @tsloughter yes close and reopen this PR, these are just 2 quick clicks and it will retrigger the check.
    Tristan Sloughter
    @tsloughter
    oh, thanks, for some reason I guess I assumed the original PR opener would have to reopen, so I didn't try that
    worked perfectly :)
    Ted Young
    @tedsuo
    Looks like I will be a few minutes late for the meeting this morning
    Daniel Dyla
    @dyladan
    Sorry about the end of the meeting there my mic was dead

    I wanted to get the opinions of the other maintainers on how to handle errors in the API or in the setup process. Currently in JS the logger is an SDK-only concept, so we typically do all of our error handling in the SDK or in some API cases we do the no-op behavior. But when we do have errors in the API, how do we want to handle them? Seems we have 3 options:

    1. throw
    2. log to console
    3. an api-level logger

    Throwing obviously runs the risk of crashing the program, but if there is an error in the setup code this may be the correct behavior. Logging to console can also break end-user applications in less obvious ways. If a program reads the output of another program and we change that output, we can break the application which is reading the output. Creating an API-level global logger seems like the correct choice to me, but there is no spec for logging in the API

    John Watson
    @jkwatson
    In Java we're thinking of creating a API-level logger with a standard name that can be used for this stuff, but at the moment, it's not uniform and is just logged using the built-in java logging subsystem with no real coherent naming scheme to the loggers.
    Anthony Mirabella
    @Aneurysm9
    In Go we have an API-level ErrorHandler interface, with a default implementation that logs to STDERR, and a Handle(error) function that invokes the globally-registered ErrorHandler
    Daniel Dyla
    @dyladan
    we have a similar global error handler in js but it is sdk-level
    maybe moving it to the API is the way to go
    Tristan Sloughter
    @tsloughter
    hm, good idea making in configuratable, then if the user wanted they could crash the program if setup fails, but the default is to just log.
    Daniel Dyla
    @dyladan
    is this a behavior that should be spec'd and standardized?
    I am not excited about exposing a new method from the API package for logging and/or error handling without specification blessing.
    Tristan Sloughter
    @tsloughter
    there is an error handling spec of some sort in the specification, but maybe it doesn't cover bootup?
    Daniel Dyla
    @dyladan
    The error handling doc suggests to catch errors globally and use sane defaults
    The error handler example in that doc is sdk-specific
    since most errors will happen in the SDK, this is fine for most things. But the problem we're specifically trying to solve is errors regarding setting up the SDK and registering it with the API.
    specifically, what should happen if you try to register a global tracer provider when one has already been registered?
    1. throw - may crash program
    2. nothing - may be confusing to users
    3. log - changes output of program, may break some things
    4. some new error handling interface
    5. replace old tracer provider with new - maybe confusing or unexpected behavior
    Bartlomiej Obecny
    @obecny
    with regards to point 3 I'm hesitant to say that logging should never break any program and we can't do anything especially in node.js, using console.log / error etc.
    John Watson
    @jkwatson
    Is Monday's meeting still on? It's a national holiday in the US, so I'm sure many of the folks in the US won't be there.