Skip to content
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

Variety of fixes in response to feedback on #780 #796

Merged
merged 2 commits into from
Aug 25, 2021

Conversation

robscott
Copy link
Member

@robscott robscott commented Aug 20, 2021

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
There's been a lot of great feedback in #780, this makes some of the easier fixes.

Does this PR introduce a user-facing change?:

* listener.routes has been renamed to listener.allowedRoutes
* The "NoSuchGatewayClass" has been removed after it was deprecated in v1alpha1
* "*" is no longer a valid hostname. Instead, leaving hostname unspecified is interpreted as "*".

@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Aug 20, 2021
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 20, 2021
Comment on lines -36 to -39
// Implementations should add the `gateway-exists-finalizer.gateway.networking.k8s.io`
// finalizer on the associated GatewayClass whenever Gateway(s) is running.
// This ensures that a GatewayClass associated with a Gateway(s) is not
// deleted while in use.
Copy link
Member Author

@robscott robscott Aug 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to GatewayClass spec

@robscott robscott force-pushed the 780-small-fixes branch 2 times, most recently from fe98e8b to 26f3a97 Compare August 21, 2021 00:09
Copy link
Contributor

@youngnick youngnick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two small suggestions, but aside from that, LGTM.

apis/v1alpha2/gateway_types.go Show resolved Hide resolved
apis/v1alpha2/gatewayclass_types.go Show resolved Hide resolved
apis/v1alpha2/gateway_types.go Show resolved Hide resolved
// ignored otherwise.
// TLS is the TLS configuration for the Listener. This field is required if
// the Protocol field is "HTTPS" or "TLS". It MUST be ignored when the
// Protocol field is "HTTP", "TCP", or "UDP".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer we error out. Such silent acceptance result in confusion during debugging.
We can add a check in the validation webhook for this purpose.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like this is a good case for a Condition of some sort, but I'm not sure which one.

// only one rule may ultimately receive the request. Matching precedence
// MUST be determined in order of the following criteria:
// Although a client request may match multiple route rules, only one rule
// may ultimately receive the request. Matching precedence MUST be
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MUST rather than MAY.

Suggested change
// may ultimately receive the request. Matching precedence MUST be
// WILL ultimately receive the request. Matching precedence MUST be

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one of the things we're struggling with here is what the intended audience is. I think we may need to start differentiating implementation guidance (words like MUST) with what users should expect (words like will). Maybe implementation guidance belongs somewhere other than spec?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've struggled with that distinction and I brought it before as well.
I think most of the documentation is geared towards implementation guidance and we should stick to that. The larger audience will require much more context and the implementation authors can take care of that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was talking with @bowei about this recently, maybe there are some guidelines we can be applying when we're writing our godocs here?

apis/v1alpha2/gateway_types.go Outdated Show resolved Hide resolved
apis/v1alpha2/gateway_types.go Outdated Show resolved Hide resolved
apis/v1alpha2/gateway_types.go Outdated Show resolved Hide resolved
apis/v1alpha2/gateway_types.go Outdated Show resolved Hide resolved
apis/v1alpha2/httproute_types.go Outdated Show resolved Hide resolved
apis/v1alpha2/shared_types.go Show resolved Hide resolved
apis/v1alpha2/tcproute_types.go Outdated Show resolved Hide resolved
@youngnick
Copy link
Contributor

I think I've only really got one thing that needs addressing here, but there are a few followup things, especially around Conditions and status (which is probably due for a recheck and overhaul). I don't think we should block at least the RC on status though, and I feel like a status review is possibly bigger than we should bite off bevore v1alpha2.

@@ -47,12 +60,19 @@ type GatewayClass struct {
Status GatewayClassStatus `json:"status,omitempty"`
}

const (
// GatewayClassFinalizerGatewaysExist MUST be added as a finalizer to the
Copy link
Contributor

@ccfishk ccfishk Aug 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

literally "must" is already "commanded or requested", strong.
dont think the uppercase is really needed since the importance is delivered by the verb.

Suggested change
// GatewayClassFinalizerGatewaysExist MUST be added as a finalizer to the
// GatewayClassFinalizerGatewaysExist must be added as a finalizer to the

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure how to distinguish between MUST and must for our godocs, but I think historically we've been using all caps to emphasize/match RFC terminology.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// GatewayClassFinalizerGatewaysExist MUST be added as a finalizer to the
// GatewayClass whenever there are provisioned Gateways using a
// GatewayClass.
GatewayClassFinalizerGatewaysExist = "gateway-exists-finalizer.gateway.networking.k8s.io"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading your comments,

Suggested change
GatewayClassFinalizerGatewaysExist = "gateway-exists-finalizer.gateway.networking.k8s.io"
ProvisionedGatewayClassFinalizer = "provisioned-gateway-finalizer.gateway.networking.k8s.io"

is more aligned to what you mean ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably could have a better name, but in this case I'm not actually changing the name, just moving it from gateway_types to gatewayclass_types. The idea is for it to indicate that at least one Gateway is using the GatewayClass and therefore the GatewayClass should not be deleted.

//
// * A Listener with `test.example.com` as the hostname matches HTTPRoutes
// that have either not specified any hostnames, or have specified at
// least one of `test.example.com` or `*.example.com`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// least one of `test.example.com` or `*.example.com`.
// least one of `test.example.com` or `*.example.com` or `*`.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually something that came out of API review, I can't remember which of the reviewers suggested it, but the recommendation was to remove "" as a possible value. An empty or unspecified value here would continue to be interpreted at "", but there was no point in differentiating between empty and "*" since they were interpreted the same way. Let me add that to the PR description.

// ignored. For example, if a Listener specified `*.example.com`, and the
// HTTPRoute specified `test.example.com` and `test.example.net`,
// `test.example.net` must not be considered for a match.
//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean as following ?
// If both the Listener and HTTPRoute have specified hostnames, only exact match
// will be considered.
// For example, if a Listener specified test.example.com, and the
// HTTPRoute specified test.example.com and test.example.net,
// test.example.net is not be considered for a match.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is trying to describe how wildcard hostname matching should work with hostnames specified on HTTPRoutes. I don't think removing the wildcard from the example would help here, but I may be misunderstanding what you're suggesting.

// must get a 503 instead.
// sent.

// If unspecified or invalid (refers to a non-existent resource or a Service
Copy link
Contributor

@ccfishk ccfishk Aug 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any k8s Service (Service with no endpoints) that does not have endpoints ?
maybe "resource" is more accurate here ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what we're trying to communicate here is a Service that does not have any endpoints, likely because there are no Pods running that have been selected by that service.

// status for this route should be updated with a condition that describes
// the error more specifically.
// "match" behavior. For example, resource "mytcproutematcher" in group
// "networking.example.net". If the referent cannot be found, the rule MUST
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// "networking.example.net". If the referent cannot be found, the rule MUST
// "networking.example.net". If the referent cannot be found, the rule must

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's probably room for a broader discussion around the usability of these all caps RFC terms, but so far the guidance from other reviewers has been to move more into this capitalization style. We can add to the agenda for next community meeting and/or create an issue to discuss if that's helpful. I don't have a very strong opinion here other than trying to be consistent with what we've done elsewhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely a thing we've copied from RFCs, where the increased emphasis is very purposeful - it's a guide for people implementing the spec that allows the reader to easily find the things they MUST do when reading what is often a long and dry specification. That's why I'm supportive of the all-caps.

// ignored otherwise.
// TLS is the TLS configuration for the Listener. This field is required if
// the Protocol field is "HTTPS" or "TLS". It MUST be ignored when the
// Protocol field is "HTTP", "TCP", or "UDP".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should ignore be actually be illegal? enforced by validation webhook?

Same with hostname for tcproute?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with that interpretation. For now I've just stated that this is invalid, but also created #827 to track this.

apis/v1alpha2/gatewayclass_types.go Show resolved Hide resolved
@robscott
Copy link
Member Author

Thanks to everyone for the great feedback on this one! I think I've responded to everything now, PTAL. Once we get this in, we should be able to move forward with v1alpha2-rc1.

@robscott
Copy link
Member Author

Looks like a deploy/netlify flake?

/retest

Copy link
Contributor

@youngnick youngnick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

I think that @ccfishk raises some fair questions to discuss, particularly about the use of all-caps for MUST, MAY etc, but I also think that's a larger discussion that would be better suited for its own issue/PR.

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 25, 2021
@k8s-ci-robot k8s-ci-robot merged commit 8343da8 into kubernetes-sigs:master Aug 25, 2021
robscott added a commit to robscott/gateway-api that referenced this pull request Aug 25, 2021
youngnick pushed a commit to youngnick/gateway-api that referenced this pull request Aug 26, 2021
Signed-off-by: Nick Young <ynick@vmware.com>
@robscott robscott deleted the 780-small-fixes branch January 8, 2022 01:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants