style(namespace): consistent position for namespace arg

Author: slack

src/contributing/development-environment.md

@@ -203,29 +203,29 @@ Once your customized Deis component has been deployed, here are some helpful com
 ### See All Deis Pods
 
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 ```
 
 ### Describe a Pod
 
 This is often useful for troubleshooting pods that are in pending or crashed states:
 
 ```
-$ kubectl describe -f <pod name> --namespace=deis
+$ kubectl --namespace=deis describe -f <pod name>
 ```
 
 ### Tail Logs
 
 ```
-$ kubectl logs -f <pod name> --namespace=deis
+$ kubectl --namespace=deis logs -f <pod name>
 ```
 
 ### Django Shell
 
 Specific to [deis/controller][controller]
 
 ```
-$ kubectl exec -it <pod name> --namespace=deis -- python manage.py shell
+$ kubectl --namespace=deis exec -it <pod name> -- python manage.py shell
 ```
 
 Have commands other Deis contributors might find useful? Send us a PR!

src/installing-workflow/index.md

@@ -66,19 +66,19 @@ You'll need to wait for the pods that it launched to be ready. Monitor their sta
 by running:
 
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 ```
 
 If you would like `kubectl` to automatically update as the pod states change, run (type Ctrl-C to stop the watch):
 ```
-$ kubectl get pods --namespace=deis -w
+$ kubectl --namespace=deis get pods
 ```
 
 Depending on the order in which the Workflow components start, you may see a few components restart. This is common during the installation process, if a component's dependencies are not yet available the component will exit and Kubernetes will automatically restart the containers.
 
 Here, you can see that controller, builder and registry all took a few loops before there were able to start:
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 NAME                          READY     STATUS    RESTARTS   AGE
 deis-builder-hy3xv            1/1       Running   5          5m
 deis-controller-g3cu8         1/1       Running   5          5m

src/managing-workflow/configuring-dns.md

@@ -23,7 +23,7 @@ DNS for any applications using a "custom domain" (a fully-qualified domain name
 Although it is dependent upon your distribution of Kubernetes and your underlying infrastructure, in many cases, the IP(s) or existing fully-qualified domain name of a load balancer can be determined directly using the `kubectl` tool:
 
 ```
-$ kubectl describe service deis-router --namespace=deis | grep "LoadBalancer Ingress"
+$ kubectl --namespace=deis describe service deis-router | grep "LoadBalancer Ingress"
 LoadBalancer Ingress:	a493e4e58ea0511e5bb390686bc85da3-1558404688.us-west-2.elb.amazonaws.com
 ```
 
@@ -40,7 +40,7 @@ In general, for any IP, `a.b.c.d`, the fully-qualified domain name `any-subdomai
 To begin, find the node(s) hosting router instances using `kubectl`:
 
 ```
-$ kubectl describe pod deis-router --namespace=deis | grep Node
+$ kubectl --namespace=deis describe pod deis-router | grep Node
 Node:       ip-10-0-0-199.us-west-2.compute.internal/10.0.0.199
 Node:       ip-10-0-0-198.us-west-2.compute.internal/10.0.0.198
 ```

src/managing-workflow/configuring-load-balancers.md

@@ -16,7 +16,7 @@ Begin by determining the "node ports" for the `deis-router` service:
 
 
 ```
-$ kubectl describe service deis-router --namespace=deis
+$ kubectl --namespace=deis describe service deis-router
 ```
 
 This will yield output similar to the following:

src/managing-workflow/platform-logging.md

@@ -13,7 +13,7 @@ Logger acts like a syslog server and receives all log messages that are occurrin
 With the release of workflow-beta3 chart the logging system is part of the main installation of Workflow. You will then need to watch the components come up and verify they are in a running state by executing the following command:
 
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 ```
 
 You should see output similar to this:
@@ -46,8 +46,8 @@ Once the pod has restarted, you can verify the logging system is working by goin
 ```
 Error: There are currently no log messages. Please check the following things:
 1) Logger and fluentd pods are running.
-2) The application is writing logs to the logger component by checking that an entry in the ring buffer was created: kubectl logs <logger pod> --namespace=deis
-3) Making sure that the container logs were mounted properly into the fluentd pod: kubectl exec <fluentd pod> --namespace=deis ls /var/log/containers
+2) The application is writing logs to the logger component by checking that an entry in the ring buffer was created: kubectl  --namespace=deis logs <logger pod>
+3) Making sure that the container logs were mounted properly into the fluentd pod: kubectl --namespace=deis exec <fluentd pod> ls /var/log/containers
 ```
 
 ## Architecture Diagram

src/quickstart/provider/aws/dns.md

@@ -8,7 +8,7 @@ By describing the `deis-router` service, you can see what hostname allocated by
 cluster:
 
 ```
-$ kubectl describe svc deis-router --namespace=deis | egrep LoadBalancer
+$ kubectl --namespace=deis describe svc deis-router | egrep LoadBalancer
 Type:                   LoadBalancer
 LoadBalancer Ingress:   abce0d48217d311e69a470643b4d9062-2074277678.us-west-1.elb.amazonaws.com
 ```

src/quickstart/provider/aws/install-aws.md

@@ -54,19 +54,19 @@ You'll need to wait for the pods that it launched to be ready. Monitor their sta
 by running:
 
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 ```
 
 If you would like `kubectl` to automatically update as the pod states change, run (type Ctrl-C to stop the watch):
 ```
-$ kubectl get pods --namespace=deis -w
+$ kubectl --namespace=deis get pods -w
 ```
 
 Depending on the order in which the Workflow components start, you may see a few components restart. This is common during the installation process, if a component's dependencies are not yet available the component will exit and Kubernetes will automatically restart the containers.
 
 Here, you can see that controller, builder and registry all took a few loops before there were able to start:
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 NAME                          READY     STATUS    RESTARTS   AGE
 deis-builder-hy3xv            1/1       Running   5          5m
 deis-controller-g3cu8         1/1       Running   5          5m
@@ -96,7 +96,7 @@ By describing the `deis-router` service, you can see what IP hostname has been a
 cluster:
 
 ```
-$ kubectl describe svc deis-router --namespace=deis | egrep LoadBalancer
+$ kubectl --namespace=deis describe svc deis-router | egrep LoadBalancer
 Type:                   LoadBalancer
 LoadBalancer Ingress:   abce0d48217d311e69a470643b4d9062-2074277678.us-west-1.elb.amazonaws.com
 ```

src/quickstart/provider/gke/install-gke.md

@@ -52,19 +52,19 @@ You'll need to wait for the pods that it launched to be ready. Monitor their sta
 by running:
 
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 ```
 
 If you would like `kubectl` to automatically update as the pod states change, run (type Ctrl-C to stop the watch):
 ```
-$ kubectl get pods --namespace=deis -w
+$ kubectl --namespace=deis get pods -w
 ```
 
 Depending on the order in which the Workflow components start, you may see a few components restart. This is common during the installation process, if a component's dependencies are not yet available the component will exit and Kubernetes will automatically restart the containers.
 
 Here, you can see that controller, builder and registry all took a few loops before there were able to start:
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 NAME                          READY     STATUS    RESTARTS   AGE
 deis-builder-miekp            1/1       Running   1          2m
 deis-controller-egu7x         1/1       Running   3          2m

src/quickstart/provider/vagrant/install-vagrant.md

@@ -52,12 +52,12 @@ You'll need to wait for the pods that it launched to be ready. Monitor their sta
 by running:
 
 ```
-$ kubectl get pods --namespace=deis
+$ kubectl --namespace=deis get pods
 ```
 
 If you would like `kubectl` to automatically update as the pod states change, run (type Ctrl-C to stop the watch):
 ```
-$ kubectl get pods --namespace=deis -w
+$ kubectl --namespace=deis get pods -w
 ```
 
 Depending on the order in which the Workflow components start, you may see a few components restart. This is common during the installation process, if a component's dependencies are not yet available the component will exit and Kubernetes will automatically restart the containers.