-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
test: add compatibility versions feature gate test as a nightly prow periodic job #34257
test: add compatibility versions feature gate test as a nightly prow periodic job #34257
Conversation
/assign @BenTheElder |
05e2216
to
3d5d4f7
Compare
/cc @Jefftree |
3d5d4f7
to
7c7effc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General question about test-infra changes: Is it possible to see a sample run of this before merging or is that not possible?
config/jobs/kubernetes/sig-testing/compatibility-versions-e2e.yaml
Outdated
Show resolved
Hide resolved
7c7effc
to
28998c5
Compare
I don't believe it is possible, I have been testing the scripts manually. I have attached a gist of a test output to the PR description. |
35f6a6c
to
b79b493
Compare
config/jobs/kubernetes/sig-testing/compatibility-versions-e2e.yaml
Outdated
Show resolved
Hide resolved
experiment/compatibility-versions/compatibility-versions-feature-gate-test.sh
Outdated
Show resolved
Hide resolved
possible, but a big pain (you have to setup everything yourself, see e.g. pj-on-kind.sh, which is going to have problems with e2e tests) ... and prow has ~no investment right now, just barely community-provided KTLO |
- wrapper.sh | ||
- bash | ||
- -c | ||
- curl -sSL https://kind.sigs.k8s.io/dl/latest/linux-amd64.tgz | tar xvfz - -C "${PATH%%:*}/" && ./../test-infra/experiment/compatibility-versions/compatibility-versions-feature-gate-test.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xref: #33980
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry -- I'm just trying to track these for later, it's not a blocker.
Basically you use kind build node-image
with one of the CI builds of Kubernetes instead of from source.
We will also have to make sure the commit from that build gets recorded to testgrid (I forget the specifics of how that works), if / when we convert one of the scripts we can apply it in multiple places.
But it's not a blocker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
config/jobs/kubernetes/sig-testing/compatibility-versions-e2e.yaml
Outdated
Show resolved
Hide resolved
config/jobs/kubernetes/sig-testing/compatibility-versions-e2e.yaml
Outdated
Show resolved
Hide resolved
experiment/compatibility-versions/compatibility-versions-feature-gate-test.sh
Outdated
Show resolved
Hide resolved
kubectl get --raw /metrics > "${output_file}" | ||
} | ||
|
||
validate_feature_gates() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it would make sense to factor out this part into a test script independent of all the e2e setup bits, at some point we may more directly share the rest? Also it seems like most (all?) of this [test] would work on other clusters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've refactored validate_feature_gates
into its own script now:
experiment/compatibility-versions/validate-compatibility-versions-feature-gates.sh
which is called from the main/entrypoint script:
experiment/compatibility-versions/compatibility-versions-feature-gate-test.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I could see us hoisting this out or even rewriting it in go later for use by more jobs (maybe into k/k and run against GCE clusters as well?) :-)
182200d
to
a7cca0e
Compare
/sig api-machinery |
runtimeConfig: ${runtime_config} | ||
kubeadmConfigPatches: | ||
- | | ||
kind: ClusterConfiguration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're also going to have to start targeting these to specific versions and add a kubeadm v1alpha4 patch soon: kubernetes-sigs/kind#3847
Going to be a headache, at least trying to track the places in-project where we're running kind @ HEAD
touch "${results_file}" | ||
|
||
# Parse /metrics -> actual_features[featureName] = 0 or 1 | ||
declare -A actual_features |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
worth noting: when we have a lot of arrays that aren't something trivial like exec args that's a sign that we probably want to reach for a more structured language
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, I originally wrote this test as an integration test for k8s/k8s in Golang but ported it to bash for use in test-infra after some discussion on the original PR:
kubernetes/kubernetes#128138
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, I commented there to continue the conversation 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(and I think for now bash is reasonable, but something to be wary of longterm, especially if we know we're going to need more functionality)
@@ -0,0 +1,259 @@ | |||
#!/bin/bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can be a follow-up but we usually use #!/usr/bin/env bash
, this guarantees that we use the preferred copy in PATH and is a little more portable (/usr/bin/env
is virtually guaranteed due to env
being POSIX and so many scripts doing this, but bash
may not be in /bin
, e.g. on my work mac I have installed newer bash via homebrew and kubernetes scripts may require that)
same goes for the other script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for flagging this, I've updated all scripts to use:
#!/usr/bin/env bash
done | ||
} | ||
|
||
# --- Main execution when script is called directly --- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend just only supporting calling and condense this down to a single codepath / exec it from the other script instead of trying to support both exec and sourcing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(up to you, but I'd suggest considering this before it gets wider usage, feel free to /hold cancel and punt)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah makes sense, I've updated the script to support only being exec'd for now.
a7cca0e
to
0ebca9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
/hold |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aaron-prindle, BenTheElder 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 |
0ebca9f
to
2220b0b
Compare
/hold cancel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
@aaron-prindle: Updated the
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-sigs/prow repository. |
This PR adds a feature get test to the compatibility version prow periodic jobs. This test is adapted from the closed PR here: kubernetes/kubernetes#128138 which attempted a similar test upstream (it was decided test-infra was the better place for the test in the discussion there). This feature gate test builds and runs the latest k8s, hits the /metrics endpoint fetching the current feature gates and their information (stage, lockToDefault, enabled/disabled). Then it pulls the n-1 k8s repo and grabs the versioned_feature_list.yaml and unversioned_feature_list.yaml files from that repo which are the source of truth for n-1 feature gates and compares them making sure that the feature gates for n vs n-1 fall within the necessary guarantees for the compatibility versions feature.
Example test run by running the script locally w/ same env var config as the prow test:
https://gist.github.com/aaprindle/254f748d008afc11063ba3479f7238ff