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

Created dry run flag for collector #6445

Conversation

Chinwendu20
Copy link
Contributor

@Chinwendu20 Chinwendu20 commented Oct 30, 2022

Signed-off-by: Maureen [email protected]

Description: Created dry run flag for the collector

Link to tracking Issue: #4613

Documentation: Updated readme of service package but would create an issue on opentelemetry.io to update documentation

@Chinwendu20 Chinwendu20 requested review from a team and codeboten October 30, 2022 20:12
@Chinwendu20
Copy link
Contributor Author

Heyy, just discovered there were some recent changes to the main branch that would affect this PR. I would make some changes and push

Comment on lines 63 to 64
// DryRunGet validates the configuration, prints out all related errors without running the collector
DryRunGet(ctx context.Context, factories component.Factories) (*Config, error, bool)
Copy link
Member

Choose a reason for hiding this comment

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

Should "dry run" be a flag or a command?

/cc @codeboten @jpkrohling who also reviewed #6322

Copy link
Contributor

@codeboten codeboten Nov 14, 2022

Choose a reason for hiding this comment

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

i would expect it to be a flag

Update: after looking at what helm does, i think it should just be a command. I would rename dry-run to verify or validate since that's what we're really asking the command to do here.

dry-run only really applies to the context of a command that would change a state somewhere.

func (cfg *Config) DryRunValidate() {
// Currently, there is no default receiver enabled.
// The configuration must specify at least one receiver to be valid.
if len(cfg.Receivers) == 0 {
Copy link
Member

Choose a reason for hiding this comment

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

Each one of the conditions needs its test to ensure its correctness.


func (ConfigUnmarshaler) DryRunUnmarshal(v *confmap.Conf, factories component.Factories) (*config.Config, error, bool) {
errorcheck := false
if err := v.Unmarshal(&rawCfg, confmap.WithErrorUnused()); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

Using a var that is defined in an unrelated file would be confusing. If you have to use the same var, it might make sense to split this into its own source file.

"go.opentelemetry.io/collector/confmap"
)

type ExtensionValidateError struct {
Copy link
Member

Choose a reason for hiding this comment

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

If those four types have the same definition, perhaps you can have only one? ComponentValidationError would probably be a good candidate here.

Err string
}

var ExtensionValidateErrors []ExtensionValidateError
Copy link
Member

Choose a reason for hiding this comment

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

You can still have four vars, each being a slice of ComponentValidationErrors

@Chinwendu20
Copy link
Contributor Author

Thank you @jpkrohling. I have changed my approach to this problem because of recent changes to the main branch. I currently have it on my local computer and I am about wrapping up with tests. Would push as soon as it is done

@Chinwendu20
Copy link
Contributor Author

Still have to make some changes as recent changes in the main branch has affected my most recent push as well. I will try to finish this one up as fast as possible.

@codecov
Copy link

codecov bot commented Dec 13, 2022

Codecov Report

Base: 90.15% // Head: 90.00% // Decreases project coverage by -0.14% ⚠️

Coverage data is based on head (ac2cbfe) compared to base (55e6fa0).
Patch coverage: 71.92% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6445      +/-   ##
==========================================
- Coverage   90.15%   90.00%   -0.15%     
==========================================
  Files         248      249       +1     
  Lines       14291    14403     +112     
==========================================
+ Hits        12884    12964      +80     
- Misses       1159     1183      +24     
- Partials      248      256       +8     
Impacted Files Coverage Δ
otelcol/command_validate.go 44.00% <44.00%> (ø)
otelcol/collector.go 76.08% <62.50%> (-0.84%) ⬇️
service/config.go 90.68% <80.76%> (-9.32%) ⬇️
otelcol/command.go 66.66% <100.00%> (+1.14%) ⬆️
otelcol/command_components.go 89.28% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@Chinwendu20
Copy link
Contributor Author

Had a working solution earlier today just to find out that there are new changes to the the main branch later today hence this conflict.

@Chinwendu20
Copy link
Contributor Author

So the problem is that I am creating a new function for validate that just prints validation errors when it is encountered as opposed to returning quickly so if there is a change in the implementation of the main validate function I would have to change mine. I do not know if there is a smarter way of going about this

@github-actions
Copy link
Contributor

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

@jpkrohling
Copy link
Member

So the problem is that I am creating a new function for validate that just prints validation errors when it is encountered as opposed to returning quickly

It's okay -- I prefer to have all errors listed instead of failing fast in this case.

if there is a change in the implementation of the main validate function I would have to change mine

Not quite sure what you meant here.

@Chinwendu20
Copy link
Contributor Author

Chinwendu20 commented Jan 13, 2023

So the problem is that I am creating a new function for validate that just prints validation errors when it is encountered as opposed to returning quickly

It's okay -- I prefer to have all errors listed instead of failing fast in this case.

if there is a change in the implementation of the main validate function I would have to change mine

Not quite sure what you meant here.

I am giving a reason why I have had to keep changing my code and why some checks are failing. It is because at the time there were changes to the validate function after submitting my PR. I would go at it again

@github-actions
Copy link
Contributor

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

@github-actions github-actions bot added the Stale label Jan 28, 2023
@github-actions
Copy link
Contributor

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

@github-actions github-actions bot closed this Feb 12, 2023
codeboten pushed a commit that referenced this pull request Jun 7, 2023
This is bringing back the functionality initially submitted in @Chinwendu20's PR: #6445

Adds a validate method which validates the configuration

Link to tracking Issue: #4613

---------

Signed-off-by: Alex Boten <[email protected]>
Co-authored-by: Maureen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants