[Refactor] Refactor common code between all benchmark commands#1611
[Refactor] Refactor common code between all benchmark commands#1611ruflin wants to merge 8 commits intoelastic:mainfrom
Conversation
There is quite a bit of duplicated code across all the benchmark commands. This is a first quick take on bringing it together. Initially I wanted to only refactor 1-2 functions but one lead to the next things. I am pushing this now to get early review from others, this is not complete / not fully tested. Also potentially now that the refactoring is bigger, likeyl the best place of the common files has become a different place.
|
@ruflin so far all good for me |
| Corpora corpora `config:"corpora" json:"corpora"` | ||
| } | ||
|
|
||
| // TODO: Why is this slightly different from the common fields? |
There was a problem hiding this comment.
@aspacca You might know more here? And the one below?
There was a problem hiding this comment.
the data required for both data_stream and corpora configuration is different between system benchmarks and rally/stream ones.
specifically: rally/stream does not require data_stream.vars and corpora.input_service
since I "duplicated" both structs used to unmarshal the yaml configuration in the rally/stream packages that I added, I removed the fields that were not required.
it is fine to have this two structs only in the common package as well, with all the fields currently defined in the system package (ie: the "version" we have in this file). the packages where the fields are not required will just not access them. there's no impact on the specs from the underlying structs that are used to unmarshal the yaml.
the only caveat is that what can happen is that someone could add data_stream.vars or corpora.input_service in a configuration where they are not required and provide a value that cannot be unmarshalled. in this case we cannot simply ignore/not access the not required fields, the user has to remove them.
There was a problem hiding this comment.
Got it, I for now remove the 2 TODO mentions, we can always follow up on this.
💚 Build Succeeded
History
cc @ruflin |
jsoriano
left a comment
jsoriano
left a comment
There was a problem hiding this comment.
Looks good, thanks for the refactor! Added some nitpicking and waiting for Andrea's review.
| // or more contributor license agreements. Licensed under the Elastic License; | ||
| // you may not use this file except in compliance with the Elastic License. | ||
|
|
||
| package common |
There was a problem hiding this comment.
Nit. common seems too generic, could this go directly in the internal/benchrunner/runners package? Or to an internal/benchrunner/scenario package?
There was a problem hiding this comment.
@aspacca Any thoughts?
| return nil, fmt.Errorf("error loading scenario: %w", err) | ||
| } | ||
| scenarios[scenarioName] = scenario | ||
| } else { |
There was a problem hiding this comment.
Nit. I think we can remove the else to have one less nesting level.
| } else { | |
| return scenarios | |
| } |
There was a problem hiding this comment.
See my comment above, happy to follow up further code changes but now trying to focus on only moving things around, no logical changes.
| return c, nil | ||
| } | ||
|
|
||
| func ReadScenarios(path, scenarioName, packageName, packageVersion string) (map[string]*Scenario, error) { |
There was a problem hiding this comment.
Nit. Do we have any benefit on returning scenarios as a map? Returning a list would help controlling the order of execution and results. Scenario could have a field for the name.
| func ReadScenarios(path, scenarioName, packageName, packageVersion string) (map[string]*Scenario, error) { | |
| func ReadScenarios(path, scenarioName, packageName, packageVersion string) ([]*Scenario, error) { |
There was a problem hiding this comment.
@jsoriano I would prefer to delay code changes to a different PR. The reason is for this PR I only moved code around, not type / logic change to make sure the refactoring does not affect any of the logic.
|
@lalit-satapathy This should have been a quick one around code cleanup. Unfortuantely I didn't manage to fully follow up so there are now conflicts. Hopefully nothing major to resolve. |
5 participants
There is quite a bit of duplicated code across all the benchmark commands. This is a first quick take on bringing it together.
Initially I wanted to only refactor 1-2 functions but one lead to the next things. I am pushing this now to get early review from others, this is not complete / not fully tested. Also potentially now that the refactoring is bigger, likeyl the best place of the common files has become a different place.