Commit 7bcee13d79 added alpha feature gates for Kubernetes 1.19 in
the CSI_PROW_E2E_ALPHA_GATES_LATEST variable based on the comment in
https://github.com/kubernetes-csi/external-provisioner/pull/493#discussion_r502663402
that alpha testing only runs for the latest Kubernetes.
But some components (like external-health-monitor) are configured with
a single Prow job which runs the default set of tests on a stable
Kubernetes release (currently 1.17). Those tests used to include alpha
testing which then broke during Kind cluster startup because the
Kubernetes 1.19 feature gates weren't recognized by 1.17.
The solution is to disable alpha testing for Kubernetes != latest in
the default set of tests.
kind 0.9 adds support for recent Kubernetes releases like 1.19 and
simplifies configuration of feature gates and runtime config.
With Kubernetes 1.19, new feature gates were introduced which might
become relevant for the alpha Prow jobs.
The updated kind release comes with images for different Kubernetes
releases than the one before. To avoid breaking existing jobs,
the script now picks kind images automatically. As an additional
bonus, it then uses images with hash, i.e. it's less likely to break
if those image tags change because of a future kind release.
Bazel makes sense in the Prow jobs because those often get invoked
with a pre-populated Bazel cache. But local invocation don't need it
and now can turn it off with CSI_PROW_USE_BAZEL=false.
It used to be necessary to override from where the E2E suite came on a
case-by-case basis (initially, testing was using a more recent suite
against an older Kubernetes). This should never become necessary again
and the lack of a specific entry for 1.18 already had the unintended
effect that Kubernetes 1.18 was tested with the suite from master, so
overall it is better to always use the E2E suite which matches
Kubernetes.
Kubernetes 1.19.0 uses Go 1.15, but refers to it as 1.15.0. This broke
both the check whether we need to install 1.15 (because "go version"
reports 1.15, which didn't match 1.15.0) and then downloading the
release archive (because the URL also only uses 1.15).
If the Dockerfile needs to run some command, that step fails unless
QEMU is set up properly first:
failed to solve: rpc error: code = Unknown desc = failed to load
LLB: runtime execution on platform linux/ppc64le not supported
The approach taken here extends the existing support for
cross-compiling binaries on the build host and specifying the Go
compiler: Go is installed if needed (as in Prow testing), binaries are
build on the host, then one image is created for each platform, and
finally those are combined into a single multi-architecture image.
Developers should not be forced to build for all platforms by
default. We also don't want to copy-and-paste the go invocation for
each new platform.
To address both, the target platform(s) are now configurable via
BUILD_PLATFORMS and additional platforms are only enabled in the Prow
CI.
For now this serves as a test that the source actually compiles for
multiple platforms. Building images for different target platforms is a
different problem.
The final 1.3.0 release of the hostpath driver really uses the 1.3.0
driver image in its deployment, in contrast to the previous -rc
candidates which still used 1.2.0.
This relies on a slightly different deployment script: a "deploy.sh"
must exist which knows that it has to dump a test driver configurion
into the file pointed to with CSI_PROW_TEST_DRIVER, if that env
variable is set.
That way, we no longer need to know what capabilities the installed
driver has.
This requires adding one more parallel e2e test run with
a special focus flag because snapshot tests are still guarded
with a "[Feature:VolumeSnapshotDataSource]" tag. The setting that
skips all tests with "[Feature:.*]" has to be removed because it
overrides the focus.
We don't have serial snapshot tests yet. This needs to be modified
again if we add any in the future.
Inside a real Prow job it is better to clean up at runtime instead of leaving that to the Prow job cleanup code because the later sometimes times out.
Signed-off-by: Mucahit Kurt <mucahitkurt@gmail.com>
changes to kind. There are 3 changes made to prow.sh:
1. Use a master commit of kind that includes the fix for Kubernetes
master.
2. Use git clone instead of git checkout (shallow) to source Kubernetes.
This lets kind correctly figure out the Kubernetes release tag.
3. Build kind with make install. The kind fix was not working correctly
when built with go build.
with specific patch versions that kind 0.4.0 supports. Also, feature
gate setting is only supported on 1.15+ due to
kind.sigs.k8s.io/v1alpha3 and kubeadm.k8s.io/v1beta2 dependencies.
By moving the code into a separate function, other CSI drivers have a
chance to overwrite it. For the hostpath driver itself we need the
ability to set the driver name depending on which revision is getting
installed.
Whether a component supports sanity testing depends on the
component. For example, csi-driver-host-path enables it because it
makes sense there (and only there). Letting the prow.sh script decide
whether it actually runs simplifies the job definitions in test-infra.