Proxy Minions have undergone a significant overhaul in 2015.8.
salt-proxy
command/etc/salt/proxy
./var/log/salt/proxy
.salt-proxy
takes a --proxyid
switch. This becomes the id of the proxy
minion, and thus the pillar key under which the configuration for the proxy is
looked up./srv/pillar/top.sls
:
base:
minioncontroller:
- dumbdevice1
- dumbdevice2
/srv/pillar/dumbdevice1.sls
:
dumbdevice1:
proxy:
proxytype: networkswitch
host: 172.23.23.5
username: root
passwd: letmein
/srv/pillar/dumbdevice2.sls
:
dumbdevice2:
proxy:
proxytype: networkswitch
host: 172.23.23.6
username: root
passwd: letmein
This would cause the minion with id minioncontroller
to fork off two
processes and rename their minion id's to dumbdevice1
and dumbdevice2
.
These processes would initiate a new connection to the master.
For proxy minion controllers this made it quite difficult to tell which process was doing what. Also, if the controlling minion died for any reason, it would take all the proxies with it. The new pillar structure does away with the id's in the lower level pillar files and brings proxy configuration to the same level with all other minions.
/srv/pillar/top.sls
:
base:
dumbdevice1:
- dumbdevice1
dumbdevice2:
- dumbdevice2
/srv/pillar/dumbdevice1.sls
:
/srv/pillar/dumbdevice2.sls
:
Proxies can be better tracked via system process utilities:
..code-block:: bash
root@raring64:/var/log/salt# ps guax | grep p8 root 15215 pts/3 S+ 10:57 0:00 python salt-proxy -l debug --proxyid=p8000 root 15275 pts/5 S+ 10:57 0:00 python salt-proxy -l debug --proxyid=p8002
Proxies still gather a significant number of grains from the host. This is useful for targeting, but does not obviate the need for custom grains to better support your controlled devices. See the proxy documentation for writing grains modules for your proxy.
Future enhancements of proxy minions could include execution modules and states for easier proxy process management.