summaryrefslogtreecommitdiff
path: root/contributors
diff options
context:
space:
mode:
authoreduartua <eduartua@gmail.com>2019-01-28 12:01:55 -0600
committereduartua <eduartua@gmail.com>2019-02-06 16:22:26 -0600
commit4644fb47e75d59b1246f013d7f9c273abbf3cac3 (patch)
tree294dadde09bcb366941cbbb693f2bdef7aa99aef /contributors
parent37052c849095856e1fc2a793c3256e05a0f4267b (diff)
all URL pointing to kubectl-conventions.md have been fixed
Diffstat (limited to 'contributors')
-rw-r--r--contributors/design-proposals/architecture/declarative-application-management.md2
-rw-r--r--contributors/guide/coding-conventions.md2
-rw-r--r--contributors/guide/pull-requests.md2
3 files changed, 3 insertions, 3 deletions
diff --git a/contributors/design-proposals/architecture/declarative-application-management.md b/contributors/design-proposals/architecture/declarative-application-management.md
index 68425d02..f1419200 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 880c1833..fe6f376c 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 a9c26086..cdab6ce4 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?