Separate repo for generic cli utils

[juanvallejo]

Feature Description

• One-line feature description (can be used as a release note): The package pkg/kubectl/genericclioptions should be split out from kubectl into a separate repo in order to allow use of it by plugin authors and third-party clients.
• Primary contact (assignee): juanvallejo
• Responsible SIGs: sig-cli
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: pwittrock, soltysh
• Approver (likely from SIG/area to which feature belongs): pwittrock, soltysh
• Feature target (which target equals to which milestone): 1.12
  • Beta release target (x.y): 1.12

As part of ongoing work that focuses on containing all significant kubectl command utilities in a single package (pkg/kubectl/genericclioptions), this package should be split out into its own repo in order to allow use by third-party clients as well as plugins. The self-contained genericclioptions package currently provides all of the major components (kubeconfig parsing, obtaining a config and a REST client, printing, etc.) needed to build a generic kubectl command. Making this package into a separate repository would allow external plugins to behave and be structured as a typical kubectl command, particularly in terms of communicating with the api server.

cc @soltysh

[juanvallejo]

/sig cli

[justaugustus]

@juanvallejo @soltysh --

It looks like this feature is currently in the Kubernetes 1.12 Milestone.

If that is still accurate, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Set the following:

• Description
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.

---

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!
/stage beta

[zparnold]

Hey there! @juanvallejo I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

[soltysh]

@zparnold sorry for the late reply but I can't modify the tracking spreadsheet. This feature won't have any doc updates.

[zparnold]

Thanks!

…

On Tue, Aug 28, 2018 at 6:58 AM Maciej Szulik ***@***.***> wrote: @zparnold <https://github.com/zparnold> sorry for the late reply but I can't modify the tracking spreadsheet. This feature won't have any doc updates. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#581 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE81SKy7dYnBaG7wm0n34yXJ3kVGer_Gks5uVUyEgaJpZM4U4vbB> .

[ameukam]

Hi folks,
Kubernetes 1.13 is going to be a 'stable' release since the cycle is only 10 weeks. We encourage no big alpha features and only consider adding this feature if you have a high level of confidence it will make code slush by 11/09. Are there plans for this enhancement to graduate to beta/stable within the 1.13 release cycle? If not, can you please remove it from the 1.12 milestone or add it to 1.13?

We are also now encouraging that every new enhancement aligns with a KEP. If a KEP has been created, please link to it in the original post. Please take the opportunity to develop a KEP

[juanvallejo]

Are there plans for this enhancement to graduate to beta/stable within the 1.13 release cycle? If not, can you please remove it from the 1.12 milestone or add it to 1.13?

No plans to graduate this feature. @soltysh can you remove this from 1.12 milestone?
Thanks

[kacole2]

/milestone clear

[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

[claurence]

@juanvallejo Hello - I’m the enhancement’s lead for 1.14 and I’m checking in on this issue to see what work (if any) is being planned for the 1.14 release. Enhancements freeze is Jan 29th and I want to remind that all enhancements must have a KEP

[soltysh]

@claurence no work is being planned for 1.14 for this issue.

[kacole2]

I'm the Enhancement Lead for 1.15. Is this feature going to be graduating alpha/beta/stable stages in 1.15? Please let me know so it can be tracked properly and added to the spreadsheet. This also needs a KEP to be included.

Once coding begins, please list all relevant k/k PRs in this issue so they can be tracked properly.

[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

[rbitia]

Hi @juanvallejo, I'm the 1.16 Enhancement Shadow. Is this feature going to be graduating alpha/beta/stable stages in 1.16? Please let me know so it can be added to the 1.16 Tracking Spreadsheet. If it's not's graduating, I will remove it from the milestone and change the tracked label.

Once coding begins or if it already has, please list all relevant k/k PRs in this issue so they can be tracked properly.

As a reminder, every enhancement requires a KEP in an implementable state with Graduation Criteria explaining each alpha/beta/stable stages requirements.

Milestone dates are Enhancement Freeze 7/30 and Code Freeze 8/29.

Thank you.

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