Make collector flag functions public to allow collector builders to use them

[dashpole]

This is the set of public changes required for #4977. After that, we need to wait for a release before making changes in that PR.

Part of #4967

[codecov]

Codecov Report

Merging #5130 (9e4d0c7) into main (699a81b) will decrease coverage by 0.05%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##             main    #5130      +/-   ##
==========================================
- Coverage   89.96%   89.91%   -0.06%     
==========================================
  Files         183      183              
  Lines       11104    11106       +2     
==========================================
- Hits         9990     9986       -4     
- Misses        889      894       +5     
- Partials      225      226       +1     

Impacted Files	Coverage Δ
service/flags.go	82.14% <60.00%> (-6.32%)	⬇️
service/command.go	82.35% <100.00%> (ø)
model/internal/pdata/common.go	93.54% <0.00%> (-0.72%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 699a81b...9e4d0c7. Read the comment docs.

[bogdandrutu]

I have a philosophical question: Who is the user of the "Flags" API? Do we want to support the use-case where users are writing their own "main" func, or we support only the use-case where they use the builder?

[jpkrohling]

Do we want to support the use-case where users are writing their own "main" func, or we support only the use-case where they use the builder?

I see the builder as one user that writes its own main func. Users may use the builder once and adapt the generated source code for their needs.

[neelayu]

This change is needed for collector distributions relying on custom config provider MustNewConfigProvider

[bogdandrutu]

@neelayu we have an issue to allow custom providers and did 80% of that work already.. Next reason :)

[bogdandrutu]

@jpkrohling

I see the builder as one user that writes its own main func. Users may use the builder once and adapt the generated source code for their needs.

So the builder should/can generate that file as well? We should not offer that in our "distributed" modules.

[neelayu]

@bogdandrutu Are you talking about this PR #4936?
If yes, then will you add the default overwrite properties provider which accepts flags since this one is designed with functional options?

[jpkrohling]

So the builder should/can generate that file as well? We should not offer that in our "distributed" modules.

People can use the builder to create their own distributions. The recommendation is to just use a manifest file and let the builder generate the sources and compile a binary, but I do see how people would be interested in just generating a bootstrap code and adapt it from there. This is why we have the option "--skip-compilation". In fact, we have something similar for the contrib repository: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/otelcontribcol

[bogdandrutu]

@jpkrohling correct... but do we want to support the use-case where they manually write all the files?

[jpkrohling]

but do we want to support the use-case where they manually write all the files?

We do not want to support the conflict resolution between the generated sources and the customizations, but we want to support the source code generation, especially if users find it easier to check the manifests vs. the main.go file. As a developer of a downstream distribution, I would probably isolate my changes outside of the generated files, perhaps just adding a line or two to call my custom func defined elsewhere. Otherwise, I wouldn't see the point in generating the main func.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.