external-snapshot-metadata yaml files are on unusual place, so this script
would need some updates. Since the sidecar is not used in any e2e test,
skip the sidecar for now.
Copy VolumeGroupSnapshot v1beta2 CRDs from the external-snapshotter and
disable v1beta1 API in them - we can't run the conversion webhook in e2e
tests easily.
Update e2e tests to use v1beta2.
YAML files were patched with:
sed -i -e 's;registry.k8s.io/e2e-test-images/agnhost:2...;registry.k8s.io/e2e-test-images/agnhost:2.54;' $(git grep -l agnhost:2 test/e2e/testing-manifests/ test/fixtures/)
The test/images/kitten and test/images/nautilus base images are still on an
older agnhost because updating those is better left to the owners.
Instead of hard-coding two instances of the hostpathplugin which listen on
certain socket paths, the hostpathplugin now gets started through Pod exec as
needed. The advantage is that the helper code is in charge of socket naming,
just like it would be in real deployment.
One nuisance is that exec.StreamWithContext always complains in copyFromStdout
and copyFromStderr when the remote hostpathplugin gets killed via context
cancellation:
E0312 11:56:31.637669 289446 v2.go:167] "Unhandled Error" err="next reader: read tcp [::1]:59006->[::1]:6444: use of closed network connection" logger="UnhandledError"
E0312 11:56:31.637749 289446 v2.go:150] "Unhandled Error" err="next reader: read tcp [::1]:59006->[::1]:6444: use of closed network connection" logger="UnhandledError"
These can be ignored.
When supporting rolling updates, we cannot use the same fixed socket paths for
old and new pod. With the revised API, the caller no longer specifies the full
socket paths, only directories. The logic about how to name sockets then can be
in the helper.
While at it, avoid passing a context to the gRPC helper code when
all that the helper code needs is a logger. That leads to confusion
about whether cancellation has an effect.
This commit introduces comprehensive e2e tests for the
Volume Group Snapshot feature to ensure robust validation and functionality.
Addresses issue [kubernetes#1080 ](kubernetes-csi/external-snapshotter#1080).
Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters:
1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes.
2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents.
3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots.
Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications.
Approved API references:
- VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814
- VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068
Signed-off-by: Manish <myathnal@redhat.com>
