salt-stack

问题 Running an initial install takes about 20 minutes, running a salt-call state.highstate takes about 6 minutes. That's not unreasonable, but I'd like to speed it up, but I'm not sure how to find the slowest states. Is there any way to find how long each state takes to run other than watching my screen with a stopwatch for 6 minutes? 回答1: sudo salt-call state.highstate provides start-time and duration for each state. ---------- ID: ntp-removed Function: pkg.removed Result: True Comment: None of

问题 Given how flexible jinja templating can be with saltstack and the numerous pillar variables are merged into the template; I would find it useful to be able to get salt to 'render' the full sls out to screen before i push it out. Is there a way of doing this? 回答1: Just to answer my own question: I knew that state.show_top existed. So I tried state.show_sls, and voila! Exactly what I'm after. 来源： https://stackoverflow.com/questions/34191710/how-to-render-and-dump-the-file-sls-with-salt-stack

问题 I was trying to execute this saltstack command cmd = "/usr/local/bin/salt -L 'target' cp.get_dir salt://allapps/V001 /u02/tomcat-8.0.24/8080/webapps/" output = os.popen(cmd).readlines() using python. I have started 8 threads in parallel to run this command, but each thread costs about 5 min to finish. But I run this command in terminal or python console standalone, it just takes me about 2-3 secs to complete. First I thought it was because of readlines() consuming lots of memory, but it still

问题 I am trying to test salt-cloud saltify to deploy/install salt-minions on target machines. I created three vagrant machines and names them master , minion-01 and minion-02 . all the machines were same like this; root@master:/home/vagrant# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.4 LTS Release: 14.04 Codename: trusty then on master I followed this http://repo.saltstack.com/#ubuntu to install salt-master(manually ofcourse). then in master I

问题 Is salt caching /etc/hosts? I'm in a situation where I change /etc/hosts such that the FQDN points to the external IP address instead of 127.0.0.1 The problem is that in the first run, the fqdn_ipv4 stays 127.0.0.1 and I need to rerun salt '*' state.highstate to get the right values. This leads to problems like this, which cost me a lot of time. Is salt rendering everything before execution (or caches DNS)? How do I address this problem? The state file looks like this: 127.0.0.1: host.absent:

问题 I found this answer here that tells how to get the IP of another minions inside a template but i can't get host.fqdn or host.ip . When I use host I get the full domain name and not the IP. When I ran it on console it gets the ips, but inside the template it does return a str object Unable to manage file: Jinja variable 'str object' has no attribute 'fqdn' I tried this one here but this one didn't even show a result. I want to be able to build a hosts file. Each minion have some roles set as

问题 I'm trying to build the hosts file on my servers using salt. In some of the servers, the eth0 network interface has the inet set and in some others is the bond0 interface. In the init.sls i have: /etc/hosts: file.managed: - source: salt://configs/etc/hosts/hostsfile - user: root - group: root - mode: 644 - template: jinja - context: {% for host, interface in salt['mine.get']('*', 'network.interfaces').items() %} {% if interface['bond0'].has_key('inet') %} ip: {{ salt['network.interfaces']()[

问题 I am using jinja2 template to install/upgrade packages. The logic was setting a variable for current installed version and compare it with the available version. It was working fine but once we passed in to 10.x, comparison quit working. Is it possible to cast the variable so it can correctly identify 10.9.8 is greater than 9.8.7? Thanks current_version=['9.8.7'] {% if current_version < '10.9.8' %} 回答1: There's a special test version_compare: {% if current_version | version_compare('10.9.8',

问题 I have the following saltstack top file. 'blog.php.*': - php-apps - php-apps.blog 'app.php.*': - php-apps - php-apps.some-app '*phpone*': - php-apps - php-apps.blog - php-apps.some-app When I run high state for the above to environments It works fine. like this salt 'blog.php.*' state.highstate or salt 'app.php.*' state.highstate But when I run the same for the third server it fails. salt '*phpone*' state.highstate Error: No matching sls found for 'php_apps' in env 'base' I went to the minion

问题 I am trying to access salt master from salt-minion. But, I am unable to get the keys on salt-master. On my VM, I installed salt-master and on my Windows, I installed salt-minion . I have given master IP address on my minion vi salt\conf\minion master: master ip address I tried to run the command below: c:\salt\salt-minion.exe -l debug -c c:\salt\conf I am getting a message like below: [DEBUG ] Reading configuration from c:\salt\conf\minion [INFO ] Using cached minion ID from c:\salt\conf