WIP: Implement LB allowed source ranges API #510
Conversation
openshift-ci-robot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
openshift-ci-robot
added
the
approved
Fake bump to get the LB allowed source ranges API. * manifests/00-custom-resource-definition.yaml: * pkg/manifests/bindata.go: * vendor/github.com/openshift/api/operator/v1/0000_50_ingress-operator_00-ingresscontroller.crd.yaml: * vendor/github.com/openshift/api/operator/v1/types_ingress.go: Regenerate.
* pkg/operator/controller/ingress/controller.go (setDefaultPublishingStrategy): Update allowed source ranges if needed. * pkg/operator/controller/ingress/load_balancer_service.go (desiredLoadBalancerService): Copy the value of the ingresscontroller's spec.status.endpointPublishingStrategy.loadBalancerSourceRanges.allowedSourceRanges field to the service's spec.loadBalancerSourceRanges field. * pkg/operator/controller/ingress/load_balancer_service_test.go (TestLoadBalancerServiceChanged): Add test case for source range. * test/e2e/operator_test.go (TestAllowedSourceRanges): New test. Verify that the operator correctly configures the load balancer service and updates the service when the allowed source range is changed.
Miciah
force-pushed
the
implement-LB-allowed-source-ranges-API
branch
from
43bb24b
to
bff61df
Compare
|
@Miciah: 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/test-infra repository. I understand the commands that are listed here. |
|
/retitle WIP: Bug 1906560: Implement LB allowed source ranges API |
openshift-ci-robot
changed the title
openshift-ci-robot
added
the
bugzilla/severity-urgent
|
@Miciah: This pull request references Bugzilla bug 1906560, which is valid. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
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. |
openshift-ci-robot
added
the
bugzilla/valid-bug
| // The initial source range of 127.0.0.0/8 should block all traffic. | ||
| // Poll for a minute and verify that we do not get an HTTP response. | ||
| gotResponse := false | ||
| err := wait.PollImmediate(10*time.Second, 1*time.Minute, func() (bool, error) { |
There was a problem hiding this comment.
nit: We want a timeout error in this case, so maybe we should replace err with _.
There was a problem hiding this comment.
Fair point. I suppose err is redundant since we have gotResponse.
| err := wait.PollImmediate(10*time.Second, 1*time.Minute, func() (bool, error) { | ||
| status, err := checkRoute() | ||
| if err != nil { | ||
| t.Logf("Got error from LB: %v", err) |
There was a problem hiding this comment.
Should we change this log message to indicate that an error from the LB is an expected thing? Wouldn't want to confuse anyone reading our test logs who doesn't know what this test does.
There was a problem hiding this comment.
Yeah, I wasn't sure how to word this. The phrase "expected error" doesn't seem quite right because it implies that a specific error was expected. I'll add "as expected" to the message.
| t.Fatal(err) | ||
| } | ||
|
|
||
| err = wait.PollImmediate(10*time.Second, 2*time.Minute, func() (bool, error) { |
There was a problem hiding this comment.
Any particular reason that this loop has a timeout of 2 minutes, but the prior loop has a timeout of only 1 minute?
There was a problem hiding this comment.
I have a couple reasons, but I'm not sure how sound they are. First, the first timeout is expected to be hit (the request should always fail), so it's a question of how long we want the test to sit around making sure that the thing that should never happen never happens. One minute seems like a reasonable amount of time to be confident that the LB really isn't accepting connections, without increasing the overall test time in the expected case too much. Second, the second timeout is expected not to be hit, and if we only hit it because the configuration change takes longer than expected, that's a test flake, so the high timeout usually won't increase the overall test time, and when it does, it reduces flakiness, which is worth waiting an extra minute (maybe even a couple extra minutes). Does that sound reasonable?
There was a problem hiding this comment.
Does that sound reasonable?
Yup. We can always readjust these values in the future need be.
Miciah
changed the title
|
@Miciah: No Bugzilla bug is referenced in the title of this pull request. 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. |
openshift-ci-robot
removed
bugzilla/severity-urgent
|
@Miciah: PR needs rebase. 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. |
openshift-ci-robot
added
the
needs-rebase
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci-robot
removed
the
lifecycle/stale
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
removed
the
lifecycle/stale
openshift-ci
bot
added
the
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. 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. |
pkg/operator/controller/ingress/controller.go(setDefaultPublishingStrategy): Update allowed source ranges if needed.pkg/operator/controller/ingress/load_balancer_service.go(desiredLoadBalancerService): Copy the value of the ingresscontroller'sspec.status.endpointPublishingStrategy.loadBalancerSourceRanges.allowedSourceRangesfield to the service'sspec.loadBalancerSourceRangesfield.pkg/operator/controller/ingress/load_balancer_service_test.go(TestLoadBalancerServiceChanged): Add test case for allowed source ranges.test/e2e/operator_test.go(TestAllowedSourceRanges): New test. Verify that the operator correctly configures the load balancer service and updates the service when the allowed source ranges are changed.Depends on the following PR: