Skip to content
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

[exporter/kafka] move kafka configures authentication to internal pkg #27289

Merged
merged 1 commit into from
Oct 9, 2023

Conversation

sakulali
Copy link
Contributor

@sakulali sakulali commented Oct 1, 2023

Description:
Move kafka configures authentication to internal pkg, make references become clearer. Additionally, avoid to use export function kafkaexporter.ConfigureAuthentication to pass checkapi.

Link to tracking Issue:
#27093

Testing:
make gotidy
make golint
make crosslink
make multimod-verify
make gendependabot
make genotelcontribcol
make docker-otelcontribcol
go test for kafkaexporter
go test for kafkametricsreceiver
go test for kafkareceiver
go test for internal/kafka

Documentation:

@@ -1097,8 +1102,3 @@ updates:
schedule:
interval: "weekly"
day: "wednesday"
- package-ecosystem: "gomod"
directory: "/receiver/solacereceiver"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this part is removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not deleted it purposely, it
seems make gendependabot do that?

Copy link
Contributor

@fatsheep9146 fatsheep9146 Oct 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest you revert this unrelated change if possible

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I've no idea whether we need to revert this merged PR, as mentioned by @dmitryax below, there are different suggestions.

@@ -103,7 +105,7 @@ func (cfg *Config) Validate() error {
return validateSASLConfig(cfg.Authentication.SASL)
}

func validateSASLConfig(c *SASLConfig) error {
func validateSASLConfig(c *kafka.SASLConfig) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Speaking of validation, how about defining a common validation function for kafka.Authentication in internal/kafka package, which can be reused by kafkametricsreceiver, kafkareceiver and kafkaexporter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds great, it seems duplicate logic
in between validateSASLConfig and configureSASL, maybe we can defining a common validation function as you said :), and we can make a separate issue to follow up

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you help create an issue for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! I am glad to do that, i will make it a few days later since without bringing laptop currently

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you help create an issue for this?

Sorry for delay, #27486

@fatsheep9146
Copy link
Contributor

@MovieStoreGuy @dmitryax could you help review about this pr?

Copy link
Member

@dmitryax dmitryax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @sakulali!

@dmitryax dmitryax merged commit 96d53a2 into open-telemetry:main Oct 9, 2023
83 checks passed
@github-actions github-actions bot added this to the next release milestone Oct 9, 2023
@dmitryax
Copy link
Member

dmitryax commented Oct 9, 2023

I just realized I missed something important thing after merging the PR.

It definitely makes to remove the dependency on the exporter from other components and move the code to a common package, but I don't believe we can move configuration parts to internal package. Doing it, we are making it impossible to setup the kafka components programmatically, which I believe we should allow

cc @atoulme, I don't think checkapi tool should disallow exporting structs used in components configuration.

dmitryax added a commit to dmitryax/opentelemetry-collector-contrib that referenced this pull request Oct 9, 2023
@atoulme
Copy link
Contributor

atoulme commented Oct 9, 2023

Checkapi only checks for functions, not structs.

@sakulali
Copy link
Contributor Author

sakulali commented Oct 9, 2023

I just realized I missed something important thing after merging the PR.

It definitely makes to remove the dependency on the exporter from other components and move the code to a common package, but I don't believe we can move configuration parts to internal package. Doing it, we are making it impossible to setup the kafka components programmatically, which I believe we should allow

cc @atoulme, I don't think checkapi tool should disallow exporting structs used in components configuration.

Thanks for the thorough review @dmitryax! If you believe that moving the configuration to the internal package is not a reasonable approach, should I revert the merged PR and consider placing the configuration in a different package or location? I think that if we place it in the pkg module, it can be used by other repositories as well.

@dmitryax
Copy link
Member

dmitryax commented Oct 9, 2023

Should I revert the merged PR and consider placing the configuration in a different package or location?

No, I think it's not that big of an issue. I see we have other components with config options in the internal package, e.g. k8s ones. Let's see if someone complains after this change :)

I think that if we place it in the pkg module, it can be used by other repositories as well.

Right, pkg would be probably the best location, but we need to export only config structs not helpers like ConfigureAuthentication. So probably we'll have to be split it into two packages.

I'd suggest we handle this generically with other components like kubestats. Probably we should have pkg/config/k8s and pkg/config/kafka. Let's start with an issue and continue discussion there? Maybe it's not something that other folks see importance in having.

jorgeancal pushed a commit to jorgeancal/opentelemetry-collector-contrib that referenced this pull request Oct 9, 2023
…open-telemetry#27289)

**Description:** 
Move kafka configures authentication to internal pkg, make references
become clearer. Additionally, avoid to use export function
`kafkaexporter.ConfigureAuthentication` to pass checkapi.

**Link to tracking Issue:** 

open-telemetry#27093
jorgeancal pushed a commit to jorgeancal/opentelemetry-collector-contrib that referenced this pull request Oct 9, 2023
@sakulali sakulali deleted the chore-kafka-config-auth branch November 2, 2023 13:58
jmsnll pushed a commit to jmsnll/opentelemetry-collector-contrib that referenced this pull request Nov 12, 2023
…open-telemetry#27289)

**Description:** 
Move kafka configures authentication to internal pkg, make references
become clearer. Additionally, avoid to use export function
`kafkaexporter.ConfigureAuthentication` to pass checkapi.

**Link to tracking Issue:** 

open-telemetry#27093
jmsnll pushed a commit to jmsnll/opentelemetry-collector-contrib that referenced this pull request Nov 12, 2023
@vincentfree
Copy link
Contributor

Should I revert the merged PR and consider placing the configuration in a different package or location?

No, I think it's not that big of an issue. I see we have other components with config options in the internal package, e.g. k8s ones. Let's see if someone complains after this change :)

I think that if we place it in the pkg module, it can be used by other repositories as well.

Right, pkg would be probably the best location, but we need to export only config structs not helpers like ConfigureAuthentication. So probably we'll have to be split it into two packages.

I'd suggest we handle this generically with other components like kubestats. Probably we should have pkg/config/k8s and pkg/config/kafka. Let's start with an issue and continue discussion there? Maybe it's not something that other folks see importance in having.

I was just writing an issue about this, I'm trying to simplify a project that I've made by using structs from the collector project directly instead of having the serialize and make my own struct replicating what the project has already created. I'm making something that simplifies the process of configuring the collector for the company I work for, I want to do prefills and have the option for either grpc or kafka. With the core structs for grpc I can just use all for the config structs without any issues which helps me reduce complexity.

With the kafka implementation I find that the Authentication field breaks due to it being in a internal folder. Thus im either stuck at an older version or have to revert to my own struct that implements the same fields as the struct im trying to use from receiver/kafka.

Could we revisit this and move the code to a pkg/ folder instead of internal?
For me it doesn't make a lot of sense hiding one field in a struct making it unusable for others to use in downstream applications.

@wicklander-bryant
Copy link

I just realized I missed something important thing after merging the PR.
It definitely makes to remove the dependency on the exporter from other components and move the code to a common package, but I don't believe we can move configuration parts to internal package. Doing it, we are making it impossible to setup the kafka components programmatically, which I believe we should allow
cc @atoulme, I don't think checkapi tool should disallow exporting structs used in components configuration.

Thanks for the thorough review @dmitryax! If you believe that moving the configuration to the internal package is not a reasonable approach, should I revert the merged PR and consider placing the configuration in a different package or location? I think that if we place it in the pkg module, it can be used by other repositories as well.

I am encountering this very issue. I'm attempting to use the kafka exporter for a custom collector that I'm building and I want to export to AWS MSK, only issue is that I this requires token authentication which I can't configure because the Authentication field is referencing a struct that is in an internal package, see here.

IMHO I think it makes sense to have this authentication logic in /pkg or somewhere that exports it publicly since the publicly exported kafkaexporter config struct references it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants