Reorganization of drivers repo

[lpabon]

Overview:
This repo was first created to be a location for example, non-production, drivers. Just a location on how they may be created. After some time, it has turned into a repo for real drivers. For this reason, these drivers should move onto their own repo with their own release cycles.

Proposal:
Here are a set of the proposals:

• First, make sure we tag and branch to keep around the older stuff.
• Rename drivers to driver-hostpath repo.
• Remove cinder, csi-common, flexadapter, iscsi, and nfs drivers and packages.
• Cleanup the documentation to just be the repo for hostpath and point to the csi-sanity mock driver as another example.

[saad-ali]

Xing: Moving csi-common will it break existing drivers? Are drivers using this? If so where should it be moved?

[saad-ali]

Move flexadapter to kubernetes-csi/driver-flexadapter
If csi-common is useful it should be kubernetes-csi/csi-common. Other wise leave it where it is and mark deprecated.

[pohly]

csi-common could be the place where the common code of hostpath, external attacher/provisioner, driver registrar could be maintained. Right now code like logGRPC is copy-and-pasted around. external-provisioner/pkg/controller/controller.go has a TODO about putting it into a library.

The open question is whether there's supposed to be any API stability guarantee around the content of such a csi-common or whether it should be treated as internal to the kubernetes-csi team.

[pohly]

Overall I'd prefer to keep kubernetes-csi/csi-common.

[pohly]

Note that @shubheksha found an example that shows why we might want to avoid cut-and-paste: logGPRC logs secrets. If we want to fix that (undecided, see kubernetes-csi/external-provisioner#82), then currently we would have to make the change in four places.

[pohly]

I have started vendoring csi-common into driver-registrar as part of the Jaeger tracing prototype, sharing both the logGRPC code and the Jaeger tracing support code:

• https://github.com/pohly/drivers/commits/jaeger-tracing
• https://github.com/pohly/driver-registrar/commits/jaeger-tracing

However, I'm not entirely happy with the setup. It is very cumbersome to make changes in csi-common and then use those changes in driver-registrar. One either has to hack in driver-registrar/vendor and copy changes back, or go through a commit/push/dep cycle with a locally set source constraint.

Has it been considered to put all code into the same repo?

Choosing the granularity of repos is always a tradeoff. Keeping each component in its own repo makes sense when they are technically independent and/or developed by different teams at a different pace. But I would argue that neither of these is the case here:

• once we start sharing code, the different apps become more closely coupled
• it's the same team making changes to all of them
• they get released at the same time
• integration testing in Kubernetes must be done with all four apps

[lpabon]

@pohly I think creating a csi-common repo with logGRPC is a good start.

Also, I think you bring up a good point about all the repos being separate. Right now Kubernetes is a single repo of multiple project. The key difference is the processes in place to divide the areas.

I will discuss this with with @saad-ali . It may make it easier on repo management also.

[kfox1111]

@lpabon Looks like the reorg may have happened? can we create a repo for #85 yet?

[pohly]

kfox1111 <notifications@github.com> writes:

@lpabon Looks like the reorg may have happened? can we create a repo for #85 yet?

No, the reorg is on hold at the moment. The Kubernetes CSI team decided in one of the weekly meetings to continue development with one repo per component. Your driver therefore should get its own repo.

[kfox1111]

Yeah, thats of what I'm asking. If it is to be in its own repo, can we get it created? github.com/kubernetes-csi/csi-driver-image?

Thanks,
Kevin

[kfox1111]

Oh. I see. the repos were created, but there isn't code in them yet. I can wait then.

[kfox1111]

Can someone please explain why this is stalled? I'd like to help if possible.

[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: Closing this issue.

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.