-
Notifications
You must be signed in to change notification settings - Fork 597
tlsroute: make TLSRoute structure consistent with HTTPRoute #682
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
tlsroute: make TLSRoute structure consistent with HTTPRoute #682
Conversation
@hbagdi: GitHub didn't allow me to request PR reviews from the following users: howardjohn. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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/test-infra repository. |
apis/v1alpha2/tlsroute_types.go
Outdated
// | ||
// +optional | ||
// +kubebuilder:validation:MaxItems=16 | ||
Hostnames []Hostname `json:"snis,omitempty"` |
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.
Would you mind reverting the Go field name to match the JSON/YAML field name? Divergence on the names for fields has led me astray many times in the past :)
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.
Updated the other way around since the discussion has to be around renaming this field to hostnames
as well.
4c86a99
to
6beb478
Compare
/lgtm |
// a domain name prefixed with a single wildcard label (e.g. `*.example.com`). | ||
// The wildcard character `*` must appear by itself as the first DNS label | ||
// and matches only a single label. You cannot have a wildcard label by | ||
// itself (e.g. Host == `*`). |
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.
Why not? I think right now in the spec the answer would be "Because you should just use TCPRoute instead in that case", but in the future could we not allow routing on other attributes of the TLS handshake?
I don't feel strongly about this at all - our implementation only supports routing by SNI today - just curious.
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 see this is also copy+pasted so definitely not blocking this PR at all
/approve |
@hbagdi I've thought about this more and agree that this change makes sense. We discussed this briefly at community meeting today and it didn't sound like there was any opposition to this change, so I'm happy to LGTM once it's rebased. |
6beb478
to
237d154
Compare
/hold cancel |
237d154
to
21caf2b
Compare
Thanks! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hbagdi, howardjohn, jpeach, robscott The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind cleanup
/kind api-change
What this PR does / why we need it:
This PR makes the structure of TLSRoute similar to HTTPRoute:
Which issue(s) this PR fixes:
Fixes #566
Does this PR introduce a user-facing change?:
Putting a hold here as there is still work to do. I'd like to get consensus on moving this forward before putting more time in here.
/hold
/cc @howardjohn @bowei @jpeach @robscott