[WIP] Add provision support as a targetd plugin

[mkimuram]

What type of PR is this?
/kind feature

What this PR does / why we need it:
This PR adds provision support to csi-driver-iscsi.
By adding this feature, users will be able to provision PV with CSI iscsi driver, as it could be done with iSCSI-targetd provisioner for in-tree driver.

Which issue(s) this PR fixes:

Special notes for your reviewer:
This PR is implemented on top of another clean-up PR, so provision related commits are only below two commits:

• Support Create/Delete Volume in targetd plugin
• Support ControllerPublish/Unpublish in targetd plugin

This PR leveraged the same way to plugin the provisioner functionality, as I started discussion for csi-driver-nfs here. So, feedback for plugin mechanism related topic is welcomed in the PR.

Most of iscsi provision codes are copied from here, so how to prepare the iscsi targetd is the same to the existing provisioner.

Does this PR introduce a user-facing change?:

[k8s-ci-robot]

@mkimuram: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mkimuram
To complete the pull request process, please assign j-griffith
You can assign the PR to them by writing /assign @j-griffith in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[msau42]

/assign @j-griffith

[j-griffith]

We'll want to adjust the log level on these sorts of entries

[j-griffith]

@mkimuram This is a clever idea using plugin and driving creates. I would like to discuss this a bit, something that I have been interested in for a while (but haven't found the time for) is to actually provide a "full featured" iscsi-storage plugin based off of lvm and targetd.

What you have here is a nice approach though and allows a bit more flexibility. I'd like to chat with you and others about this a bit and think about this a little more. One thing this makes me wonder is if we kept this generic enough using the plugin model you have to then be able to plug in different models; for example options to build a plugin that uses the LVM model I mentioned, but also I could envision a plugin that does something like just assign a target to a raw disk or a partition as well. Basically the result is a flexible enough framework to turn "any" storage device into a iscsi plugin. Thoughts?

[mkimuram]

@j-griffith

Thank you for your comment.

One thing this makes me wonder is if we kept this generic enough using the plugin model you have to then be able to plug in different models

Actually, this is the exact point that I would like to discuss with people from many storage vendors and one who are interested in utilizing this feature, because every one of them might have different requirements.
If this is flexible enough for most of them that they can leverage the code in csi-driver-iscsi, they will have motivations to collaboratively improve the code here. But if it isn't, this will just introduce an extra complexity for this project. (In such a case, it would be better just to hard code these methods to the controller's code and make csi-driver-iscsi just for targetd.)

So, the enough flexibility for everyone will be one of the key criteria to decide if we should apply this model or not.

but also I could envision a plugin that does something like just assign a target to a raw disk or a partition as well.

As for replacing the plugin to allow raw disk or partition, instead of LVM, current model should be enough. Just replacing the plugin.so to another one should allow to do it.

[j-griffith]

@mkimuram Yeah, I totally get the idea and I like it in theory. I have some concerns around using the plugin module, I've done some things with it in the past and it was nice (initially) but IIRC there are some limitations on platforms (linux only AIR). Maybe that's not a deal breaker. More of a concern though is that it seemed to be very picky about things (go versions, libs etc).

The thing that's nice about this approach you have here is that it takes things a step further from the libraries, and actually offloads some of the CSI overhead (which has been a point of discussion lately). A vendor would still have to build their binary into this but we could actually offer a pretty reasonable kit for vendors to leverage.

I'd like to get some input from others (particularly storage vendors) if you don't mind... perhaps @lpabon maybe @bswartz

[k8s-ci-robot]

@mkimuram: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[k8s-ci-robot]

@fejta-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.