-
Notifications
You must be signed in to change notification settings - Fork 690
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
Update ContourConfig definitions #4292
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4292 +/- ##
==========================================
- Coverage 78.34% 77.78% -0.56%
==========================================
Files 113 112 -1
Lines 10196 10030 -166
==========================================
- Hits 7988 7802 -186
- Misses 2025 2045 +20
Partials 183 183
|
With the current spec as I write this, applying a blank ContourConfiguration object: apiVersion: projectcontour.io/v1alpha1
kind: ContourConfiguration
metadata:
namespace: projectcontour
name: blank2
spec: {} will get you this: apiVersion: projectcontour.io/v1alpha1
kind: ContourConfiguration
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"projectcontour.io/v1alpha1","kind":"ContourConfiguration","metadata":{"annotations":{},"name":"blank2","namespace":"projectcontour"},"spec":{}}
creationTimestamp: "2022-01-24T05:07:57Z"
generation: 1
name: blank2
namespace: projectcontour
resourceVersion: "461305830"
uid: 791c3e8e-8d65-4788-9ed2-1b9e2259badb
spec:
debug:
kubernetesLogLevel: 0
logLevel: info
enableExternalNameService: false
envoy:
cluster:
dnsLookupFamily: auto
defaultHTTPVersions:
- HTTP/1.1
- HTTP/2
health:
address: 0.0.0.0
port: 8002
http:
accessLog: /dev/stdout
address: 0.0.0.0
port: 8080
https:
accessLog: /dev/stdout
address: 0.0.0.0
port: 8443
listener:
tls:
minimumProtocolVersion: "1.2"
useProxyProtocol: false
logging:
accessLogFormat: envoy
metrics:
address: 0.0.0.0
port: 8002
network:
adminPort: 9001
service:
name: envoy
namespace: projectcontour
health:
address: 0.0.0.0
port: 8002
httpproxy:
disablePermitInsecure: false
metrics:
address: 0.0.0.0
port: 8002
xdsServer:
address: 0.0.0.0
port: 8001
tls:
caFile: /certs/ca.crt
certFile: /certs/tls.crt
insecure: false
keyFile: /certs/tls.key
type: contour |
c6ff0af
to
64531e7
Compare
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.
Added a few specific comments but probably due for an in-person discussion
// Defines the XDSServer to use for `contour serve`. | ||
// +kubebuilder:validation:Enum=contour;envoy | ||
// | ||
// Values: `contour` (default), `envoy` | ||
// | ||
// Other values will produce an error. | ||
// +kubebuilder:default=contour | ||
// +optional | ||
Type XDSServerType `json:"type"` |
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 is a good example of one where we'll likely want to switch the default at some point (#2134), how would that work? Are we saying that that requires a major version bump of the API to do?
@@ -24,8 +23,8 @@ import ( | |||
type ContourConfigurationSpec struct { | |||
// XDSServer contains parameters for the xDS server. | |||
// +optional | |||
// +kubebuilder:default={type: "contour", address: "0.0.0.0", port: 8001, tls: { caFile: "/certs/ca.crt", certFile: "/certs/tls.crt", keyFile: "/certs/tls.key", insecure: false}} | |||
XDSServer XDSServerConfig `json:"xdsServer"` | |||
// +kubebuilder:default={type: "contour"} |
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.
We should add a good comment at the top of this file explaining how the defaulting works since it is very non-obvious (i.e. specifying one field at this level triggers the lower-level defaults to also fill in).
// | ||
// Other values will produce an error. | ||
// The default includes both values. | ||
// +kubebuilder:default="HTTP/1.1";"HTTP/2" |
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.
Seems like one that'll change over time, how do we handle?
|
||
// TLS holds various configurable Envoy TLS listener values. | ||
TLS EnvoyTLS `json:"tls"` | ||
// +optional | ||
// +kubebuilder:default={minimumProtocolVersion: "1.2"} |
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.
another that'll change over time, how to handle?
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 one is probably worth looking at the docstring again and making sure we explain that you can choose 1.1, but we don't turn it on by default.
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.
Surely all valid options should be described but I guess the change over time here would be deprecation of 1.2. and setting 1.3 as default.
// * `1.3` | ||
// | ||
// Other values will produce an error. | ||
// +kubebuilder:default="1.2" |
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.
another that'll change over time
64531e7
to
987eb82
Compare
also a TODO item related to this is to write an e2e test to validate kubebuilder defaults, this will ensure if defaults change in a PR, we have a signal and can write a release note etc. trick will be to make sure new fields are added to this test over time, to ensure we maintain coverage |
// +kubebuilder:default={address: "0.0.0.0", port: 8000} | ||
Metrics MetricsConfig `json:"metrics"` | ||
// +kubebuilder:default={port: 8002} | ||
Metrics *MetricsConfig `json:"metrics"` | ||
} | ||
|
||
// XDSServerType is the type of xDS server implementation. | ||
type XDSServerType string |
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.
for this sort of thing I also see +enum
as an annotation (e.g. here), which is described here, not sure if we care to do this or not, might make things nice for downstream consumers? (but also not clear to me if this locks you into the same thing as kubebuilder enum, that adding values is a major change)
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.
The argument against using Enums is that Clients can (and should) assume that they know all possible values of the enum, so adding or removing fields can break clients unless it's made very clear that the enum could be changed. Making the type an aliased string leaves the door open for other values than the list at any particular version.
It feels to me like this applies no matter how the enum is specified.
Does this really apply here? I think so, but I suppose that a lot of these fields are unlikely to have further values added. I think XDSServerType is a good example of one where we could conceivably add further values (like maybe incremental
or something) as we add further functionality and want to have a chance to get it in people's hands before it's as stable as the rest.
I agree that having to document this stuff manually sucks, but this feels to me like another time when the rule has been written in upstream maintainer pain.
@@ -539,7 +673,7 @@ type ContourConfigurationStatus struct { | |||
// +patchStrategy=merge | |||
// +listType=map | |||
// +listMapKey=type | |||
Conditions []contour_api_v1.DetailedCondition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"` | |||
Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"` |
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 wanted to open a thread on this one, to see what the reasoning behind this change was? the standard metav1.Condition
list may be sufficient?
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.
Ah, thanks for catching this, I had intended to put a comment in here.
I think DetailedCondition was a mistake on my part. Unfixable in the v1 APIs, but we aren't really using the Errors
and Warnings
fields in DetailedCondition, so I think we should move towards using the upstream struct instead.
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 could (and probably should) be a separate PR though.
With conversation still ongoing in #4062, I'll leave this alone for now. Once we have more consensus there, I'll come back here and update. |
Marking this PR stale since there has been no activity for 14 days. It will be closed if there is no activity for another 30 days. |
Marking this PR stale since there has been no activity for 14 days. It will be closed if there is no activity for another 30 days. |
Marking this PR stale since there has been no activity for 14 days. It will be closed if there is no activity for another 30 days. |
* Remove enum defnitions, replace with godoc for allowed values * Simplify defaults Signed-off-by: Nick Young <ynick@vmware.com>
* Update defaulting logic for TLS Ciphersuites * Update servecontext_test.go tests to reduce boilerplate * Update API Reference docs to list available constant values for string alias types * Added default value documentation to fields that have a Kubebuilder default Signed-off-by: Nick Young <ynick@vmware.com>
Signed-off-by: Nick Young <ynick@vmware.com>
Signed-off-by: Nick Young <ynick@vmware.com>
Signed-off-by: Nick Young <ynick@vmware.com>
987eb82
to
fa2a997
Compare
TODO list here, from #4062
|
Signed-off-by: Nick Young <ynick@vmware.com>
fa2a997
to
961f9fd
Compare
Marking this PR stale since there has been no activity for 14 days. It will be closed if there is no activity for another 30 days. |
Superseded by #4451 |
Here I'm proposing swapping everything to optional, in line with my comments in #4062. While working on that, I've cleaned up a few other things I've found, as listed above.