Skip to content
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

Merged
merged 1 commit into from Aug 16, 2019

Conversation

j-griffith
Copy link
Contributor

@j-griffith j-griffith commented Jul 13, 2019

/kind cleanup

What this PR does / why we need it:

Add an e2e test for the VolumePVCDataSource feature, test against the CSI Hostpath driver.

None

@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. area/test sig/testing Categorizes an issue or PR as relevant to SIG Testing. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 13, 2019
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)
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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)
Copy link
Member

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"

@msau42
Copy link
Member

msau42 commented Jul 18, 2019

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.


dc := l.config.Framework.DynamicClient
dataSource, cleanupFunc := preparePVCDataSourceForProvisioning(framework.NodeSelection{Name: l.config.ClientNodeName}, l.cs, dc, l.pvc, l.sc)
defer cleanupFunc()
Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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.

Copy link
Contributor Author

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).

Copy link
Member

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.

Copy link
Contributor Author

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{})
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed

// 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)
Copy link
Member

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"?

Copy link
Contributor Author

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
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. and removed needs-kind Indicates a PR lacks a `kind/foo` label and requires one. labels Aug 1, 2019
@j-griffith
Copy link
Contributor Author

j-griffith commented Aug 10, 2019

Dependent changes needed:
kubernetes-csi/external-provisioner#325 Merged
kubernetes-csi/csi-driver-host-path#82 new tag release
#81304 - update e2e image reference to include cloning fix

@j-griffith
Copy link
Contributor Author

/retest

1 similar comment
@j-griffith
Copy link
Contributor Author

/retest

address unit test comments
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Aug 15, 2019
@j-griffith
Copy link
Contributor Author

/retest

@msau42
Copy link
Member

msau42 commented Aug 15, 2019

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 15, 2019
@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 15, 2019
@j-griffith
Copy link
Contributor Author

/retest

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

1 similar comment
@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

@k8s-ci-robot k8s-ci-robot merged commit 1955467 into kubernetes:master Aug 16, 2019
@k8s-ci-robot k8s-ci-robot added this to the v1.16 milestone Aug 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. release-note-none Denotes a PR that doesn't merit a release note. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants