Adding OWNERS for docs.

docs/admin/salt.md

@@ -1,5 +1,9 @@
----
----
+---
+assignees:
+- davidopp
+- lavalamp
+
+---
 
 The Kubernetes cluster can be configured using Salt.
 
@@ -13,11 +17,11 @@ The **salt-minion** service runs on the kubernetes-master and each kubernetes-no
 
 Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce).
 
-```shell
+```shell
 [root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf
 master: kubernetes-master
-```
-
+```
+
 The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes.
 
 If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master.  It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API.
@@ -34,27 +38,27 @@ All remaining sections that refer to master/minion setups should be ignored for
 
 Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions.  It is not recommended to use this security configuration in production environments without deeper study.  (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
 
-```shell
+```shell
 [root@kubernetes-master] $ cat /etc/salt/master.d/auto-accept.conf
 open_mode: True
 auto_accept: True
-```
-
+```
+
 ## Salt minion configuration
 
 Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine.
 
 An example file is presented below using the Vagrant based environment.
 
-```shell
+```shell
 [root@kubernetes-master] $ cat /etc/salt/minion.d/grains.conf
 grains:
   etcd_servers: $MASTER_IP
   cloud: vagrant
   roles:
     - kubernetes-master
-```
-
+```
+
 Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files.
 
 The following enumerates the set of defined key/value pairs that are supported today.  If you add new ones, please make sure to update this list.
@@ -77,16 +81,16 @@ These keys may be leveraged by the Salt sls files to branch behavior.
 
 In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.).  As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following.
 
-```liquid
+```liquid
 {% raw %}
 {% if grains['os_family'] == 'RedHat' %}
 // something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc.
 {% else %}
 // something specific to Debian environment (apt-get, initd)
-{% endif %}
+{% endif %}
 {% endraw %}
-```
-
+```
+
 ## Best Practices
 
 1.  When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments.  This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.