一、下发grains：
salt master端自定义grains项目，并下发到minion端，举例说明，下发max_open_file。
1、在salt master端的目录_grains下创建grains_openfile.py
import os,sys,commands
def grains_openfile(): ''' return os max open file of grains value ''' grains = {} _open_file = 65536 try: getulimit=commands.getstatusoutput('source /etc/profile;ulimit -n') except Exception,e: pass if getulimit[0] == 0: _open_file = int(getulimit[1]) grains['max_open_file'] = _open_file return grains2、下发到minion端（salt '*' saltutil.sync_grains）
minion端接收并缓存到目录var/cache/minion/files/base/_grains
master端会md5加密传输并缓存到var/cache/roots/hash/base
3、minion端对下发项目值进行修改后，需要重启minion服务才可生效。
4、从master端对grains进行清cache和刷新grains可以去掉grains项目。
salt.modules.saltutil.clear_cache()
Forcibly removes all caches on a minion.
salt.modules.saltutil.refresh_modules()
Signal the minion to refresh the module and grain data
具体查看：
二、注意配置文件中几个参数：
master 端：
1、 minion_data_cache: True
为True时，会缓存各种定义的分组信息，包括grains,pillar,nodegroup等。
为False时，不缓存，minion好像始终是所有key交互成功的主机。
2、 loop_interval: 60
定义进程周期读取配置文件的频率，和执行salt命令读取配置文件互不冲突；
理论上修改配置文件不用重启，但经过测试，修改主配置文件的参数，不重启服务，并没有生效，有待以后深入测试。
minion端：
1、acceptance_wait_time: 15
acceptance_wait_time_max: 10
等待key验证的时间频率和最大次数，但经测试最大次数好像不管用。
2、rejected_retry: True
key被拒后是关闭进程，还是继续重试。true为重试，默认false为关闭进程。
3、auth_timeout: 30
auth_tries: 3
等待key验证的超时时间和次数，经测试好像不管用。
三、sls文件中的先决条件和状态参数：
比如：require,require_in ,watch, watch_in, include 更多查看：
状态管理模块页面：
内置命令模块页面：
四、schedule的使用：
1、可以使用命令:
salt '*' schedule.add job2 function='cmd.run' job_args="['date >> /tmp/date.log']" seconds=60
2、使用pillar配置：
schedule: job: function: cmd.run args: - /bin/date > /tmp/a.log seconds: 60
salt '*' saltutil.refresh_pillar
3、使用state配置：
[root@openstack-control salt]# cat schedule.sls
job1: schedule.present: - function: cmd.run - job_args: - /bin/date >> /tmp/a.log - cron: '*/5 * * * *' #- seconds: 60salt '*' state.sls schedule
4、查看schedule: salt '*' schedule.list