Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate KEPs and Design Proposals from k/community #613

Closed
wants to merge 1,146 commits into from

Conversation

justaugustus
Copy link
Member

@justaugustus justaugustus commented Sep 3, 2018

DO NOT MERGE.
Trying some git gymnastics to move KEPs and design proposals away from k/community...

/sig pm
/sig architecture
/assign
/hold

rel: kubernetes/community#2565

irfanurrehman and others added 30 commits March 13, 2018 21:41
Also update a spelling suggestion by newly implemented hack/verify-spelling.sh
"API sever"->"API server"
Signed-off-by: Joe Beda <joe.github@bedafamily.com>
Signed-off-by: Joe Beda <joe.github@bedafamily.com>
Signed-off-by: Joe Beda <joe.github@bedafamily.com>
Signed-off-by: Joe Beda <joe.github@bedafamily.com>
Signed-off-by: William Zhang <warmchang@outlook.com>
Signed-off-by: Joe Beda <joe.github@bedafamily.com>
- Report both v1.Container & v1.ContainerStatus in PodStatus
- Persist v1.Container as a container runtime label
- Start ephemeral containers from the kubelet pod worker
Proposal for growing FlexVolume size, the feature ticket is at:
kubernetes#304

The original google doc for this proposal is at:
https://docs.google.com/document/d/1dwom9xQ3Fg5F_jJrybr0slp-QsO3_CKiisxzNRoMhec/edit?usp=sharing
- remove `optional` from sections
- remove unused sections
Mostly just propose a repository structure for existing providers
and punt on the details of accepting new cloud providers
... also add Cloud Provider specific  SIGs as participants on this KEP.
Removes proposed repositories for Cloud Provider implementations
currently without a related SIG.
...but I'm sure there are other lurkers out there
…-master

KEP kubeadm join --master workflow
@k8s-ci-robot k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Sep 3, 2018
@justaugustus
Copy link
Member Author

/meow

@k8s-ci-robot
Copy link
Contributor

@justaugustus: cat image

In response to this:

/meow

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.

@k8s-ci-robot
Copy link
Contributor

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.


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. I understand the commands that are listed here.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. label Sep 3, 2018
@justaugustus
Copy link
Member Author

/assign
/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 3, 2018
@justaugustus
Copy link
Member Author

/assign @bgrant0607 @jdumars

@justaugustus
Copy link
Member Author

/check-cla

@justaugustus justaugustus added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Sep 3, 2018
@justaugustus justaugustus changed the title [WIP] Migrate KEPs and Design Proposals from k/community Migrate KEPs and Design Proposals from k/community Sep 3, 2018
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 3, 2018
@calebamiles
Copy link
Contributor

please don't do this yet. Moving the KEPs out of kubernetes/community needs to consider at least

  1. where the tooling for keps should go (in my opinion it should be in a kubernetes/keps repository or similar
  2. how web rendering (hugo or similar) will work and where that tooling should live

I've spent some time thinking about (2) and have just started spitballing (1).

For the KEPs themselves we need to rev the process a bit to

  1. drop numbers until a KEP has reasonable agreement on at least the motivation so that people stop trying to "reserve" numbers

  2. switch to a directory (rather than flat file) format for KEPs to accommodate experience reports and to allow the folks iterating on a KEP to take advantage of the OWNERS process and tooling (and create some basic tooling to attempt automatic-ish conversion of well formed KEPs). Given that it's relatively easy to extract just the KEPs from kubernetes/community I would suggest closing this PR and in favor of one that focuses narrowly on improving the KEP process itself as we discuss how to fold in the rest of the artifacts here

@justaugustus
Copy link
Member Author

@calebamiles -- Yep. The PR was more of a "This is what it could look like if we did this" thing than anything else. The PR will likely go stale before we lay out all of the pieces that we need in k/community.

  1. where the tooling for keps should go (in my opinion it should be in a kubernetes/keps repository or similar

Agreed that it should go in k/keps. I was thinking we'd rename k/features to k/keps, which works to reinforce the fact that KEPs are the currently accepted process. Related comment: kubernetes/community#2245 (comment)

  1. drop numbers until a KEP has reasonable agreement on at least the motivation so that people stop trying to "reserve" numbers

Agreed that the current numbering is broken (kubernetes/community#2245). Another thought we were kicking around was either dropping numbering altogether or creating issues (similar to feature issues in this repo) and using the issue number as the KEP number.

  1. switch to a directory (rather than flat file) format for KEPs to accommodate experience reports and to allow the folks iterating on a KEP to take advantage of the OWNERS process and tooling (and create some basic tooling to attempt automatic-ish conversion of well formed KEPs).

Big +1 here!

Given that it's relatively easy to extract just the KEPs from kubernetes/community I would suggest closing this PR and in favor of one that focuses narrowly on improving the KEP process itself as we discuss how to fold in the rest of the artifacts here

I'm going to leave this open for a little bit for the sake of discussion, but I wholeheartedly agree that there are steps to make the process more clear and discoverable and something like this is merely a subset of what that would look like.

Echoing some of the things I had in mind from kubernetes/community#2565 (comment) over here:

  • announce the forthcoming change
  • merge the k/features PR
  • set up blockade to prevent pushes to either dir in k/community
  • rename k/features to k/keps
  • migrate KEP / design proposal PRs to k/keps
  • create tombstones for files in both dirs in k/community
  • fix KEP / proposal links in k/keps issues
  • update docs in k/keps to clarify process
  • figure out the best way to reconcile the multiple OWNERS files between the two repos

@idvoretskyi
Copy link
Member

/cc

/assign

@justaugustus
Copy link
Member Author

Closing. We'll track this effort here: kubernetes/community#2730
/close

@k8s-ci-robot
Copy link
Contributor

@justaugustus: Closing this PR.

In response to this:

Closing. We'll track this effort here: kubernetes/community#2730
/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.

@justaugustus justaugustus added area/enhancements Issues or PRs related to the Enhancements subproject and removed sig/pm labels Apr 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/enhancements Issues or PRs related to the Enhancements subproject cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.