-
Notifications
You must be signed in to change notification settings - Fork 38.6k
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
Add e2e tests for CSI PVCDataSources #80117
Conversation
ginkgo.By("[Initialize dataSource]creating a source PVC") | ||
sourcePVC, err := client.CoreV1().PersistentVolumeClaims(source.Namespace).Create(source) | ||
framework.ExpectNoError(err) | ||
err = framework.WaitForPersistentVolumeClaimPhase(v1.ClaimBound, client, sourcePVC.Namespace, sourcePVC.Name, framework.Poll, framework.ClaimProvisionTimeout) |
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.
To support delayed binding, we should create the pod first, and then we can wait for pvc bound.
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.
Maybe better to check for delayed binding and react appropriately; then the calling test can sort out what to do (it may check the same way). My thought being that rather than just making the helper in the suite work in all conditions, make sure it's expclicitly checking based on the bind mode?
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.
Unsure if this test really cares about the different between delayed and immediate. For most tests I think it'll be simpler to handle both the same way
defer cleanup() | ||
|
||
dc := l.config.Framework.DynamicClient | ||
dataSource, cleanupFunc := preparePVCDataSourceForProvisioning(framework.NodeSelection{Name: l.config.ClientNodeName}, l.cs, dc, l.pvc, l.sc) |
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.
L244 should be updated to be "pvc-datasource-tester"
We also need to update https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-gcp/sig-gcp-gce-config.yaml#L132 to run tests with the new feature tag. And I think this depends on #79955 to update the sidecar in the test. |
077227f
to
d9b1a67
Compare
|
||
dc := l.config.Framework.DynamicClient | ||
dataSource, cleanupFunc := preparePVCDataSourceForProvisioning(framework.NodeSelection{Name: l.config.ClientNodeName}, l.cs, dc, l.pvc, l.sc) | ||
defer cleanupFunc() |
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.
maybe call this dataSourceCleanup to be more clear
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.
changed to "dataSourceCleanup", thanks.
|
||
wantStatus := v1.ClaimBound | ||
if *class.VolumeBindingMode == storagev1.VolumeBindingWaitForFirstConsumer { | ||
wantStatus = v1.ClaimPending |
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.
Unsure what is the purpose of checking for state if it's just going to be pending. Since the purpose of this function is not to test PVC binding, what if we just don't check for PVC Phase and just wait for the pod to succeed to populate the data? If there actually is some binding failure, it will show up as pod failed to run.
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.
Well, as you pointed out the code before was creating a PVC and waiting for "bound" status, as a result if one were to pass in a local-disk for example or anything using "FirstConsumer" binding, then this helper function in the test suite would fail.
So by adding the check above we "know" not to fail if the test is using a WaitForFirstConsumer PVC, and we don't fail here because it never went to Bound. That way it's up to the person implementing the test to decide how they want to deal with things like checking usage against a pod etc, but it makes this suite flexible enough to be used for both.
Sure, we could just omit this check altogether if you'd rather, however I think there was a test that consumed this and relied on this to determine if a volume was properly provisioned (by checking for status Bound).
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 function is specific to preparing pvc data source, so I don't think it really needs to check pvc bound state. It only cares that the volume was successfully populated with some data.
If you still want to keep the pvc bound check, then I would move the check to after the pod is successful. This is how other tests handle both immediate and delayed binding.
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.
That works, I'll just drop it out altogether, thanks.
|
||
ginkgo.By("[Initialize dataSource]checking the source PVC") | ||
// Get new copy of the source | ||
_, err = client.CoreV1().PersistentVolumeClaims(sourcePVC.Namespace).Get(sourcePVC.Name, metav1.GetOptions{}) |
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.
unsure if we need this call? We only need pvc.namespace + name for this test, which should already be set in L729.
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.
removed
d4eea8a
to
7bd418d
Compare
// write namespace to the /mnt/test (= the volume). | ||
ginkgo.By("[Initialize dataSource]write data to volume") | ||
command := fmt.Sprintf("echo '%s' > /mnt/test/initialData", sourcePVC.GetNamespace()) | ||
RunInPodWithVolume(client, sourcePVC.Namespace, sourcePVC.Name, "pvc-snapshot-writer", command, node) |
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 should be "pvc-datasource-writer"?
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.
fixed
dataSource, dataSourceCleanup := preparePVCDataSourceForProvisioning(framework.NodeSelection{Name: l.config.ClientNodeName}, l.cs, dc, l.pvc, l.sc) | ||
defer dataSourceCleanup() | ||
|
||
l.pvc.Spec.DataSource = dataSource |
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.
Have you tried running this test manually against hostpath driver? I'm not sure if reusing l.pvc
works here because we already used it to provision the source volume.
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 won't work without: kubernetes-csi/external-provisioner#309 and kubernetes-csi/csi-driver-host-path#82.
We'll need to get those merged and backported or update the image in the e2e tests for this to pass.
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'm still not sure this works. l.pvc
is used to create the source pvc. We need a new PVC for the target clone.
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'll clean it up, it's poorly written as is even if it did work.
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.
@msau42 I added a new source PVC to the init, instrumented some thing and ran though it with the new images to confirm it's working as expected.
Dependent changes needed: |
/retest |
1 similar comment
/retest |
address unit test comments
7bd418d
to
47facf9
Compare
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: j-griffith, msau42 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 |
/retest |
/retest Review the full test history for this PR. Silence the bot with an |
1 similar comment
/retest Review the full test history for this PR. Silence the bot with an |
/kind cleanup
What this PR does / why we need it:
Add an e2e test for the VolumePVCDataSource feature, test against the CSI Hostpath driver.