Update of csi-lib-iscsi fails to compile

[humblec]

update of csi-lib-iscsi fails to compile:

[hchiramm@localhost csi-driver-iscsi]$ grep -iR "github.com/kubernetes-csi/csi-lib-iscsi" * --color
go.mod:	github.com/kubernetes-csi/csi-lib-iscsi v0.0.0-20200629134124-4eea777a2dc3
go.sum:github.com/kubernetes-csi/csi-lib-iscsi v0.0.0-20200629134124-4eea777a2dc3 h1:wXFH8cdGsfC7gibAZfolMASqCLsuqt3cbiy44hWkcLU=
go.sum:github.com/kubernetes-csi/csi-lib-iscsi v0.0.0-20200629134124-4eea777a2dc3/go.mod h1:4lv40oTBE8S2UI8H/w0/9GYPPv96vXIwVd/AhU0+ta0=

+ go build -a -ldflags ' -X main.version=991e8fb04982913f68afdaaf5af265fefc715e1b  -extldflags "-static"' -o ./bin/iscsiplugin ./cmd/iscsiplugin
# github.com/kubernetes-csi/csi-lib-iscsi/iscsi
vendor/github.com/kubernetes-csi/csi-lib-iscsi/iscsi/iscsi.go:379:7: no new variables on left side of :=
Building iscsiplugin for GOOS= GOARCH= failed, see error(s) above.
make: *** [release-tools/build.make:81: build-iscsiplugin] Error 1

[humblec]

The interesting thing here is that, the csi iscsi library has been used in this CSI driver to great extent. However the library project itself (https://github.com/kubernetes-csi/csi-lib-iscsi) looks unmaintained to me. @msau42 @andyzhangx @j-griffith any thoughts here?

[andyzhangx]

so maybe it's better put whole csi-lib-iscsi project to csi-driver-iscsi repo? In near term, we would add e2e test for this project, and if there is change in csi-lib-iscsi lib, it's quite easier to build, test, verify. Maintain two projects is a burden.

[humblec]

so maybe it's better put whole csi-lib-iscsi project to csi-driver-iscsi repo? In near term, we would add e2e test for this project, and if there is change in csi-lib-iscsi lib, it's quite easier to build, test, verify. Maintain two projects is a burden.

Indeed thats one thing we can do. Other idea would be placing all the libraries of csi in a single repo, I am not sure how many we have atm. We can go either way. Will wait for other opinions and move on accordingly.

@saad-ali @jsafrane @xing-yang @pohly wdyt?

[msau42]

The reason for having the iscsi library be its own repo is so that other drivers can import it without needing to import the iscsi csi driver. However, I think with the improvements with go modules, I think it's feasible to move the iscsi library into this repo and release it as an additional sub module. We do something similar for snapshotter and the client api libraries.

[pohly]

I agree, a Go submodule with its own independent versioning in the same repo as the driver is probably the best solution for this.

[j-griffith]

As @msau42 pointed out the hope was that all the vendors and other folks using iscsi would adopt the csi-lib-iscsi package, that hasn't really materialized for the most part. Abandoning the csi-lib-iscsi pacakage and using this using a sub module might lead to more adoption, it certainly makes more sense than maintaining the two code bases separately.

[humblec]

Thanks @msau42 @pohly @j-griffith @andyzhangx for sharing the thoughts 👍 As everyone backed the solution of bringing csi lib iscsi to this repo as a submodule , lets move with that. Working on the same.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close