Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Operator refactor - validation and import cleanup #1356
Operator refactor - validation and import cleanup #1356
Changes from 1 commit
15c6fce
51d5032
3bfd918
7e4015b
74d6ce9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Building off my comment from above, I wonder if we should be doing all of the reporting configuration validation in the cmd/reporting-operator driver function that provides the entry point for this operator, rather than in the constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it can be called from the
cmd
package but it should not be done there. Commands in Kube/OpenShift follow a pattern ofComplete
,Validate
,Run
. We should refactor ours to match and call theIsValidConfig
method in the command'sValidate
method. However we should keep it in new as well to protect against programmatic access to the operator no matter how it's started in the future.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example of the recommended pattern: https://github.com/openshift/oc/blob/a695d74ef1aee9a3f605d38dd8b6fae2062b63fc/pkg/cli/tag/tag.go#L93-L116
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previously we allowed config to be set even if this was set to false. Should we continue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would imagine that makes sense, i.e. rejecting a configuration where you explicitly set TLS-related flags yet disable TLS entirely for the reporting-operator -> presto communications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previously we allowed config to be set even if this was set to false. Should we continue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as my comment below. I think this is fine UX, reject any configurations like this if you're disabling TLS on the reporting-operator side for that component.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previously we stated that one overrides the other. Introducing this will cause explicit failure. Acceptable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure where I land on this validation check. I think it sounds reasonable looking at the codebase and making sure we reject configurations that won't be respected. @bentito any opinion on this validation check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bentito - thoughts on this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading the usage in
start.go
, it seems like this validates the stated usage. If it's Prom import question, they're both just ways of getting at how far back to try to grab Prom data when metering somehow gets out of sync. I thinkPrometheusDataSourceGlobalImportFromTime
has more potential to be pretty awful for cluster workload, but I don't think that's being asked here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just validation of input. Sounds like I can leave it. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will fail if a port is not given - can someone confirm that that is a correct behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gets called on api, metrics, pprof, presto, hive
I think it's valid to make the admin config the port for our API.
Metrics = Prom, has a default, might be ok to not spec.
pprof seems like it has a default port as well, so maybe okay to not spec.
Presto has a default port, might be ok to not spec.
Hive has a default thrift service port as well, so maybe that might not need being requeired to specify either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will remove the calls/tests for apis that have default ports.