WIP: try with csi-test upgraded to 2.2.0 and change of #393 added

[okartau]

No description provided.

[pohly]

This is a subset of #401. Can we merge that instead?

[okartau]

The essential change in 2.2.0 is use of ID Generator instead of static strings.
IDGen is an optional interface for callers to provide a generator for valid Volume and Node IDs. Defaults to DefaultIDGenerator which generates generic string IDs

Use of generated IDs is good thing as otherwise the static string IDs could remain same and cause hash collisions in VolumeIDs that PMEM-CSI generates.

Despite the promise in comment "optional, defaults to DefaultIDGenerator" it does not work without explicit init.value in Config (which I added in separate comment). Without that initialization, sc.Config.IDGen remains nil and causes tester code panic when sc.ConfigIDGen. method is called.

[okartau]

This is a subset of #401. Can we merge that instead?

indeed, it is. somehow, #401 gets tests running without adding IDGen to Config ?

[pohly]

Olev Kartau <notifications@github.com> writes:

indeed, it is. somehow, #401 gets tests running without adding IDGen to Config ?

Did you find that this is necessary?

[okartau]

yes as I explained in comment above. If I just made change to 2.2.0, test code paniced as sc.Config.IDGen was nil. Code started to run when I added IDGen init in Config.

[pohly]

yes as I explained in comment above. If I just made change to 2.2.0, test code paniced as sc.Config.IDGen was nil. Code started to run when I added IDGen init in Config.

Hmm, then why did the PR test of #401 pass?

[okartau]

no idea. My first thought after I saw the panic was that there is something else involved which my isolated version step-up did not bring in. I tried to find it, but IDGen change seems quite well isolated. So I went on and created workaround using Config init.line.
Now with bigger change working OK, my first idea gets more support again.

[pohly]

#401 passed PR testing because... no E2E tests ran (https://cloudnative-k8sci.southcentralus.cloudapp.azure.com/blue/organizations/jenkins/pmem-csi/detail/PR-401/2/pipeline/58).

That is the Achilles heel of automatically choosing which tests to run in the code: if choosing the tests is buggy, testing may silently not run as intended.

I'll investigate that in #401.

[pohly]

This shouldn't be necessary. I think it's a bug in csi-test, which we should fix there: https://github.com/kubernetes-csi/csi-test/blob/82b05190c167c52bb6d5aaf2e1d7c833fa539783/pkg/sanity/sanity.go#L161-L163 was added to Test, but not GinkgoTest.

We should have a common function that is used by both code paths to sanitize the config.

@okartau as you found this, can you do the upstream fix?

In this repo we can keep IDGen: &sanity.DefaultIDGenerator{} as a temporary workaround for 2.2.0, but there should be a TODO comment above it about removing it.

[pohly]

kubernetes-csi/csi-test#220

[okartau]

closing as devel stepped up to csi-test 2.2.0