Org: Request to create new repository `kubernetes-sigs/alibaba-cloud-csi-driver` on behalf of sig-cloud-provider

[fredkan]

New Repo, Staging Repo, or migrate existing

migrate existing: https://github.com/AliyunContainerService/csi-plugin

Requested name for new repository

alibaba-cloud-csi-driver

Which Organization should it reside

kubernetes-sigs

If not a staging repo, who should have admin access

@fredkan, @xianlubird

If not a staging repo, who should have write access

@fredkan, @xianlubird

If not a staging repo, who should be listed as approvers in OWNERS

@fredkan, @xianlubird

If not a staging repo, who should be listed in SECURITY_CONTACTS

@fredkan, @xianlubird

What should the repo description be

'alibaba-cloud-csi-driver' is a CSI Driver for volume management on AlibabaCloud platform, which supports most of storage types in alibabacloud. The drivers used as the base storage driver in ACK(Alibaba Cloud Container Service for Kubernetes) and also cooperate with lots of customers like: SAP, TiDB, AntFinancial.

The Plugin repo has received many of PRs from the developers, which make a great improvement. We want to contribute the repo to kubernetes community and working together with developers.

The Source Address: https://github.com/AliyunContainerService/csi-plugin

What SIG and subproject does this fall under in sigs.yaml

this is a new subproject for sig-cloud-provider called alibaba-cloud-csi-driver

Approvals

Sent out email to sig-storage, sig-cloud-provider.
https://groups.google.com/forum/#!topic/kubernetes-sig-cloud-provider/kT7k41rvBvs

Additional context for request

/cc @saadali, @andrewsykim @xiang90

[andrewsykim]

@fredkan I think you have to be a Kubernetes SIGs org member in order to be an admin/owner.

[xianlubird]

@andrewsykim

I'm the kubernetes member and we are the same team for alibaba cloud csi plugin, can I be an admin/owner ?

Thank you .

[mrbobbytables]

@fredkan just for clarification, are you looking for a bare repository? or to migrate AliyunContainerService/csi-plugin to kubernetes-sigs?

If it's migration, there are a few more steps involved to donate it to the Kubernetes project. For the specifics on that, please see the docs for it here:
https://git.k8s.io/community//github-management/kubernetes-repositories.md#rules-for-donated-repositories

[xianlubird]

@mrbobbytables We want a bare repository.

Most of these authors are our colleagues, accounting for about 99% of the total, and the remaining one or two commits will be discarded, without affecting any function points.

[nikhita]

@xianlubird a few more follow-up questions:

• Will the code be copied from the existing repo or will the code be created from scratch?

• Will the existing commits (barring 1-2 commits) be included/"copied" to the new repo?

[xianlubird]

@nikhita

1. The code will be copied from the existing repo

2. The existing commits (barring 1-2 commits) won't be included/"copied" to the new repo

[nikhita]

The code will be copied from the existing repo

This would essentially be equal to migrating the repo so it'll need to follow the rules in https://git.k8s.io/community//github-management/kubernetes-repositories.md#rules-for-donated-repositories. This is mainly important for licensing, code of conduct, etc.

The existing commits (barring 1-2 commits) won't be included/"copied" to the new repo

Is there a particular reason why the commits won't be included? IMO it's better to include them for attribution. I'm also a little concerned that this could be tricky from a legal perspective if they aren't included. :grimacing:

[xianlubird]

@nikhita OK, thank you . These commits authors cloud not be reached, so we can't let them sign CLA.
We will follow

If (a) contributor(s) have not signed the CLA and could not be reached, a NOTICE file should be added referencing section 7 of the CLA with a list of the developers who could not be reached

adding a NOTICE file to reference these commits.

[nikhita]

@xianlubird Thanks for the background! :)

Generally, we try to avoid adding a NOTICE file as much as possible. I checked CLA for all existing contributors and only two contributors don't have CLA signed - tommenx (https://github.com/AliyunContainerService/csi-plugin/commit/35dc77b98bf58ebf632ca486474a6d93e7830a66) and haoshuwei (https://github.com/AliyunContainerService/csi-plugin/commit/adba9f4f55043cf27a33b80aca5a5787a71f778d). Both of them have single commits each. In the past, we've tried reverting changes from the particular authors to go around the CLA issue.

I'll wait for approval from @andrewsykim for the migration first, and if it's approved, I'd prefer pinging the two contributors and wait for a few days before we decide to revert the changes and/or add a NOTICE file just to have a written, linkable record of "we tried to contact the authors, but couldn't reach them".

[fredkan]

@xianlubird Thanks for the background! :)

Generally, we try to avoid adding a NOTICE file as much as possible. I checked CLA for all existing contributors and only two contributors don't have CLA signed - tommenx (AliyunContainerService/csi-plugin@35dc77b) and haoshuwei (AliyunContainerService/csi-plugin@adba9f4). Both of them have single commits each. In the past, we've tried reverting changes from the particular authors to go around the CLA issue.

I'll wait for approval from @andrewsykim for the migration first, and if it's approved, I'd prefer pinging the two contributors and wait for a few days before we decide to revert the changes and/or add a NOTICE file just to have a written, linkable record of "we tried to contact the authors, but couldn't reach them".

@nikhita Thank you.
haoshuwei(AliyunContainerService/csi-plugin@adba9f4) is our colleague in the same team in alibabacloud, I will contact him to sign the CLA today.

tommenx (AliyunContainerService/csi-plugin@35dc77b) is one of the developper, I will also try to contact him to sign.

Thank you very much.

[fredkan]

@nikhita
haoshuwei (AliyunContainerService/csi-plugin@adba9f4) has signed the CLA. I will continue to contact tommenx. Thanks.

[andrewsykim]

I'm the kubernetes member and we are the same team for alibaba cloud csi plugin, can I be an admin/owner ?

@xianlubird yes but you still need to request membership for the kubernetes-sigs org - which has no requirements if you're already a kubernetes org member but you still need to open an issue to request it. Ideally you also want at least 2 approvers in the OWNERs file but I don't think that's a strict requirement here.

Given the precedent that SIG Cloud Provider owns plugins owned by cloud providers I have no objections for the SIG owning this repo. cc @cheftako

[cheftako]

/lgtm

[xianlubird]

@andrewsykim Thank you very much for your detailed and patient reply. I have already open a issue for join kubernetes-sigs org #1150.

@nikhita We've got a approval from @andrewsykim and we can continue on for the next step.

Thank you very much.

[nikhita]

There are a few things that need to be done before we can migrate the repo:

• There are a bunch of dependencies in the vendor directory that have no license file. Example: https://github.com/AliyunContainerService/csi-plugin/tree/master/vendor/github.com/nightlyone/lockfile. But the original source code for that dependency: https://github.com/nightlyone/lockfile has a LICENSE file. Is there a particular reason why these LICENSE files were not included -- maybe some glide magic under the hood? If that's the case, would it be helpful to move to gomodules? In general, we require that LICENSE files be present for all vendor directories.

• The Kubernetes boilerplate header needs to be added to all relevant files. The boilerplate for different files can be found here: https://github.com/kubernetes/kubernetes/tree/master/hack/boilerplate.
  I noticed that there are some files which already have this header (like https://github.com/AliyunContainerService/csi-plugin/blob/master/pkg/nas/nas.go) but the newlines in the boilerplate need to be fixed. :grimacing:

• Can you add CONTRIBUTING.md, code-of-conduct.md, SECURITY_CONTACTS and OWNERS files as per https://github.com/kubernetes/kubernetes-template-project?

• Can you also update the READMEs (both README.md and README-zh_CN.md) to the format as described in https://github.com/kubernetes/kubernetes-template-project? Particularly the "community" and "code of conduct" sections.

• I noticed that the repo has both .travis.yml and .circleci/config.yml files. Which one of these is being used right now? Travis is not configured for the @kubernetes-sigs org, so only circleci will be functional. Overall, we suggest to use Prow for CI/CD for upstream projects but the move to prow can be done post-migration.

• Looks like @tommenx has still not signed the CLA. Would it be possible to remove the files in https://github.com/AliyunContainerService/csi-plugin/commit/35dc77b98bf58ebf632ca486474a6d93e7830a66 temporarily and re-add them back post-migration? This should help us with the CLA issue.

• After all of this has been done, please add me as an admin to the repo to carry out the migration.

Also, if you have any questions, feel free to ping me on the k8s slack (I'm @nikhita on there). :smile:

[fredkan]

@nikhita Thank you very much for your detailed and patient reply. We are working on it.

[fredkan]

@nikhita I have updated the repo, and fix the above issues. Please have a check.

Issue 1: update the vendor with go mod.
Issue 2: update the boilerplate headers.
Issue 3: Files added.
Issue 4: README.md updated.
Issue 5: travis.yml circleci removed.
Issue 6: remove the files as cannot contact the developer.

Thank you for your support.

[nikhita]

@fredkan Thank you sooo much for addressing all the issues so quickly! :smile:

Issue 5: travis.yml circleci removed.

Looks like both travis and circle are still present...but it's totally ok to remove them after migration too.

Everything looks good! Please add me as an admin to the repo when you are ready to migrate it.

[fredkan]

@nikhita Thank you for your review.
travis.yml circleci removed now, and I have added you as an admin to the repo.

Is it OK only to migrate the master branch to the new repo?

[nikhita]

Repo has been migrated: https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver :tada:

@fredkan I noticed that the repo still has travis and circleci webhooks. I'm guessing it's okay to remove these, but wanted to double check if you are good with it as well.

Also created:

• https://github.com/kubernetes/org/pull/1156 - to add GitHub teams to grant access
• https://github.com/kubernetes/community/pull/4047 - to add the repo to sigs.yaml

Once both PRs merge, we can close the issue.

[nikhita]

Is it OK only to migrate the master branch to the new repo?

Migration will migrate all branches, but feel free to delete the branches you'd rather not keep.

[fredkan]

@fredkan I noticed that the repo still has travis and circleci webhooks. I'm guessing it's okay to remove these, but wanted to double check if you are good with it as well.

@nikhita It is okay, I can remove them while I get the right to modify. Thank you very much.

[nikhita]

Both PRs have merged and the relevant teams have been granted access.

/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

Both PRs have merged and the relevant teams have been granted access.

/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.