From 4644fb47e75d59b1246f013d7f9c273abbf3cac3 Mon Sep 17 00:00:00 2001 From: eduartua Date: Mon, 28 Jan 2019 12:01:55 -0600 Subject: [PATCH] all URL pointing to kubectl-conventions.md have been fixed --- .../architecture/declarative-application-management.md | 2 +- contributors/guide/coding-conventions.md | 2 +- contributors/guide/pull-requests.md | 2 +- sig-cli/migrated-from-wiki/roadmap-kubectl.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributors/design-proposals/architecture/declarative-application-management.md b/contributors/design-proposals/architecture/declarative-application-management.md index 68425d027..f14192001 100644 --- a/contributors/design-proposals/architecture/declarative-application-management.md +++ b/contributors/design-proposals/architecture/declarative-application-management.md @@ -252,7 +252,7 @@ Deployment of bespoke applications involves multiple steps: Step 1, building the image, is out of scope for Kubernetes. Step 3 is covered by kubectl apply. Some tools in the ecosystem, such as [Draft](https://github.com/Azure/draft), combine the 3 steps. -Kubectl contains ["generator" commands](https://github.com/kubernetes/community/blob/master/contributors/devel/kubectl-conventions.md#generators), such as [kubectl run](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#run), expose, various create commands, to create commonly needed Kubernetes resource configurations. However, they also don’t help users understand current best practices and conventions, such as proper label and annotation usage. This is partly a matter of updating them and partly one of making the generated resources suitable for consumption by new users. Options supporting declarative output, such as dry run, local, export, etc., don’t currently produce clean, readable, reusable resource specifications ([example](https://blog.heptio.com/using-kubectl-to-jumpstart-a-yaml-file-heptioprotip-6f5b8a63a3ea))**.** We should clean them up. +Kubectl contains ["generator" commands](/contributors/devel/sig-cli/kubectl-conventions.md#generators), such as [kubectl run](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#run), expose, various create commands, to create commonly needed Kubernetes resource configurations. However, they also don’t help users understand current best practices and conventions, such as proper label and annotation usage. This is partly a matter of updating them and partly one of making the generated resources suitable for consumption by new users. Options supporting declarative output, such as dry run, local, export, etc., don’t currently produce clean, readable, reusable resource specifications ([example](https://blog.heptio.com/using-kubectl-to-jumpstart-a-yaml-file-heptioprotip-6f5b8a63a3ea))**.** We should clean them up. Openshift provides a tool, [oc new-app](https://docs.openshift.com/enterprise/3.1/dev_guide/new_app.html), that can pull source-code templates, [detect](https://github.com/kubernetes/kubernetes/issues/14801)[ application types](https://github.com/kubernetes/kubernetes/issues/14801) and create Kubernetes resources for applications from source and from container images. [podex](https://github.com/kubernetes/contrib/tree/master/podex) was built to extract basic information from an image to facilitate creation of default Kubernetes resources, but hasn’t been kept up to date. Similar resource generation tools would be useful for getting started, and even just [validating that the image really exists](https://github.com/kubernetes/kubernetes/issues/12428) would reduce user error. diff --git a/contributors/guide/coding-conventions.md b/contributors/guide/coding-conventions.md index 880c1833c..fe6f376c7 100644 --- a/contributors/guide/coding-conventions.md +++ b/contributors/guide/coding-conventions.md @@ -59,7 +59,7 @@ following Go conventions - `stateLock`, `mapLock` etc. - [API conventions](/contributors/devel/api-conventions.md) - - [Kubectl conventions](/contributors/devel/kubectl-conventions.md) + - [Kubectl conventions](/contributors/devel/sig-cli/kubectl-conventions.md) - [Logging conventions](/contributors/devel/sig-instrumentation/logging.md) diff --git a/contributors/guide/pull-requests.md b/contributors/guide/pull-requests.md index a9c260867..cdab6ce49 100644 --- a/contributors/guide/pull-requests.md +++ b/contributors/guide/pull-requests.md @@ -182,7 +182,7 @@ Let's talk about best practices so your pull request gets reviewed quickly. * [Development guide](/contributors/devel/development.md) * [Coding conventions](../guide/coding-conventions.md) * [API conventions](/contributors/devel/api-conventions.md) -* [Kubectl conventions](/contributors/devel/kubectl-conventions.md) +* [Kubectl conventions](/contributors/devel/sig-cli/kubectl-conventions.md) ## 1. Is the feature wanted? File a Kubernetes Enhancement Proposal Are you sure Feature-X is something the Kubernetes team wants or will accept? Is it implemented to fit with other changes in flight? Are you willing to bet a few days or weeks of work on it? diff --git a/sig-cli/migrated-from-wiki/roadmap-kubectl.md b/sig-cli/migrated-from-wiki/roadmap-kubectl.md index 62d8b6e71..fc639efdd 100644 --- a/sig-cli/migrated-from-wiki/roadmap-kubectl.md +++ b/sig-cli/migrated-from-wiki/roadmap-kubectl.md @@ -2,7 +2,7 @@ `kubectl` is the Kubernetes CLI. -If you'd like to contribute, please read the [conventions](/contributors/devel/kubectl-conventions.md) and familiarize yourself with [existing commands](http://kubernetes.io/docs/user-guide/kubectl-overview/). +If you'd like to contribute, please read the [conventions](/contributors/devel/sig-cli/kubectl-conventions.md) and familiarize yourself with [existing commands](http://kubernetes.io/docs/user-guide/kubectl-overview/). **Owner:** @kubernetes/kubectl