Monitoring API: Add Metric server config #2322
Conversation
|
Hello @marioferh! Some important instructions when contributing to openshift/api: |
openshift-ci
bot
added
the
size/XXL
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: marioferh The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
marioferh
force-pushed
the
metrics_server_config_monitoring_api
branch
from
8592b9b to
4a25999
Compare
|
@marioferh: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| // When omitted, this means no opinion and the platform is left to choose a default, | ||
| // which is subject to change over time. | ||
| // +optional | ||
| MetricsServerConfig MetricsServerConfig `json:"metricsServer,omitempty"` |
There was a problem hiding this comment.
Assuming you want to continue with discoverability as in #2148 - you'll want to drop the omitempty.
There was a problem hiding this comment.
This applies throughout the APIs for wherever you want discoverability.
| @@ -77,6 +79,13 @@ type ClusterMonitoringSpec struct { | |||
| // userDefined set the deployment mode for user-defined monitoring in addition to the default platform monitoring. | |||
| // +required | |||
| UserDefined UserDefinedMonitoring `json:"userDefined"` | |||
|
|
|||
| // metricsServer defines the configuration for the Metrics Server component. | |||
There was a problem hiding this comment.
What does this field allow a user to configure about the metrics server component? (i.e why would I, as a user, care to do anything with this field?)
| @@ -77,6 +79,13 @@ type ClusterMonitoringSpec struct { | |||
| // userDefined set the deployment mode for user-defined monitoring in addition to the default platform monitoring. | |||
| // +required | |||
| UserDefined UserDefinedMonitoring `json:"userDefined"` | |||
|
|
|||
| // metricsServer defines the configuration for the Metrics Server component. | |||
| // The Metrics Server provides container resource metrics for use in autoscaling pipelines. | |||
There was a problem hiding this comment.
While I understood what most of this jargon meant, if you are looking to explain what the metrics server does, I would recommend being a bit more verbose. From the metrics-server doc site, this is a pretty good and succinct summary IMO:
Metrics Server collects resource metrics from Kubelets and exposes them in Kubernetes apiserver through Metrics API for use by Horizontal Pod Autoscaler and Vertical Pod Autoscaler.
This gives me, as a user, a bit more context as to why I might care about doing some configuration of this field
| // The Metrics Server provides container resource metrics for use in autoscaling pipelines. | ||
| // When omitted, this means no opinion and the platform is left to choose a default, | ||
| // which is subject to change over time. | ||
| // +optional |
There was a problem hiding this comment.
Explicit mention that the field is optional in the GoDoc. "When omitted" implies that, but I generally prefer being explicit.
| // This configuration allows users to customize how the Metrics Server is deployed | ||
| // and how it operates within the cluster. | ||
| type MetricsServerConfig struct { | ||
| // audit defines the audit configuration used by the Metrics Server instance. |
There was a problem hiding this comment.
What is the "audit configuration"? Why should I care about configuring this?
|
|
||
| // Audit defines the configuration for Metrics Server audit logging. | ||
| type Audit struct { | ||
| // profile specifies the audit log level to use. |
There was a problem hiding this comment.
Could we elaborate here a bit more? To use for what? Why might I care to modify this as a user?
| // for more details about audit logging. | ||
| // | ||
| // +kubebuilder:validation:Enum=metadata;request;requestresponse;none | ||
| // +optional |
There was a problem hiding this comment.
Explicit mention of optional in the GoDoc.
| } | ||
|
|
||
| // AuditProfileType defines the audit policy profile type. | ||
| // +kubebuilder:validation:Enum=none;metadata;request;requestresponse |
There was a problem hiding this comment.
Don't put the enum marker on both the type and the field - pick one or the other. Using both causes an allOf in the OpenAPI schema for the field (see https://github.com/openshift/api/pull/2322/files#diff-2a283f1c7a9ed75159eeb51f06ea88be271d34a335475d4155ea8d8ee364fcb5R66-R76 ) which can end up causing weird behaviors if any drift happens.
| AuditProfileTypeNone AuditProfileType = "none" | ||
|
|
||
| // Metadata - log events with metadata (requesting user, timestamp, resource, verb, etc.) but not request or response body. | ||
| AuditProfileTypeMetadata AuditProfileType = "metadata" | ||
|
|
||
| // Request - log events with request metadata and body but not response body. This does not apply for non-resource requests. | ||
| AuditProfileTypeRequest AuditProfileType = "request" | ||
|
|
||
| // RequestResponse - log events with request metadata, request body and response body. This does not apply for non-resource requests. | ||
| AuditProfileTypeRequestResponse AuditProfileType = "requestresponse" |
| // When omitted, this means the user has no opinion and the platform is left | ||
| // to choose reasonable defaults. These defaults are subject to change over time. |
There was a problem hiding this comment.
Are you actually going to be assigning defaults here?
If we aren't ever going to be configuring defaults for a field, we don't need to put this "no opinion" blurb here.
First PR: #1929
Related: Enhancements Proposal openshift/enhancements#1627