e2e: reject unknown providers#73402
Conversation
|
|
|
Needs |
9d3ed49 to
b4384e9
Compare
|
/test ci-kubernetes-e2e-kubeadm-gce-1-13 Let's see whether the kubeadm job still works. I hope this runs it... |
that job moved to sending a PR in a bit. |
|
/test pull-kubernetes-node-e2e |
this one might fail for a while due to a GCE zone outage. |
test/e2e/framework/test_context.go
Outdated
There was a problem hiding this comment.
Why not default to skeleton here?
There was a problem hiding this comment.
Because "" traditionally had the meaning "fallback to 'local' with a specific warning". Selecting "skeleton" would change that.
I don't have any strong opinion either way, but as I don't know the background behind that behavior I don't want to be the one to change it.
There was a problem hiding this comment.
so both local and skeleton are null providers here:
https://github.com/kubernetes/kubernetes/blob/b4384e9f828b97c380b93483bea279d2a71d1d00/test/e2e/framework/provider.go#L60-L66
if the previous fallback from "" as provider was local then today setting to skeleton as default should not have a regressive effect (famous last words).
local and skeleton in test-infra/kubetest on the other hand are different.
There was a problem hiding this comment.
The question is whether anyone cares about having this log message when --provider is not set:
https://github.com/kubernetes/kubernetes/blob/b4384e9f828b97c380b93483bea279d2a71d1d00/test/e2e/framework/provider.go#L69
There was a problem hiding this comment.
If we hard fail we should have a sane default imo.
There was a problem hiding this comment.
i'm convinced that log-dump.sh is evil at this point.
needs
+ 💣
There was a problem hiding this comment.
@pohly so "" already does not fallback to "local" if i'm not wrong, as per:
https://github.com/kubernetes/kubernetes/blob/b4384e9f828b97c380b93483bea279d2a71d1d00/test/e2e/framework/provider.go#L68-L71
it effectively falls back to a unnamed null-provider in 1.13 and master, so from what i'm seeing we already modified the old behavior.
If we hard fail we should have a sane default imo.
from my understanding we are not failing but instead we are only showing a warning if --provider is not set (equals "").
There was a problem hiding this comment.
@neolit123 right, it currently basically falls back to "skeleton plus warning". Forget what I said about falling back to "local". I think that the current behavior is consistent with <1.13 but haven't checked.
I'm in favor of removing this odd log message and just making skeleton the explicit default. Any objections?
There was a problem hiding this comment.
Done. See latest commit in this PR.
test/e2e/framework/test_context.go
Outdated
There was a problem hiding this comment.
Please add a //TODO: when providers are extracted this code should be removed.
There was a problem hiding this comment.
I've added a TODO and link to #70194
I've kept the wording a bit more open-ended because I can imagine scenarios where kubernetes/kubernetes itself has no provider-specific code, but still supports building custom testsuites where such code is included. That would allow different cloud providers to share common tests in a neutral location when those tests depend on cloud-provider specific code. Whether that is something that Kubernetes as an organization wants to support I don't know.
test/e2e/framework/test_context.go
Outdated
There was a problem hiding this comment.
I'm not really a fan, but if your long term goal is to extract provider code then I'll be ok with this if there are tracking/umbrealla issues that outline path forwards.
There was a problem hiding this comment.
I personally don't have plans in that direction, but it is getting tracked here: #70194
This finishes the work started for 1.13: instead of merely warning about an unknown value given to --profile, the test/e2e/e2e.test binary will now print an error and refuse to run. Fixes: kubernetes#70200
b4384e9 to
f3d79e1
Compare
The empty string was the default and then triggered a special warning. There's no good reason for that behavior, so now the special handling for "unset provider" is gone and "skeleton" is the non-empty default for the value.
|
/retest |
|
/lgtm |
|
/retest |
1 similar comment
|
/retest |
|
/test pull-kubernetes-node-e2e |
|
/skip |
|
@pohly hm, i though "" should be defaulting to skeleton at this point. |
|
@neolit123 thanks for investigating the error, I wasn't sure whether it was just flakiness or caused by the PR. The Should |
my initial reaction is that we should print a message that we are defaulting |
Not accepting --provider= (i.e. setting an empty provider name) broke some test jobs. As suggested in kubernetes#73402 (comment), now --provider= and not passing --provider at all both trigger a message and then continue as if --provider=skeleton had been used.
|
Pushed another commit with that change. |
|
thanks you. |
|
@pohly: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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. |
|
/test pull-kubernetes-verify |
|
/lgtm |
|
@neolit123 do you still want me to squash? I think it is not necessary, each commit makes sense by itself, and I would prefer to merge it like it is now (given that we have clean test results, a lgtm, etc.). |
seems fine to me! |
|
@timothysc please have another look and if you agree then approve the PR. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pohly, timothysc The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
looks like this PR still manged to break our signal even if it wasn't supposed to: will investigate why. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This finishes the work started for 1.13: instead of merely warning
about an unknown value given to --profile, the test/e2e/e2e.test
binary will now print an error and refuse to run.
That was the intended behavior, we just couldn't do it earlier because it broke some users of the binary. At least kubeadm testing is now fixed (kubernetes/test-infra#10913).
Which issue(s) this PR fixes:
Fixes #70200
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
/sig testing
/cc @neolit123 @timothysc