Org: kubernetes-sigs/network-policy-apis

[jayunit100]

New Repo, Staging Repo, or migrate existing

Migrate https://github.com/jayunit100/network-policy-subproject ->

Requested name for new repository

kubernetes-sigs/network-policy-working-group

Which Organization should it reside

kubernetes-sigs

If not a staging repo, who should have admin access

jayunit100, rikatz, andrewsykim , abhiraut

If not a staging repo, who should have write access

jayunit100, rikatz, andrewsykim, abhiraut

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

jayunit100, rikatz, andrewsykim, abhiraut

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

jayunit100, rikatz, andrewsykim, abhiraut

What should the repo description be

A repository for upcoming network policy related advancements in Kubernetes.

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

this is part of the NetworkPolicy v2 subproject for sig-network

Approvals

Authoritative requirements are here: https://git.k8s.io/community/github-management/kubernetes-repositories.md

Additional context for request

We've been an informal working group for 6 months, and a formal one for about 2 months, and recently got approval from the sig-network group to begin working on a series of 3 KEPs, so we're starting to get more focused, and thus need a visible / neutral upstream workspace.

[jayunit100]

@thockin @caseydavenport @danwinship I assume we need someone from sig-network to approve this

[rikatz]

/assign @caseydavenport

Casey, can we have your approval in this please? :)

We're moving the subproject (and re-organizing docs, user stories, implementations, etc) and need a non personal repo for that!

Thanks!!

[andrewsykim]

I'm personally in favor of naming the repo something like kubernetes-sigs/network-policy-apis so the scope of the project is clear, but I'll defer to @jayunit100 and @rikatz on naming.

[rikatz]

I'm afraid of generating confusion in users searching for stuff about netpol and getting into us, so I'm up to calling this 'traffic policy' as we're going to start working on something new :)

Or using just network-policy to me also seems fine, as we're not going necessarily to work only in the APIs (I think) but also in some auxiliary tools here :)

Jay, your vote pls ;)

[jayunit100]

im in favor of having all our content in one place as a way of building gravity around what we do.
helping people with the V1 APIs is in my opinion an EXTREMELY IMPORTANT way for us to gather feedback on them.

[rikatz]

@nikhita So our consensus is to have a repo called sig-network-policy-api (the same name of the slack channel we asked) :)

Will wait for the sig leads to take a look into this issue and approve it, if they agree with.

Thanks

[caseydavenport]

/approve

[andrewsykim]

/retitle kubernetes-sigs/network-policy-apis

Based on Ricardo's comment above.

[andrewsykim]

Also FYI that the issue description is using an incorrect handle for my username, it should be andrewsykim (NOT a_sykim) :)

[nikhita]

/assign

@jayunit100 We still need to do a few things before we can migrate the repo :)

• Can you please add the template files as per https://github.com/kubernetes/kubernetes-template-project? Please also update the README to include links to slack channels, mailing lists and code of conduct.

• Is the repo expected to host code as well? If no, you'll need to use Creative Commons 4.0 license - https://github.com/kubernetes/website/blob/master/LICENSE

• The following contributors to the repo have not signed the CLA.

  • @gjsj
  • @dumlutimuralp
  • @dbyron0
  • @Dyanngg

Note: if your name is listed above, could you please sign the CNCF CLA so that we can migrate https://github.com/jayunit100/network-policy-subproject to Kubernetes? Instructions on how to sign the CLA can be found here. Thank you! :)

[andrewsykim]

We still need to do a few things before we can migrate the repo :)

I would be in favor of starting this repo from scratch as opposed to migrating the existing one. The existing one was a temporary home for draft KEPs which should really belong in k/enhancements anyways.

[nikhita]

@jayunit100 can you update the issue body to reflect the new changes? :)

[jayunit100]

/close

[k8s-ci-robot]

@jayunit100: Closing this issue.

In response to this:

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

[jayunit100]

Our current existing KEPs (from the original purpose of this repo) are now living here:

• https://github.com/kubernetes/enhancements/pull/2113
• https://github.com/kubernetes/enhancements/pull/2090

Lets sync w/ the broader group monday and figure out wether we actually need a repo moving forward, as this issues original purpose seems to be obviated (or someone else can recreate a new issue w a more precise definition of what were asking for I guess?)