The LoadBalancer rules change if the node IP is in one of the
LoadBalancerSourceRange subnets, so make sure to set nodeIP on the
fake proxier so we can test this, and add a second source range to
TestLoadBalancer containing the node IP. (This changes the result of
one flow test that previously expected that node-to-LB would be
dropped.)
This removes all feature definitions that were marked for removal in 1.25, with
some exceptions:
- some features were marked for removal in 1.25 although they only graduated
to GA in 1.24 - that seems too soon, so the comment was updated instead
- CSIVolumeFSGroupPolicy and PodDisruptionBudget are still used in the code, so
removing them will be more work and was deferred
Merge conflicts become less likely when:
- features are sorted alphabetically because
then changes are more likely to be done in
different parts of the files
- blank lines separate the hash entries because
gofmt then doesn't change the formating of
other entries when adding or removing one
Merge conflicts where pretty common shortly before a code freeze when everyone
added new features at the end of the files.
Starting golangci-lint >= 1.45, the tool is complaining
about the function being unused:
```bash
test/e2e_node/device_plugin_test.go:82:6: func `getSampleDevicePluginPod` is unused (unused)
func getSampleDevicePluginPod() *v1.Pod {
^
Please review the above warnings. You can test via "./hack/verify-golangci-lint.sh"
If the above warnings do not make sense, you can exempt this warning with a comment
(if your reviewer is okay with it).
In general please prefer to fix the error, we have already disabled specific lints
that the project chooses to ignore.
See: https://golangci-lint.run/usage/false-positives/}
```
thing is the code is not changed lately, and manual inspection trivially
confirms it is used.
Older versions of golangci-lint (tested with
```
golangci-lint has version 1.41.1 built from a2074809 on 2021-06-19T16:01:50Z
```)
indeed do NOT complain about the function, so this seems a golangci-lint
bug.
To move forward, we can disable the warning, but this leaves a sour
taste.
Instead, since the function is pretty trivias, was used just once and the caller
was undoing some of the work done by the function, we just inline it,
which solves the linter warning and makes the code a bit better.
Signed-off-by: Francesco Romani <fromani@redhat.com>
