问题背景：搭建一个多节点后端集群，使用saltstack作为底层管理，使用Python封装saltstack接口成逻辑层。通过逻辑层的调用实现对整个集群的运维管理。
问题：随着项目中模块的增多，发现saltstack并不能很好的满足集群管理功能。原因就是saltAPI的返回值不一定正确。简单的来讲，salt每一个接口(以下所有的saltAPI均指salt同步接口)调用时都会产生一个job，当job在5s(默认参数)内没有返回时候，会产生一个fetch-job去查找执行的job，每10s检测一次，判断job是否还在运行，然后返回结果。但salt的机制中fetch-job不一定能拿到job的返回值，为不可信的。在实际测试中发现，调用salt-api时，salt-api返回为空（正常应该为一个字典或字符串，多个salt-api执行时容易出现异常情况），使用fetch-job去查找job，试图获取返回值，但发现fetch-job也为不可信的（原因就是fetch-job一旦有一次查找job失败，则停止查找）
环境准备：
salt --version查看版本：salt 2017.7.1 (Nitrogen)
两台机器，搭建salt-master(ip:192.168.136.191) salt-minion(ip:192.168.136.191，ip:192.168.136.192)
1.演示fetch-job
在191主机上执行test.sleep 20，然后通过salt-run查看
通过salt-run jobs.list_jobs 查看上一步中执行的任务
分析：其中第一个标注中，是执行的test.sleep 20秒任务，然后在5s之后，也就是15:08:41时候，触发了一个find_job。此时，find_job成功找到job，所以没有返回。第三个标注中，触发了第二个find_job，在这个job之后没有find_job任务了(find_job在没有找到job时，不继续执行了)，可以认为这个find_job是没有找到job了。
补充测试，下面一个是执行test.sleep 25秒的结果，分析同上。
2.继续探究
我尝试模拟fetch-job失败的情况，但是没有重现。可能的原因是模拟的系统太单一，没有完整项目的复杂。完整的项目中，涉及到的模块多，都是调用salt-api接口，就可能造成fetch-job失败的情况。总的来说，在系统简单的时候，salt-api返回值是可信的，但随着系统模块的增加，会导致返回值不能成功返回。
没有模拟出环境就解释下用到的几个接口（截图自官方文档）
1.查询所有的job，通常job任务比较多，推荐使用 " > jobs.txt" 重定向到一个文件，再进行查找
2.配合missing=True参数使用，能够查询find_job是否丢失（实际上fetch-job也是一个job任务）。
3.打印job执行结果，在job没有执行结束的时候调用，返回为 minion not return
4.查找一个job，功能类似salt自带的fetch-job
总结：
1.简单系统在使用salt-api时候，salt-api能按照期望的返回。（具体什么程度为简单，没有具体的数据，只是真实项目中做到后期，模块量庞大的时候发现了这个问题）
2.复杂系统使用salt-api接口的时候，会有以下情况：
a.单纯的使用salt-api接口，接口已经返回，返回为空（没有返回值）。但实际job依然在执行，待job真实执行结束后，通过salt-run jobs.print_job xxx，能查看返回值。在没有执行结束的时候查看，返回为【minion not return】（xxx为jid, 即job id，文中图里的每一组数据唯一标识）
b.为了解决a中问题，等待fetch-job不再查找时，认定job执行成功。在实际操作中，观察到fetch-job可能会失败，即job实际还在运行，但fetch-job查找job失败，然后不再继续fetch-job。（观察方法：fetch-job已经不再查找job，但手动使用saltutil.find_job能查找到job还在继续运行）
c.在job没有执行结束的时候，使用jobs.list_jobs打印出的job没有返回，但在最终job执行结束后，原来的job会有返回值。说明salt会去修改job执行的结果，并不是类似日志一样，单纯根据时间来记录
3.实际情况中，最终所有的job能执行成功，但问题的关键在于这个成功是不可控的。无法获知一个指令执行的结束时间，也就无法获取其执行结果。
问题依然没有解决，如果有相同问题的朋友，欢迎联系我交流 :)