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

Bug 1837251: Add unsupported http/2 kill switch #401

Merged
merged 3 commits into from May 26, 2020

Conversation

frobware
Copy link
Contributor

@frobware frobware commented May 20, 2020

Adding:

ingress.operator.openshift.io/unsupported-disable-http2: "true"

to either an ingresscontroller or the ingress configuration will
disable HTTP/2 support in the router deployment.

Corresponding router change: openshift/router#133

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 20, 2020
@frobware frobware changed the title Add unsupported http/2 kill switch Bug 1837251: Add unsupported http/2 kill switch May 20, 2020
@openshift-ci-robot openshift-ci-robot added bugzilla/severity-urgent Referenced Bugzilla bug's severity is urgent for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. labels May 20, 2020
@openshift-ci-robot
Copy link
Contributor

@frobware: This pull request references Bugzilla bug 1837251, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.5.0) matches configured target release for branch (4.5.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1837251: Add unsupported http/2 kill switch

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.

frobware added a commit to frobware/router that referenced this pull request May 20, 2020
This is to support the kill functionality added by:

  openshift/cluster-ingress-operator#401
frobware added a commit to frobware/router that referenced this pull request May 20, 2020
This is to support the kill functionality added by:

  openshift/cluster-ingress-operator#401
@openshift-ci-robot
Copy link
Contributor

@frobware: This pull request references Bugzilla bug 1837251, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.5.0) matches configured target release for branch (4.5.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1837251: Add unsupported http/2 kill switch

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.

@frobware
Copy link
Contributor Author

The failures might be genuine to this PR....

/retest

@Miciah
Copy link
Contributor

Miciah commented May 20, 2020

The operator's log output from the CI run repeats the following error:

E0520 17:24:22.257635       1 reflector.go:178] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to list *v1.Ingress: ingresses.config.openshift.io is forbidden: User "system:serviceaccount:openshift-ingress-operator:ingress-operator" cannot list resource "ingresses" in API group "config.openshift.io" at the cluster scope

The operator has permission to get the resource:

- apiGroups:
- config.openshift.io
resources:
- infrastructures
- ingresses
- dnses
- apiservers
- networks
verbs:
- get

However I think you need permission to list and watch:

- apiGroups:
  - config.openshift.io
  resources:
  - ingresses
  verbs:
  - list
  - watch

pkg/operator/controller/ingress/controller.go Outdated Show resolved Hide resolved
pkg/operator/controller/ingress/controller.go Outdated Show resolved Hide resolved
@@ -498,6 +514,11 @@ func desiredRouterDeployment(ci *operatorv1.IngressController, ingressController
env = append(env, corev1.EnvVar{Name: WildcardRouteAdmissionPolicy, Value: "false"})
}

if HTTP2IsDisabledByAnnotation(ci.Annotations) || HTTP2IsDisabledByAnnotation(ingressConfig.Annotations) {
Copy link
Contributor

Choose a reason for hiding this comment

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

What if the cluster ingress config has ingress.operator.openshift.io/unsupported-disable-http2=true and the ingresscontroller has ingress.operator.openshift.io/unsupported-disable-http2=false? Seems like the ingresscontroller's annotation should override the ingress config's. Granted, this is an unsupported annotation, so I wouldn't worry too much about this if it makes the logic hairy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems like the ingresscontroller's annotation should override the ingress config's.

Interesting. I interpreted the ingress config to have the higher priority. Rather than annotating all the ingresscontrollers you could just add it to the ingress config to disable it everywhere.

Copy link
Contributor

Choose a reason for hiding this comment

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

My reasoning is that if the user explicitly added an annotation to both the ingress config as well as to an individual ingresscontroller, then the user is expressing a general preference with the former annotation and an overriding preference for the specific ingresscontroller with the latter annotation.

pkg/operator/controller/ingress/deployment.go Outdated Show resolved Hide resolved
test/e2e/operator_test.go Outdated Show resolved Hide resolved
test/e2e/operator_test.go Outdated Show resolved Hide resolved
test/e2e/operator_test.go Outdated Show resolved Hide resolved
Adding:

  ingress.operator.openshift.io/unsupported-disable-http2: "true"

to either an ingresscontroller or the ingress configuration will
disable HTTP/2 support in the router deployment.

The corresponding change for the router:

  openshift/router#133

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1837251
@frobware
Copy link
Contributor Author

@Miciah I addressed all your feedback with the exception of changing the logic for who wins when the config is "true/false" vis-a-vis when the ingresscontroller disables with "true/false". How much complexity do we want here? If either is set, the ingress controller will have http/2 disabled.

I also moved the new e2e test into its own file and factored out the functions from the core test logic.

PTAL

@frobware frobware requested a review from Miciah May 21, 2020 11:55
@frobware
Copy link
Contributor Author

I did some manual testing with openshift/router#133 and using the http/2 tests in origin I was able to see that backend would report "HTTP 1.1" when the kill switch was in effect. And testing against the grpc-interop-reencrypt route also failed.

@Miciah
Copy link
Contributor

Miciah commented May 21, 2020

You got a test failure:

=== RUN   TestRouteHTTP2EnableAndDisable
--- FAIL: TestRouteHTTP2EnableAndDisable (1.27s)
    http2_disable_test.go:58: failed to update ingresscontroller: Operation cannot be fulfilled on ingresscontrollers.operator.openshift.io "default": the object has been modified; please apply your changes to the latest version and try again

You probably need to do a Get in disableHTTP2ForIngressController so that you have the latest revision when you do the Update. That change probably would be sufficient, but if you wanted to be extra careful, you could use wait.Poll and retry the update. (You could do the same in disableHTTP2ForIngressConfig, but it is unlikely that the ingress config will be updated during the test.)

@frobware
Copy link
Contributor Author

That change probably would be sufficient, but if you wanted to be extra careful, you could use wait.Poll and retry the update

Going to do both. Admittedly I've only been testing the single http/2 e2e locally, relying on CI for the full gamut.

@frobware
Copy link
Contributor Author

/retest

The controller now needs to watch for ingress objects so that we can
detect if the http/2 disable annotation has been added. We watch the
ingress config resource and trigger reconcile for all related
ingresscontrollers.
@Miciah
Copy link
Contributor

Miciah commented May 26, 2020

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label May 26, 2020
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: frobware, Miciah

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

@openshift-merge-robot openshift-merge-robot merged commit 6e3fb0f into openshift:master May 26, 2020
@openshift-ci-robot
Copy link
Contributor

@frobware: Some pull requests linked via external trackers have merged: openshift/cluster-ingress-operator#401. The following pull requests linked via external trackers have not merged:

In response to this:

Bug 1837251: Add unsupported http/2 kill switch

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.

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. bugzilla/severity-urgent Referenced Bugzilla bug's severity is urgent for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants