Org: Transfer ownership of aws-fsx-csi-driver repository as SIG-AWS subproject

[d-nishi]

New Repo, Staging Repo, or migrate existing

New repository

Requested name for new repository

aws-fsx-csi-driver

Which Organization should it reside

kubernetes-sigs

If not a staging repo, who should have admin access

@d-nishi
@leakingtapan
@justinsb

If not a staging repo, who should have write access

@d-nishi
@leakingtapan
@justinsb
@jsafrane

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

@d-nishi
@leakingtapan
@justinsb
@jsafrane

If a new repo, who should be listed in SECURITY_CONTACTS

@leakingtapan

What should the repo description be

This is the Container Storage Interface (CSI) driver implementation of Amazon FSx for Lustre that provides a CSI interface to be used by Kubernetes to manage lifecycle of Amazon FSx for lustre filesystems.

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

SIG-AWS
this will be a standalone subproject under SIG-AWS

Approvals

Complete check-list:

• [x] Must contain the topic for the sponsoring SIG - e.g. k8s-sig-api-machinery. (Added through the Manage topics link on the repo page.)
• [x] Must adopt the Kubernetes Code of Conduct
• [x] All code projects use the Apache License version 2.0. Documentation repositories must use the Creative Commons License version 4.0.
• [ ] Must adopt the CNCF CLA bot, merge bot and Kubernetes PR commands/bots.
• [x] All OWNERS of the project must also be active SIG members
• [x] SIG membership must vote using lazy consensus to create a new repository
• [ ] SIG must already have identified all of their existing subprojects and code, with valid OWNERS files, in sigs.yaml
• [x] All contributors must have signed the CNCF Individual CLA (https://github.com/cncf/cla/blob/master/individual-cla.pdf) or CNCF Corporate CLA (https://github.com/cncf/cla/blob/master/corporate-cla.pdf)
• [x] Licenses of dependencies are acceptable; project owners can ping @caniszczyk for review of third party deps. No dependencies found.
• [x] Received lazy consensus from +8 folks in SIG-AWS meeting held on 02/08/2018: SIG AWS Meeting minutes

Additional context for request

N.A.

[d-nishi]

/assign @cblecker

[cblecker]

@d-nishi is this a new repo? or a transfer?

[leakingtapan]

/hold

This is an existing projects that is going to be contributed by aws to the community.

See https://github.com/aws/aws-fsx-csi-driver

Need to finialize the project name before transfer

[leakingtapan]

/hold cancel

[nikhita]

/unassign @cblecker
/assign

[nikhita]

@leakingtapan @d-nishi can you add me as an admin to both the repos? I can work on the migration after that.

[nikhita]

@d-nishi thanks for adding me as an admin!

Hate to be a stickler, but looks like we have a few outstanding things to address before migration :grimacing:

Adding notes for both this repo + https://github.com/kubernetes/org/issues/468:

• The following contributors need to sign the CNCF CLA before we can migrate. Instructions about signing the CLA can be found here. For aws-fsx-csi-driver:

  • @jpeddicord
  • @watsonso

  @jpeddicord is also a contributor to https://github.com/d-nishi/aws-efs-csi-driver. Once they sign the CLA, aws-efs-csi-driver would be good to be migrated.




• Both repos have NOTICE and THIRD PARTY files. Kubernetes repos don't have these files. Can these be removed? cc @swinslow for additional guidance.




• The Code of Conduct file uses Amazon's CoC. This will need to move to use the Kubernetes CoC.




• Both repos need additional template files like OWNERS, etc. The CoC and all required template files can be found here: https://github.com/kubernetes/kubernetes-template-project.




• Not a blocker...but just want to double check: both repos don't have a vendor directory. Is this expected?

[d-nishi]

@nikhita will close these soon and ping you back. Thanks!

[hyandell]

(Amazon OSPO hat)

Please review @jpeddicord commits. They were repository creation actions.

Do not remove NOTICE files, they are there per the Apache License 2.0. Removing THIRD_PARTY files is probably a bad idea though you may wish to rename/relocate them. No concern with replacing the Amazon CoC.

[leakingtapan]

@nikhita I reverted @watsonso's commit since it was only one character change.

[nikhita]

Ack, thanks for the quick responses, @hyandell and @leakingtapan! :)

Just to cover all bases: @swinslow, from the legal side, can you confirm the following? :grimacing:

Do not remove NOTICE files, they are there per the Apache License 2.0. Removing THIRD_PARTY files is probably a bad idea though you may wish to rename/relocate them.

Can you confirm that we are good with keeping the NOTICE, THIRD_PARTY files? If we need to rename/relocate the THIRD_PARTY file, what do we rename it to and where do we relocate it to?

@nikhita I reverted @watsonso's commit since it was only one character change.

Can you confirm that we don't need to consider CLA for commits that have been reverted?

Please review @jpeddicord commits. They were repository creation actions.

My understanding is that _all_ commits need to have the CLA signed but I could be wrong... @swinslow can you confirm about this as well? :)

cc @caniszczyk @dims @justaugustus
because licensing stuff

[caniszczyk]

If the original commits were removed there's no need for him to sign the CLA.

[swinslow]

Agree with @hyandell, the Kubernetes project should not ourselves be removing the pre-existing NOTICE files from third parties.

That said -- @hyandell, I gather from this you're with Amazon :) and I assume others on this thread may be as well. A question for you: seeing as the NOTICE file only has an Amazon copyright statement, would Amazon be okay with removing that statement and the NOTICE file? I believe common practice for k8s repos has been not to include NOTICE files with original or subsequent contributors' copyright statements, presumably to ease the compliance burden for downstream users. Grateful if Amazon would be okay with omitting it here also.

For the THIRD_PARTY file, it looks like this is listing the licenses and copyright statements for third-party dependencies that aren't actually distributed in the repo, but get pulled in by go.mod. I'm fine with this file staying in, but I'm curious whether it gets auto-generated or whether it was created manually. If it's the latter, I don't know whether it's likely to stay up-to-date as the repo's dependencies evolve.

[leakingtapan]

We will merge Kubernetes' CoC/CONTRIBUTING/OWNERS files after the transfer: https://github.com/d-nishi/aws-efs-csi-driver/pull/17 and https://github.com/d-nishi/aws-fsx-csi-driver/pull/20

[hyandell]

I believe THIRD_PARTY was hand developed using https://github.com/amzn/oss-attribution-builder - I'll leave it up to the LF/CNCF how they want to handle license compliance situations.

On the NOTICE, removing that file is okay; I assume we can move the copyright to the source files themselves?

[nikhita]

I'll leave it up to the LF/CNCF how they want to handle license compliance situations.

On the NOTICE, removing that file is okay; I assume we can move the copyright to the source files themselves?

@swinslow @caniszczyk wdyt?

[swinslow]

The practice in kubernetes' repos has been to list the copyright holder in source files as "The Kubernetes Authors" and similar, so that there isn't continual churn in trying to keep notices up to date as subsequent commits are made. From a quick look it appears that the source files in aws-fsx-csi-driver are already following this practice so no changes to them should be needed.

[nikhita]

So from what I gather, the next steps would be to remove the NOTICE file and keep the THIRD_PARTY file?

@hyandell and @swinslow can you both confirm that Amazon and LF/CNCF would be good with this? Thanks! :)

[swinslow]

Yes, this would be fine from the CNCF side.

[nikhita]

Oh, I just realized about this. This is still outstanding.

Please review @jpeddicord commits. They were repository creation actions.

My understanding is that all commits should have CLA signed...but @swinslow @caniszczyk could you confirm that it is ok to not have the CLA signed for the initial commit?

Ref:

• https://github.com/d-nishi/aws-fsx-csi-driver/commits?author=jpeddicord
• https://github.com/d-nishi/aws-efs-csi-driver/commits?author=jpeddicord

Alternatively, @jpeddicord - could you sign the CNCF CLA?

[jpeddicord]

CLA signed. (I think. I got "You are already authorized to contribute code to this project through your membership with CNCF - Amazon." when going through that.)

[d-nishi]

We will finish the transfer tomorrow then

[nikhita]

Migration done! :tada:

• https://github.com/kubernetes-sigs/aws-fsx-csi-driver
• https://github.com/kubernetes-sigs/aws-efs-csi-driver

I've created https://github.com/kubernetes/org/pull/677 to add GitHub teams for both repos. After that's merged, a postsubmit will run which will actually create those teams on GitHub. I'll then manually grant access to these teams.

Once that's done + the repo has been added to sigs.yaml, we can close this issue. :)

[nikhita]

https://github.com/kubernetes/community/pull/3552 added repos to sigs.yaml and access has been granted to the respective teams.

/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

https://github.com/kubernetes/community/pull/3552 added repos to sigs.yaml and access has been granted to the respective teams.

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