[chore] Make some internal packages publicly available for importing

[odubajDT]

Component(s)

internal/k8stest
internal/core

Describe the issue you're reporting

There is a existing use-case, where multiple internal functions are used in other non-opentelemetry collector repositories to test custom built collectors which are based on the OTel-collector. To avoid the need to copy over the functions needed to properly test the custom collectors, it would be beneficial to have those functions available publicly outside of the internal package, since in the current state, Golang does not allow importing packages marked as internal.

I would propose to make the following packages publicly available:

• k8stest
• idutils

My suggestion would be the following:

• internal/k8stest -> pkg/k8stest
• internal/coreinternal/idutils -> pkg/core/idutils

Looking forward to your feedback!

[atoulme]

That is very broad, would you please help identify which functions you aim to make reusable?

[odubajDT]

That is very broad, would you please help identify which functions you aim to make reusable?

Basically, we would need most of the functions (if not all) from k8stest package and functions from idutils package. Already adapted the issue description.

Would this be possible?

[odubajDT]

Created PRs how could the change potentially look like, please have a look if you have time

[mx-psi]

What is the use case here?

[odubajDT]

We're building a custom version of the collector with a subset of components with using a custom build-config.yaml.

With this collector we're doing an additional e2e testing for our custom configurations, where in these tests we are using functions from k8stest and idutils packages, which are in the current state copied to the collector repository. It would help us if these packages will be publicly available for importing to avoid copying them.

[braydonk]

Triage: Discussion is underway, removing needs-triage.

[TylerHelmuth]

These packages change enough that I don't really want to worry about our public footprint or breaking changes. Is the functionality specific to something else we do in the collector? Instead of being public can you duplicate them?

[odubajDT]

These packages change enough that I don't really want to worry about our public footprint or breaking changes. Is the functionality specific to something else we do in the collector?

I don't see any breaking changes, nor any functionality changes in the idutils package according to the git history since August 2021. I would consider this pretty stable from this reason.

Regarding the k8stest package, this one exists (as a separate package) since June 2023 (this commit). History here. Outside of maintenance work (dependency bumps, lint adaptations etc,) I found only the following two commits adapting the logic (mostly due to bug fixes and supporting newer version of k8s) here and here

For me as a potential user of the library (when it will be publicly available) it is not an issue to adapt a library twice a year, since we are still trying to have our downstream copy in 100% sync with upstream, which requires more work than dealing with some changes.

Instead of being public can you duplicate them?

In the current state we have them duplicated. We would like to get rid of the duplications.

[atoulme]

idutils is mostly used in conjunction with zipkin and jaeger, and a bit in a load generator. It is probably going to be fine to use, but please add tests and add a metadata.yaml if you expose it, and make yourself codeowner.

No idea about k8stest.