Add e2e tests for external health monitor controller

[xing-yang]

No description provided.

[NickrenREN]

Anyone who is interested in this ?

[irbekrm]

Hi! I would be interested in working on this issue.

[NickrenREN]

/assign @irbekrm

[NickrenREN]

Thanks @irbekrm

[irbekrm]

I was also wondering what driver should be used for the e2e tests.
I see here that the e2e tests should use hostpath CSI driver and GCE PD driver, however I looked at the hostpath CSI driver and it does not implement the required interface yet.
Is the requirement to use hostpath CSI driver and GCE PD driver still up to date?

[xing-yang]

We can use the CSI hostpath driver for e2e tests.

@fengzixu is working on the following issue to add health monitoring support in the CSI hostpath driver. So these e2e tests tasks are actually depending on this one.
#21

For GCE PD driver, I think we'll have to wait until it has the health monitoring support.

[xing-yang]

Hi @irbekrm,
In addition to adding e2e tests using the CSI hostpath driver, we should also add e2e tests using the CSI Mock Driver. The advantage of using the mock driver is that we can also inject failure using the javascript hooks. See the following links for details. Can you take a look of this?

• Javascript hooks for csi mock driver: Add JavaScript hooks csi-test#251
• e2e test example: kubernetes/kubernetes@a4f0808

[irbekrm]

Hi @xing-yang ,

Thank you! I will take a look at the examples for the mock driver and start working on this. I might get back with some questions about the approach.

[irbekrm]

Actually, I am having some doubts about the e2e tests for this with the CSI Mock Driver and the javascript hooks.

The external health monitor creates a VolumeConditionAbnormal event only if volume condition is marked as abnormal:true in the gRPC response from the driver. But with the hooks, it is only possible to return with a gRPC error code and empty gRPC response, so I cannot force the mock driver to return a gRPC response with abnormal:true via a hook.

I was also looking at using the hooks to return early from one of the CSI Mock Driver methods that actually create the volume, so that the condition 'becomes' abnormal in the driver itself. But because the hooks can only cause the driver method to return with a non-OK gRPC code, I think this is also not possible because the volume creation would just fail.

So, I am not sure if the creation of VolumeConditionAbnormal and VolumeConditionNormal events can be e2e-tested with the CSI Mock Driver? Maybe I could just wait for this PR kubernetes-csi/csi-driver-host-path#210 to be merged and test with the CSI hostpath driver?

Same with this #35

[xing-yang]

I see. Let's wait for the CSI hostpath driver implementation then.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fengzixu]

@irbekrm Hi. Long time no see. How are you? Actually, I want to tell you the `CSI hostpath driver implementation is already finished. I think you can start to work on e2e test issue from now.

[irbekrm]

Hi! Thanks for letting me know- I will take a look this weekend 😄

[irbekrm]

/remove-lifecycle stale

[xing-yang]

@irbekrm Not sure if you have started working on this. Actually right now there's no good way of writing an e2e test for this feature. This is because that we are only reporting events to PVCs. Events can disappear so it is not reliable to write an e2e test to verify if an event is recorded.

[irbekrm]

Hi, thank you for letting me know- actually I had not started working on this properly.

I think I will then better unassign myself- perhaps someone else can take a look or maybe there will be a better way to test this sometime in the future!

/unassign

[xing-yang]

Closing this as we are not adding e2e tests for now.