search

open-telemetry / opentelemetry-python-contrib

OpenTelemetry instrumentation for Python modules
https://opentelemetry.io
Apache License 2.0
733 stars 606 forks source link

Instrumentation acceptance policy and general guidelines for external instrumentation authors #1714

Open srikanthccv opened 1 year ago

srikanthccv commented 1 year ago

We don't have a formal written policy for this yet. As a SIG, we have decided not to accept instrumentation unless there is a solid reason. We should have a written policy.

dacevedo12 commented 1 year ago

what is considered a 'solid reason'?

srikanthccv commented 1 year ago

It's probably not phrased correctly, but we have yet to write a clear policy to convey that. We have in the past and continue to push for either adding the instrumentation directly into the library https://github.com/starlite-api/starlite/pull/796, https://github.com/faust-streaming/faust/issues/382 or outside this repo. There is no need for everything to be put here. The packages maintained outside can always be added to the registry https://opentelemetry.io/ecosystem/registry/ to make them discoverable by a large audience.

dacevedo12 commented 1 year ago

Just out of curiosity, is this a policy that all of OTel is on board with or is it just OTel python at the moment?

I've submitted a couple of PRs here (and was planning for more) to try to get OTel python stronger vs the number of instrumentors other languages have, so it would be a shame to close them and delay delivering value to other Pythonistas in the look of better observability.

Totally understand and respect the decision though. If this policy is to be enforced from now on, I'll close my PRs and try to contribute them directly to the libraries instead.

lzchen commented 1 year ago

@dacevedo12 Hey thanks for taking an interest in contributing to Otel Python. This policy was decided internally by the OT Python team. I believe a few other languages have adopted it in practice but it has never been formalized. Currently we are very short on maintainers and approvers so an ever-growing list of instrumentations is a difficult maintenance burden. Coupled with the fact that there has been several instances of contributors contributing an instrumentation that none of us are familiar with, leaving us with having to support libraries in which we do not have expertise in. We have tried to circumvent this with component_owners but it does not seem that many people are interested in continuous support.

Thanks for being an active contributor.

srikanthccv commented 1 year ago

Adding to what @lzchen said, There is no formal all OTEL level policy about this. I don't think such will exist in future. The maintainers of the subgroups have followed some policies that help them manage better. The go-contrib maintainer's team has had one such policy for a long time https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation#new-instrumentation; the collector-contrib does something similar where new component requires a sponsor and any inactivity from the code owner gets the package removed from the distro https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#adding-new-components. These are two SIGs I personally know. There may be other SIGs that have something similar.

The component owners initially agree to provide continuous maintenance but do not keep the agreement after some time, and we have to take the maintenance ownership. There are several instances of this but here is one such instance https://github.com/open-telemetry/opentelemetry-python-contrib/pull/1655#issuecomment-1437446547, https://github.com/open-telemetry/opentelemetry-python-contrib/pull/1655#issuecomment-1448257000

dacevedo12 commented 1 year ago

I'd like to bring up this topic again to check if there have been any changes.

There are several open PRs that would be affected by this decision. It would be nice for the contributors to receive opportune feedback, closing the PRs and letting them know so they can start working on instrumentations elsewhere.

Thanks,

kennytrytek-wf commented 1 year ago

@srikanthccv, could you respond to the latest comment from @dacevedo12? If any of these pull requests are going to be denied, it is not worth our effort to continue to work on them here, and that effort would be better spent moving the implementation to another repository.

srikanthccv commented 1 year ago

I am no longer part of the maintainer's group so I will let @lzchen , @ocelotl comment on this.