Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2016-10-27

| Channels | #salt index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 guerby joined #salt
00:04 supermike_ What is the "salty way" for managing a configuration file that needs to have frequent updates? (as a random example, list of customers IP addresses)
00:04 watersoul_ joined #salt
00:07 fracklen joined #salt
00:08 UtahDave supermike_: how frequent are you talking about?  How do you want to initiate it?
00:09 supermike_ Using my example above, it would be whenever a new customer signs up... so randomly.
00:09 supermike_ I was going to cron a highstate... but I figured that it might be worthwhile to check with people smarter than me
00:10 iggy you could have the "customer sign up" hit salt-api to run the states to update the config file
00:12 nZac joined #salt
00:12 orange__ joined #salt
00:13 supermike_ I didn't even think of using salt-api. Glad I asked :)
00:18 BattleChicken left #salt
00:26 antpa joined #salt
00:27 UtahDave left #salt
00:28 fracklen joined #salt
00:43 jas02 joined #salt
00:44 infrmnt joined #salt
00:53 flowstate joined #salt
00:54 DEger joined #salt
00:59 amontalban joined #salt
01:00 jas02 joined #salt
01:05 Roelt_ joined #salt
01:07 antpa joined #salt
01:10 guerby joined #salt
01:20 antpa joined #salt
01:22 spuder joined #salt
01:30 edrocks joined #salt
01:38 f4 joined #salt
01:39 nawwmz joined #salt
01:40 fracklen joined #salt
01:42 sebastian-w joined #salt
01:46 jas02 joined #salt
01:48 ilbot3 joined #salt
01:48 Topic for #salt is now Welcome to #salt! | Latest Versions: 2015.8.12, 2016.3.3 | Support: https://www.saltstack.com/support/ | Logs: http://irclog.perlgeek.de/salt/ | Paste: https://gist.github.com/ (please don't multiline paste into channel) | See also: #salt-devel, #salt-offtopic | Ask with patience as we are volunteers and may not have immediate answers
01:50 catpigger joined #salt
01:51 flowstate joined #salt
02:01 jas02 joined #salt
02:09 djgerm joined #salt
02:11 k_sze[work] joined #salt
02:11 TheoSLC_ joined #salt
02:22 djgerm joined #salt
02:23 fracklen joined #salt
02:34 evle joined #salt
02:36 Karthik_427 joined #salt
02:36 Karthik_427 Hi Team
02:39 Karthik_427 Can u please help me in setting mine functions on minions from master, with out logging into minion
02:47 fracklen joined #salt
02:48 blu_ joined #salt
02:49 jas02 joined #salt
02:49 abednarik joined #salt
02:51 flowstate joined #salt
02:55 akhter joined #salt
03:02 jas02 joined #salt
03:07 nicksloan joined #salt
03:11 DEger joined #salt
03:23 fracklen joined #salt
03:25 armguy joined #salt
03:28 ezvirtual joined #salt
03:37 mpanetta_ joined #salt
03:47 fracklen joined #salt
03:50 jas02 joined #salt
03:52 flowstate joined #salt
03:59 spuder joined #salt
04:03 jas02 joined #salt
04:18 systo joined #salt
04:23 fracklen joined #salt
04:32 edrocks joined #salt
04:35 sp0097 joined #salt
04:40 swa_work joined #salt
04:47 fracklen joined #salt
04:48 DEger joined #salt
04:51 rdas joined #salt
04:52 flowstate joined #salt
04:55 jas02 joined #salt
05:00 spuder joined #salt
05:00 Ni3mm4nd joined #salt
05:04 akhter joined #salt
05:04 jas02 joined #salt
05:13 DarkKnightCZ joined #salt
05:22 alexanderilyin joined #salt
05:23 fracklen joined #salt
05:27 alexzel joined #salt
05:29 alexzel Hello, could someone explain to me what's the difference between using "pillar['something1']['something2']" and "salt['pillar.get']('something1:something2')"
05:30 alexzel is one preferred over the other?
05:30 hemebond alexzel: Not a huge difference but the latter is preferred.
05:30 hemebond They behave slightly differently.
05:30 hemebond But if you stick to the latter you'll be fine.
05:30 alexzel so go for salt['pillar.get']?
05:30 hemebond yip
05:31 alexzel ok thanks
05:31 hemebond ????
05:35 * MTecknology tends to prefer the former, but that's because it caters to my desire to be explicit about things
05:37 MTecknology alexzel: pillar[] is a data structure, salt[pillar.get] is calling a module, which has decent documentation, and lets you do things like provide defaults
05:37 sgo_ joined #salt
05:38 MTecknology https://docs.saltstack.com/en/carbon/ref/modules/all/salt.modules.pillar.html#salt.modules.pillar.get
05:38 alexzel ah I get it now
05:39 alexzel good to know
05:41 __number5__ because pillar is python dict, so you can also `pillar.get('something', 'defaultvalue')`
05:41 __number5__ only that not support multilevel pillar format like `something1:something2`
05:41 MTecknology I probably prefer the former as well because it's much easier to debug inside of pudb
05:42 alexzel same goes for grains I assume?
05:42 __number5__ yes
05:47 fracklen joined #salt
05:52 flowstate joined #salt
05:56 jas02 joined #salt
06:00 yuhlw_____ joined #salt
06:01 impi joined #salt
06:02 jas02 joined #salt
06:03 ivanjaros joined #salt
06:03 akhter joined #salt
06:14 subsignal joined #salt
06:15 subsignal joined #salt
06:22 subsignal joined #salt
06:23 fracklen joined #salt
06:28 DEger joined #salt
06:31 spuder joined #salt
06:32 alexzel if have this map.jinja file https://gist.github.com/alex-zel/d9326da2f9439a7c13249e69fac5711b      how can I select the nested dict for 'sudo_package' based on the release version?
06:36 packeteer joined #salt
06:39 subsignal joined #salt
06:42 haam3r joined #salt
06:44 jas02 joined #salt
06:45 bocaneri joined #salt
06:45 Ni3mm4nd joined #salt
06:47 sgo_ joined #salt
06:48 fracklen joined #salt
06:50 flowstate joined #salt
06:53 zulutango joined #salt
06:55 djgerm joined #salt
07:03 jas02_ joined #salt
07:05 cyborg-one joined #salt
07:09 BlackBishop joined #salt
07:09 BlackBishop any reason why cmd.run 'du -mhs /var' for example would only return something like '123G /var' instead of the full lines ?
07:12 BlackBishop nvm ,I was wanting du -h -T not df :| my bad.
07:13 subsignal joined #salt
07:18 subsignal joined #salt
07:20 ivanjaros3916 joined #salt
07:21 armyriad joined #salt
07:26 subsignal joined #salt
07:34 edrocks joined #salt
07:36 Electron^- joined #salt
07:42 akhter joined #salt
07:51 flowstate joined #salt
07:54 armyriad joined #salt
08:01 spuder joined #salt
08:03 fracklen joined #salt
08:03 fracklen joined #salt
08:04 jas02_ joined #salt
08:04 mikecmpbll joined #salt
08:17 jhauser joined #salt
08:18 barmaley joined #salt
08:18 Electron^- joined #salt
08:24 ronnix joined #salt
08:28 subsignal joined #salt
08:28 cyborg-one joined #salt
08:36 jas02 joined #salt
08:38 s_kunk joined #salt
08:48 DEger joined #salt
08:50 SaltyVagrant joined #salt
08:51 jab416171 joined #salt
08:52 fenlee joined #salt
08:52 Guest1175 joined #salt
08:52 flowstate joined #salt
08:53 N-Mi joined #salt
08:53 N-Mi joined #salt
08:55 fenlee Hi guys, I'm newb in Saltstack, but I have already configured config to work with. Please help me to get how run exact only single one config sls to work.
08:56 jas02 joined #salt
08:57 fenlee when I run salt "*" state.apply it runs all from init.sls
08:57 fenlee but I need to run only exact config
08:59 AndreasLutro look up the documentation for state.apply
08:59 AndreasLutro it tells you how to run a single sls
08:59 fenlee doing ) thanks
09:00 fenlee if you have direct link to it, please drop the line )
09:01 yuhlw_____ left #salt
09:04 AndreasLutro just google "salt state.apply" and you'll find it
09:04 yuhlw____ joined #salt
09:04 nmadhok joined #salt
09:08 nmadhok joined #salt
09:09 babilen fenlee: Generally speaking I would aim to be able to run a highstate at any given time. It might cause you headaches if you have to ensure that only a subset of the highstate is applied.
09:11 keimlink joined #salt
09:16 lunarlamp joined #salt
09:22 sju joined #salt
09:27 samodid joined #salt
09:30 subsignal joined #salt
09:37 jab416171 joined #salt
09:50 flowstate joined #salt
10:01 Hetman Hello can I do something like to that to action something if file does not exist: {% if not file.exists['/etc/subgid'] %}
10:01 Ni3mm4nd joined #salt
10:01 netcho_ joined #salt
10:06 jas02_ joined #salt
10:15 Electron^- joined #salt
10:19 babilen Hetman: It's normally a better idea to describe what you want to achieve rather than reactions to a given situation. If you want that file to exist then just manage it.
10:23 Hetman babilen: I've got 2 problems: 1) I'm ussing file.line to ensure that there is a line in my file but I've got a problem that file does not exist. Looking for a way to check it before processing file.line . Second problem is that file.line does not adding new line after my line ... and I need it so wonder how I can add new line at end of my file
10:23 barmaley joined #salt
10:30 invalidexception joined #salt
10:30 subsignal joined #salt
10:33 AndreasLutro use "unless" in your state to not run if the file doesn't exist
10:33 AndreasLutro or onlyif, rather
10:33 AndreasLutro onlyif: test -f /path/to/file
10:35 Hetman I think I will skip that onlyif and before this will do if closure that will touch file if not exists. What about second issues ? So file.line will add line, I need a newline at end of this file currently cannot add it any idea for that
10:37 edrocks joined #salt
10:41 sevenfourk joined #salt
10:42 mavhq joined #salt
10:44 akhter joined #salt
10:51 flowstate joined #salt
10:53 alexzel Hello, is it possible to use nested salt['grains.filter_by'] for multiple grains?
10:59 netcho_ whats the best way to store AWS keys? profile with access/secret keys? pillar or?
11:03 AndreasLutro what sort of AWS keys?
11:06 dariusjs joined #salt
11:07 jas02 joined #salt
11:11 jas02_ joined #salt
11:14 jas02 joined #salt
11:15 jas02 joined #salt
11:18 cyborg-one joined #salt
11:19 SaltyVagrant_ joined #salt
11:26 west575 joined #salt
11:31 subsignal joined #salt
11:39 DEger joined #salt
11:46 cosming joined #salt
11:48 cosming How can I use salt -C 'G@roles:prometheus-node' cmd.run from a python script?
11:48 cosming local.cmd('*', 'cmd.run', - works
11:49 cosming but local.cmd('G@roles:prometheus-node', 'cmd.run', - selects no minions
11:50 nawwmz joined #salt
11:50 Ni3mm4nd_ joined #salt
11:51 Diplomat Hey everyone! When I'm trying to run a docker image.. do I have to install docker-engine first or salt installs it automatically ?
11:52 DEger joined #salt
11:54 akhter joined #salt
11:56 babilen Diplomat: Salt won't install it automatically and assumes that it will be present on the system -- https://github.com/saltstack-formulas/docker-formula/
11:56 babilen cosming: Ah, do you have states to install the prometheus node exporter?
11:56 cosming yes
11:57 babilen cosming: I guess that you have to pass "expr_form"
11:57 babilen cosming: Would you mind sharing them?
11:58 abednarik joined #salt
11:58 babilen https://docs.saltstack.com/en/latest/ref/clients/#salt.client.LocalClient.cmd details the various matchers you can reference in there
11:58 cosming not at all, but are working only on ubuntu (debian maybe)
11:58 babilen Cool, I'm just curious :)
11:59 impi joined #salt
12:00 cosming https://gist.github.com/CosminG/cb7b08d0233d3c2263c7ae0ea243d766
12:01 cosming You have to download the deb
12:02 babilen aye
12:02 cosming You can get from this repo
12:02 cosming https://www.robustperception.io/machine-monitoring-with-prometheus-debs/
12:03 babilen ta!
12:03 PerilousApricot joined #salt
12:03 DEger joined #salt
12:03 babilen Does defining expr_form solve your issue?
12:04 toanju joined #salt
12:04 barmaley joined #salt
12:07 ws2k3 im trying to setup multiple enviroments the example looks like this : http://pastebin.com/rq6tNx3J is this a good way to go? what the use for makeing seperate directory'f for states and services?
12:12 DEger joined #salt
12:13 amontalban joined #salt
12:13 amontalban joined #salt
12:18 jas02 joined #salt
12:21 cosming babilen I didn't get it working yet
12:22 DEger joined #salt
12:24 babilen cosming: You are using a compound matcher so you'd have to pass expr_form="compound" in your call
12:25 blu_ Hi guys. I've got root@utility:/srv/salt# ls _modules/blunix/trainer.py containing  def change_state(a, b)    however when I use   {% do salt['blunix.trainer.change_state']('foo', 'bar') %}   I get:   Jinja variable 'salt.utils.templates.AliasedLoader object has no attribute 'blunix.trainer.change_state'
12:26 babilen I'd expect that to be trainer.change_state
12:26 blu_ babilen, even with the directory in front of it?
12:26 amcorreia joined #salt
12:26 blu_ babilen, tested it, same result
12:27 blu_ when I say saltutil.sync_all, it actually shows modules: - modules.blunix.trainer
12:27 blu_ very strange. been there before, could have sworn it works this way..
12:28 abednarik joined #salt
12:30 babilen If it is listed that way it should work, yeah
12:30 blu_ babilen, I'll put together a pastebin - if you could very that on your end that would be awesome. Here we run 2016.3.3 on both master and minion
12:32 subsignal joined #salt
12:32 blu_ babilen, http://paste.debian.net/890367/
12:33 cosming babilen: Thank you. This is working: hosts = local.cmd('G@roles:prometheus-node', 'cmd.run', ["ip route get 8.8.8.8 | awk '{print $NF}'"], expr_form='compound')
12:33 babilen Yes, that is the command I suggested :)
12:33 guerby joined #salt
12:36 DEger joined #salt
12:37 jas02 joined #salt
12:37 APLU joined #salt
12:38 jas02 joined #salt
12:42 blu_ babilen, I'm getting some strange results even when not using a subdirectory now: http://paste.debian.net/890371/
12:42 blu_ seems it doesnt even want to work with the example in http://pyholodeck.readthedocs.io/en/latest/first_module.html (or I'm just overlooking something..)
12:45 babilen Did you reload the minion?
12:46 DEger joined #salt
12:46 blu_ babilen, yes - I reloaded both master and minion and deleted /var/chache/salt/* before so I can see output in sync_all
12:47 blu_ babilen, http://paste.debian.net/890373/ very strange
12:47 blu_ that really shoudl work - looks like _modules are not working at all on that master
12:48 blu_ there are no modifications to /etc/salt/{master,minion} - in /etc/salt/minion.d/blunix.conf we have master_retries: -1 as we are on vagrant but besides that everything is default
12:49 jas02 joined #salt
12:53 flowstate joined #salt
12:58 CampusD joined #salt
13:02 DEger joined #salt
13:03 dariusjs joined #salt
13:09 jas02 joined #salt
13:12 DEger joined #salt
13:12 jas02_ joined #salt
13:14 gheistbane joined #salt
13:18 blu_ Did get it to work with /srv/salt/_modules/foo.py in the end, but not with /srv/salt/_modules/blunix/foo.py.. I could have sworn this was working at some point
13:18 blu_ could it have been removed?
13:18 racooper joined #salt
13:18 blu_ I mean it even lists the modules when I sync_all
13:22 PerilousApricot joined #salt
13:22 DEger joined #salt
13:25 AirOnSkin joined #salt
13:25 edrocks joined #salt
13:28 blu_ I created an issue for it: https://github.com/saltstack/salt/issues/37273
13:28 saltstackbot [#37273][OPEN] Execution Modules in subdirectory "is not available" | Description of Issue/Question...
13:31 dariusjs joined #salt
13:32 Tanta joined #salt
13:33 subsignal joined #salt
13:34 barmaley joined #salt
13:34 DEger joined #salt
13:36 netcho_ joined #salt
13:38 nicksloan joined #salt
13:41 dps joined #salt
13:41 DEger joined #salt
13:45 numkem joined #salt
13:46 aagbds joined #salt
13:48 DammitJim joined #salt
13:48 ronnix joined #salt
13:50 du5tball hi, is it possible to have the salt-roster contain wildcards?
13:51 du5tball ie i want salt to run on a /24 subnet via salt-ssh
13:53 babilen du5tball: Is the it not working for you?
13:53 du5tball babilen: what do you mean?
13:53 babilen alt-ssh --roster scan 10.0.0.0/8 should do the trick, shouldn't it?
13:54 babilen *salt-ssh
13:54 babilen Which roster did you try?
13:54 du5tball babilen: ah, that seems to work. thanks :)
13:55 babilen Great
13:55 DEger joined #salt
13:56 edrocks joined #salt
14:05 johnkeates joined #salt
14:09 jas02 joined #salt
14:10 spuder joined #salt
14:15 abednarik joined #salt
14:16 hasues joined #salt
14:16 hasues left #salt
14:24 DEger joined #salt
14:26 abednarik joined #salt
14:26 Auroch joined #salt
14:27 keltim joined #salt
14:27 keltim_ joined #salt
14:30 dj_goku_ joined #salt
14:33 dj_goku_ I am trying to use a grain as part of the salt path like: salt://some/path/{{ grains['id'] }}.txt but it is erroring with none of the specified sources were found. Is this possible?
14:33 subsignal joined #salt
14:34 DEger joined #salt
14:35 dj_goku_ More context I am trying to use file.managed: - source with a salt path that has a grain imbedded.
14:36 babilen dj_goku_: Is it listed by cp.list_master ?
14:38 Auroch Hello, could someone tell me if it's a good form for a pillar ?
14:38 Auroch servers:
14:38 Auroch MachineZero:
14:38 Auroch - ref: ma198412
14:38 Auroch - ip: 151.54.8.2
14:38 dj_goku_ babilen: I get VALUE_TRIMMED for the minion
14:38 Auroch MachineOne:
14:38 Auroch - ref: ma200325
14:38 Auroch - ip: 14.22.158.237
14:38 Auroch - hosts:
14:38 Auroch - first.mydomaine.eu
14:38 Auroch - second.mydomaine.eu
14:38 Auroch - third.mydomaine.eu
14:38 babilen Auroch: Please use one of http://paste.debian.net, https://gist.github.com, http://sprunge.us, …
14:38 Auroch oups sorry
14:38 babilen And why would you make that a list?
14:39 fracklen joined #salt
14:39 babilen I'd use something different
14:39 flowstate joined #salt
14:40 CampusD joined #salt
14:40 babilen Will the ref change ?
14:40 babilen Auroch: If you could paste it I would have it easier to construct a different example
14:41 Auroch Could someone tell me if it's a good form for a pillar ?
14:41 Auroch And then explain me how I walk throught the keys ?
14:41 Auroch https://zerobin.net/?12fc5f539a45181f#6I7UO9K5xY9Rltd5b2z3GhDV2LOmGNkaylfim7Z9UJA=
14:42 babilen What's "MachineOne" in here?
14:42 tiwula joined #salt
14:43 dj_goku_ babilen: I turned up logging for salt command, but it isn't helping me debug.
14:43 Auroch babilen: It's the salt ID of a server
14:44 flowstate joined #salt
14:44 mpanetta joined #salt
14:44 babilen Auroch: I'd use something like http://paste.debian.net/890401/ that way you can iterate over 'servers:' ~ {{ grain['id'] }} ~ ':hosts' right away
14:44 DEger joined #salt
14:45 dps joined #salt
14:45 babilen And why do you target a pillar that contains data for MachineZero to MachineOne and vice versa?
14:46 babilen It might be better to target something like http://paste.debian.net/890402/ to MachineOne
14:46 babilen (i'd also use a better top-level key than "servers")
14:46 Auroch I want to store data for all machine in one sls file, but it's probably better to storein servers/MachineOne.sls servers/MachineZero.sls ?
14:46 dj_goku_ babilen: here is what I am trying to do: http://paste.debian.net/890403/
14:47 babilen You can store them however you like, but the minion should only see data meant for it
14:47 MajObviousman sanity check requested: what permissions should be on a file in /etc/sudoers.d ?
14:47 dj_goku_ 600?
14:47 babilen Auroch: Pillars are/can also be merged
14:47 MajObviousman /etc/sudoers itself is 440, but that's because it's being managed by visudo
14:47 MajObviousman yeah 600 sounds sane. I could also do 400
14:47 babilen dj_goku_: So, is it listed by cp.list_master ?
14:47 dj_goku_ babilen: no
14:47 MajObviousman dj_goku_: thanks
14:48 flowstate joined #salt
14:48 babilen dj_goku_: Are you sure that your file_roots entry is correct?
14:48 tercenya joined #salt
14:48 dj_goku_ babilen: we are using gitfs if that matters.
14:48 Auroch babilen: Merge ? so even servers/MachineZero servers/MachineOne will be merged ?
14:49 babilen dj_goku_: It might, so you have a repository with some/path/to/salt/ directory in there?
14:49 babilen dj_goku_: Try running "salt-run fileserver.update" and see if the file(s) you are after are now listed
14:49 dj_goku_ babilen: yes. I can ls
14:49 mpanetta joined #salt
14:50 dj_goku_ well I can ls the path locally which is what salt would use and it is there.
14:50 babilen locally?
14:50 dj_goku_ also I see the folder with: sudo salt-run fileserver.dir_list backend=git
14:51 lompik joined #salt
14:51 dj_goku_ babilen: yeah I cd into the states/base folder and can ls the folder and file I am expecting
14:51 babilen If it is not listed by cp.list_master you cannot reference it with salt://
14:52 babilen dj_goku_: You mean you have a local clone of the repository in question?
14:52 dj_goku_ babilen: for development yes
14:52 babilen So, how does that prove anything about the files the master sees?
14:53 dj_goku_ because I pushed the files and they show up in the git repo?
14:53 babilen They are obviously not know to it which points to a problem with your GitFS setup .. or you haven't pushed commits .. or haven't updated the fileserver in a while or ...
14:53 dj_goku_ babilen: and I see the folder structure
14:53 babilen In cp.list_master ?
14:54 dj_goku_ babilen: my other files which aren't depended on grains were copied fine.
14:54 dj_goku_ copied from gitfs to a minion using similar salt:// paths.
14:56 babilen And just because you might have overlooked it: You *did* run salt-run fileserver.update, didn't you?
14:56 babilen It doesn't matter how you reference them .. if the fileserver doesnt' know about those files they can't be fetched
14:56 babilen And those files were added in the same commit ?
14:56 babilen It would help a lot to have specific information .. also the master debug log output for the "salt-run fileserver.update" run would be of interest
14:56 feld joined #salt
14:56 marcinkuzminski joined #salt
14:56 bocaneri joined #salt
14:57 dj_goku_ babilen: yes there is a cron that runs every minute running that and yes I ran that.
14:57 darvon joined #salt
14:58 babilen Well, the master is obviously not picking up on those files. It's impossible to say more without more and explicit/specific information
14:58 dj_goku_ babilen: yes the files were added in the same commit.
15:00 babilen Unfortunately I have to leave now, but I'd look into the debug output and also disclose some (pseudo-anonymised) examples of the actual filenames and configuration
15:00 babilen Good luck!
15:00 dj_goku_ babilen: ahh I ran salt-call cp.list_master but it isn't showing gitfs files.
15:01 dj_goku_ thanks for trying to help
15:01 beowuff joined #salt
15:03 dj_goku_ babilen: ahh I see the files with: sudo salt-run fileserver.file_list backend=gi
15:10 kbaikov joined #salt
15:15 subsignal joined #salt
15:16 nZac joined #salt
15:20 keltim_ joined #salt
15:20 keltim joined #salt
15:21 Ni3mm4nd joined #salt
15:21 rem5 joined #salt
15:22 rherna joined #salt
15:23 Trauma joined #salt
15:25 subsignal joined #salt
15:27 samodid joined #salt
15:30 abednarik joined #salt
15:33 ronnix_ joined #salt
15:33 rem5_ joined #salt
15:34 jas02 joined #salt
15:35 flowstate joined #salt
15:36 numkem joined #salt
15:39 rem5 joined #salt
15:39 Ni3mm4nd joined #salt
15:43 ivanjaros joined #salt
15:44 brokensyntax joined #salt
15:44 XenophonF is anyone using salt to manage desktops and laptops?
15:45 MajObviousman can I have both an onlyif and an unless in the same state?
15:45 XenophonF i'm curious about user experience especially surrounding devices on poor internet links
15:46 djgerm joined #salt
15:49 beowuff joined #salt
15:49 Ni3mm4nd joined #salt
15:49 brokensyntax XenophonF: How long have you been experimenting with salt?
15:50 XenophonF a couple of years
15:53 brokensyntax Thoughts? I heard about it first this summer at HOPE. Haven't done a test deployment yet.
15:57 XenophonF I started using it after having some direct experience with System Center and indirect experience with things like BigFix or Tivoli.
15:58 XenophonF I was looking for something I could use on both Windows and UNIX.
15:58 juarez joined #salt
15:59 juarez left #salt
15:59 XenophonF I picked Salt after reviewing a couple of different FLOSS config management tools.
16:01 XenophonF I forget all the ones I reviewed, but it included Puppet and one who's name started with "r"...red-something maybe?
16:02 XenophonF I came for the Python and pure open-source software release---I personally feel like open-core is a bit of a bait-and-switch, having been burned by Zenoss and Teambox.
16:02 XenophonF I stayed initially for the community here, which is awesome, and the YAML and Jinja syntax, which made a lot of sense to me.
16:03 XenophonF But what's really gotten me excited over the last 6-12 months are features like orchestration, its event bus, and reactors.
16:04 XenophonF At work we do a lot of stuff surrounding federated identity and virtual organizations.
16:04 XenophonF So we are running a collaboration management platform called COmanage, which lets us set up a VO and then invite people.
16:05 XenophonF COmanage can do things like provision users in LDAP directories and the like, kind of like a metadirectory, but we're looking to extend it such that when new collaborations get created, COmanage drops an event on the Salt event bus that triggers the creation or allocation of a variety of services/resources.
16:06 flowstate joined #salt
16:06 XenophonF e.g., if you create a new scientific collaboration, COmanage tells Salt, which then creates new SharePoint site collections (doc collab), or sets up new REDCap projects (data collection), and so on.
16:07 Ni3mm4nd joined #salt
16:07 XenophonF the downside is that getting my colleagues to use it has been... difficult
16:08 XenophonF I only get occasional support from management---they want stuff in Salt and are impressed with the things I can do with it, but they aren't willing to take the time necessary to create states or reactors or whatever.
16:09 XenophonF It's a big problem our team has in general, taking the time to create properly documented service packages (in the ITIL sense).
16:09 XenophonF ...whether we automate the a service package o rnot
16:09 barmaley joined #salt
16:10 XenophonF brokensyntax: does that answer your question?
16:10 subsigna_ joined #salt
16:10 XenophonF I'm slowly salting my home network, so I've posted my state tree plus an example pillar to GitHub.
16:11 XenophonF https://github.com/irtnog/salt-states and https://github.com/irtnog/salt-pillar-example
16:11 XenophonF I have 100% coverage for my FreeBSD and Linux systems.
16:12 XenophonF I'd say that I probably have 10% coverage for my Windows systems.
16:12 XenophonF which is complicated by the fact that SaltStack seems to ignore Windows in favor of Windows Server
16:13 XenophonF (e.g., instead of using dism.exe for servicing, which would work across both Windows and Windows Server, it uses ServerManager)
16:14 zer0def joined #salt
16:17 tercenya joined #salt
16:18 brokensyntax XenophonF: Yep :D Thanks :P
16:18 cosming joined #salt
16:19 Lionel_Debroux joined #salt
16:19 XenophonF definitely start small
16:19 brokensyntax That is annoying.
16:20 brokensyntax the dism thing.
16:20 XenophonF it is
16:20 brokensyntax Which of course, that's being deprecated by Powershell...
16:20 XenophonF except that ServerManager (and related PowerShell cmdlets) aren't available on Windows, only Windows Server
16:20 XenophonF dism is actually still available across the board
16:21 XenophonF even in 2016 iirc
16:21 brokensyntax Yep, still there, just says 'this will be deprecated, use powershell cmdlet xyz'
16:21 brokensyntax Frankly, whatever works :D I still have some old dsadd/dsquery based scripts from 2003~2007 that work fine.
16:22 brokensyntax But I want to update my FOSS as most M$ businesses work under a philosophy I find difficult.
16:25 Ni3mm4nd joined #salt
16:29 edrocks joined #salt
16:29 netcho_ joined #salt
16:30 onlyanegg joined #salt
16:31 rovar joined #salt
16:32 rovar hey all.. I am looking for some help in troubleshooting extension modules.  I just upgraded to 2016-3 and my states can no longer find some of my functions.
16:32 rovar I have updated /etc/salt/master to include module_dirs:  as per https://docs.saltstack.com/en/latest/ref/configuration/master.html EXTENSION_MODULES
16:33 rovar but it still doesn't find my functions that used to be available from my states
16:33 rovar is there an easy way to validate that the functionality is found/usable?
16:34 PerilousApricot joined #salt
16:34 rovar do they need to be configured/present on the minion in order to work?
16:36 whytewolf rovar: have you tried syncing your modules with salt '*' saltutil.sync_all
16:36 whytewolf and yes modules need to be on the minions
16:36 darvon joined #salt
16:36 tercenya joined #salt
16:37 pipps joined #salt
16:38 rovar whytewolf, I'll give it a try
16:38 jas02 joined #salt
16:38 sjorge joined #salt
16:38 sjorge joined #salt
16:40 rovar whytewolf, it looks like that was the ticket. thanks!
16:41 rem5_ joined #salt
16:42 BattleChicken joined #salt
16:43 Ni3mm4nd joined #salt
16:46 keltim_ has anyone figured out how to get their editor to autocomplete pillars?
16:48 whytewolf i never tried to.
16:49 whytewolf although with vim i guess it wouldn't be that hard. just some ctags and an autocomplete module
16:50 azerioglan joined #salt
16:51 azerioglan Is anybody faced issued during using wmware?
16:53 XenophonF brokensyntax: i wrote my own interface to dism. it wasn't difficult. https://github.com/irtnog/active-directory-formula/blob/master/_modules/windows_servicing.py and https://github.com/irtnog/active-directory-formula/blob/master/_states/windows_feature.py
16:53 XenophonF my goal is to eventually support servicing WIM images
16:53 abednarik joined #salt
16:54 brokensyntax Decent goal.
16:54 XenophonF azerioglan: that's too vague - just post your question. we'll answer it if we have a clue.
16:56 azerioglan XenophonF: sorry i posted my question here https://github.com/saltstack/salt/issues/37274
16:56 saltstackbot [#37274][OPEN] Salt got the AttributeError: 'NoneType' object has no attribute 'key' during VM creation | Hi guys,...
16:59 pipps joined #salt
16:59 armyriad joined #salt
16:59 tercenya joined #salt
16:59 netcho_ joined #salt
16:59 KajiMaster joined #salt
17:03 dj_goku_ babilen: so I found out the issue. I set the grain from the master, it was somehow a list for the value, so I switched to grains['key'][0] and it fixed the issue, but in the end I just switch to using the grains['id'] vs a customer grain.
17:05 pipps joined #salt
17:07 Edgan joined #salt
17:11 tercenya joined #salt
17:11 Ni3mm4nd joined #salt
17:16 f4 joined #salt
17:16 f4 joined #salt
17:17 chamunks joined #salt
17:17 f4 joined #salt
17:17 f4 joined #salt
17:17 KevinAn27 joined #salt
17:17 f4 joined #salt
17:18 f4 joined #salt
17:28 sjorge joined #salt
17:28 sjorge joined #salt
17:29 feld joined #salt
17:29 Ni3mm4nd joined #salt
17:30 esckroh joined #salt
17:31 abednarik joined #salt
17:37 keltim joined #salt
17:37 keltim_ joined #salt
17:38 Ni3mm4nd joined #salt
17:39 mikecmpbll joined #salt
17:41 nZac joined #salt
17:44 Electron^- joined #salt
17:46 fracklen joined #salt
17:46 Trauma joined #salt
17:49 GreatSnoopy joined #salt
17:53 beowuff joined #salt
17:55 s_kunk joined #salt
17:56 mibr0 joined #salt
17:56 armyriad joined #salt
18:02 FroMaster joined #salt
18:03 spuder_ joined #salt
18:07 psrjr joined #salt
18:17 KingOfFools joined #salt
18:17 spuder joined #salt
18:18 KingOfFools Guys, can someone explain what option 'splay' in schedule module really does? And should I even use it?
18:21 netcho_ joined #salt
18:22 chamunks joined #salt
18:24 tercenya joined #salt
18:28 toanju joined #salt
18:31 bltmiller joined #salt
18:33 win_salt splay makes a timeframe for the jobs to run, and I would say it is a good idea.  Makes it easier for the master to process lots of minion jobs
18:34 zer0def joined #salt
18:34 flowstate joined #salt
18:35 rem5 joined #salt
18:39 jas02 joined #salt
18:39 sp0097 joined #salt
18:44 numkem joined #salt
18:44 mpanetta joined #salt
18:49 iggy google thundering herd
18:49 N-Mi joined #salt
18:52 XenophonF joined #salt
18:53 alexanderilyin joined #salt
18:56 PerilousApricot joined #salt
19:00 Edgan Does the schedule not have a batch mode?
19:00 Edgan batch is way better than splay
19:02 aagbds_ joined #salt
19:06 KingOfFools Ah, so if I create 2 jobs, both minutes: 15, first one with splay: 10 and second with splay: 20, first job would run, for example, in 15:15:10, 15:30:10, 15:45:10, second 15:15:20, 15:30:20, 15:45:20, right?
19:06 PerilousApricot joined #salt
19:08 PerilousApricot joined #salt
19:10 whitenoise joined #salt
19:15 flowstate joined #salt
19:19 aagbds joined #salt
19:23 aagbds joined #salt
19:25 pipps joined #salt
19:26 impi joined #salt
19:28 flowstate joined #salt
19:32 anotherZero joined #salt
19:40 kuromagi^ joined #salt
19:41 jas02 joined #salt
19:41 jas02_ joined #salt
19:43 samodid joined #salt
19:44 tapoxi hi all, running into issues with salt-cloud
19:44 tapoxi aws spits out "Network interfaces and an instance-level security groups may not be specified on the same request"
19:44 tapoxi following this: https://docs.saltstack.com/en/latest/topics/cloud/aws.html#specifying-interface-properties
19:45 aagbds joined #salt
19:47 bltmiller joined #salt
19:50 chmod666org joined #salt
19:53 netcho_ joined #salt
19:55 pipps joined #salt
20:14 iggy Edgan: the master doesn't run the schedules, the individual minions do... so there's technically nothing to batch
20:19 KingOfFools iggy: is my example right?
20:19 KingOfFools iggy: i'm not sure if i'm understanding correctly
20:21 pipps joined #salt
20:22 iggy I think splay is in minutes
20:22 iggy oh, I don't ahve enough caffeiene to parse that
20:23 iggy or type
20:28 KingOfFools iggy: documentation says it's in secods
20:28 KingOfFools *seconds
20:29 iggy just create them all with the same splay... you're way over-complicating things
20:29 KingOfFools iggy: but did i understand it correctly, that splay shifts execution time further for specified splay value?
20:30 KingOfFools just want to make sure :P
20:31 jas02 joined #salt
20:32 DEger joined #salt
20:34 pipps joined #salt
20:37 whytewolf splay isn't that it will run splay secondss after the min. it is rand(splay) after time
20:39 jwang joined #salt
20:39 KingOfFools whytewolf: hm.. ok, thanks
20:40 jwang Hey there. I want a state run on one minion to trigger a highstate on another minion. How would I do this?
20:40 amontalban joined #salt
20:40 amontalban joined #salt
20:41 whytewolf jwang: reactor, and event.send
20:41 whytewolf https://docs.saltstack.com/en/latest/ref/states/all/salt.states.event.html#salt.states.event.send
20:41 whytewolf https://docs.saltstack.com/en/latest/topics/reactor/
20:42 jas02_ joined #salt
20:43 pipps joined #salt
20:43 jwang whytewolf: perfect, thanks. And secondly, is there anything very similar puppet's exported resources, or do I have to build up something like that via jinja + mine?
20:43 whytewolf since i have no idea what "exported resources" are i can't answer that
20:44 whytewolf [I touched puppet once and quickly washed my hgands after words]
20:45 jwang fair enough. thanks again :)
20:45 pipps joined #salt
20:45 zulutango joined #salt
20:45 whytewolf humm reading quickly looks like _grains would be the closest thing
20:45 pipps99 joined #salt
20:45 whytewolf kind of like facts that are read from a system?
20:47 jwang similar -- it would be like defining a state that doesn't run on the current machine, but is stored centrally and can be slurped up by another machine
20:48 whytewolf ahh, no real thing like that. although data can be sent between machines using mine
20:48 jwang yeah - I think that's the way I'll go.
20:49 jas02_ joined #salt
20:52 flowstate joined #salt
20:52 flowstate joined #salt
20:55 pipps joined #salt
21:02 jas02 joined #salt
21:05 iggy keep in mind that mine doesn't query data at the time you request it... it is a mechanism for minions to send data to the master that it can then hand out to other minions
21:05 iggy i.e. if you run a state on one machine that changes something, that won't necessarily be exposed to the mine when your other host runs a highstate right after
21:06 iggy if you want to query the current state of one system from another, you need to look into publish
21:13 Sketch if i include an sls with variables set in it, will the variables also make it into the included file?
21:14 jwang iggy: looking into publish. is this the right doc? https://docs.saltstack.com/en/carbon/ref/modules/all/salt.modules.publish.html
21:15 numkem joined #salt
21:19 FreeSpencer joined #salt
21:19 FreeSpencer joined #salt
21:19 jas02 joined #salt
21:20 coldbrewedbrew joined #salt
21:20 coldbrewedbrew joined #salt
21:20 Sammichmaker joined #salt
21:20 coldbrewedbrew_ joined #salt
21:23 iggy jwang: probably... not sure if there's any sort of getting started type guide for it
21:23 Sketch hmm, looks like no
21:23 whytewolf Sketch: if you mean jinja variables, no. you ALSO need to import the file
21:23 whytewolf oh, never mind... just a little to late on the draw there
21:24 Sketch whytewolf: yeah, i mean including jinja variabls in one file, and importing it into more than one state
21:26 whytewolf Sketch: http://jinja.pocoo.org/docs/dev/templates/#import
21:26 whytewolf keep in mind. the jinja is rendered before the other include
21:27 flowstate joined #salt
21:28 mpanetta joined #salt
21:31 ZachLanich joined #salt
21:31 dps joined #salt
21:34 abednarik joined #salt
21:45 Edgan iggy: lame
21:46 Edgan iggy: I will take batch mode over the schedule then
21:46 mikea joined #salt
21:51 cyborg-one joined #salt
21:54 jeddi joined #salt
22:01 Electron^- joined #salt
22:03 jas02 joined #salt
22:08 akhter joined #salt
22:09 joe__ joined #salt
22:09 UtahDave joined #salt
22:15 yuhlw____ joined #salt
22:18 jeddi joined #salt
22:32 spuder joined #salt
22:33 jas02 joined #salt
22:34 systo joined #salt
22:34 GreatSnoopy joined #salt
22:35 regretio_ with state file.managed, if the source is not salt:// and source_hash is specified from what i can tell it doesn't verify it already has a file matching the source_hash before attempting to cache the remote file
22:35 regretio_ is that correct?
22:36 regretio_ so if i had a very large archive, it would attempt to cache it every time before actually checking to see if the file needs to be udpated?
22:37 adelcast joined #salt
22:44 DEger joined #salt
22:46 amontalban joined #salt
22:46 amontalban joined #salt
22:46 UtahDave regretio_: unfortunately, at the moment salt will cache the remote file, then compare.  I think if you specifiy the source_hash as a remote file, then it might just download the source_hash file and skip the large file
22:47 gtmanfred it should, as long as it all matches
22:49 pidydx joined #salt
22:50 pidydx Hi.  I am having trouble understanding the environments.  If I have a prod and dev environment can I declare things in base: that should be shared between them?
22:50 pidydx For example, I want the same states applied to both, but the pillars should combine some baseline config + environmental config
22:50 gtmanfred you can do that yes
22:51 gtmanfred so in top.sls, you just specify all of the different environments, and if it matches anything in any environment, it will run that state
22:51 gtmanfred but each environment could have different state files
22:52 gtmanfred you can also specify in base: in top.sls to use a state from dev to apply it to matches there, so that you can use environments from git
22:52 pidydx so my minion config says dev
22:52 gtmanfred minion config doesn't matter
22:52 pidydx I have top.sls in pillars that specifies matches for base, dev, and prod
22:52 gtmanfred it is the env that the minion matches in top.sls
22:52 gtmanfred so if you have
22:52 gtmanfred base:
22:52 gtmanfred '*':
22:52 gtmanfred - vim
22:52 gtmanfred prod:
22:52 gtmanfred 'salt*':
22:52 gtmanfred - httpd
22:52 pidydx I have top sls in states root that specifies things for base only.  When I try to use highstate the minion says it can't find matches
22:53 gtmanfred salt* will run the httpd state and the vim state
22:53 gtmanfred but everything else will only run the vim state
22:53 gtmanfred and it will run them from the respective environments configured in the master config
22:53 pipps joined #salt
22:53 pidydx oh crap
22:54 gtmanfred actually
22:54 gtmanfred nevermind, it can set environment: dev in the minion config
22:54 pidydx so it has to use the minion_id to determine if it should be dev/prod/whatever?
22:54 gtmanfred so i think that would make it so that minion would only ever use the specified environment
22:54 gtmanfred hrm... i don't actually know
22:54 nZac_ joined #salt
22:54 ZachLanich joined #salt
22:54 gtmanfred if you read this, https://docs.saltstack.com/en/latest/ref/configuration/minion.html#environment it says the recommended way is to isolate it in the top file
22:54 pidydx I expected setting the environment in the minion config to  cause it to check base: and dev: for matches and ignore prod:
22:55 gtmanfred but you can isolate it and say only run this environment on the minion
22:55 gtmanfred so yeah, you can't use base if you specify dev on the minion config
22:55 gtmanfred nope, only checks dev, ignores all others
22:55 gtmanfred if you want it to do both, you need to isolate it using the top file
23:01 pidydx Why bother with dev: prod: at all if the only thing that matters is minion_id matching?
23:02 gtmanfred i use it so that i can manage my dev and preprod environment seperately in gitfs
23:02 gtmanfred then i make all my changes in dev
23:02 gtmanfred test my deploy, merge it to preprod
23:02 pidydx wouldn't putting everything in base: be the same if it is only going to use the minion_id matching to determine what to apply?
23:02 gtmanfred and then before the release, merge it to prod
23:02 gtmanfred no, because maybe you have slightly different setups, or slightly different state files that you are making changes to in dev
23:04 gtmanfred also, having different git repositories for different environments could be usefull if you have 10 different people managing their apps state files in different repositories
23:04 edrocks joined #salt
23:04 jas02 joined #salt
23:04 pipps joined #salt
23:06 pidydx I was trying to break up pillars into dev/prod settings with a common base setting
23:06 pipps99 joined #salt
23:06 BattleChicken left #salt
23:07 pidydx so that a box in environment X would get its settings + base settings
23:07 pidydx but it sounds like the only way to do that is via minion_id matching alone
23:07 gtmanfred you can do that
23:07 gtmanfred just make sure you don't hard set the environment in the minion config, and isolate it in the top file
23:07 gtmanfred in yuor pillars topfile
23:08 mohae joined #salt
23:08 pidydx As far as I can tell doing that erases any meaningful distinction between dev/prod
23:08 pidydx if a minion id matches in any place it will get everything
23:09 gtmanfred base is just another environment like dev or prod, it isn't special and applied to everything always
23:11 hemebond Depending on the top.sls
23:11 gtmanfred sure
23:11 gtmanfred but it doesn't magically overwrite isolating the environment in the minion config
23:12 pidydx what I am getting at is I can't have webserver*: in prod and in dev and have it only get base+dev or base+prod
23:13 hemebond Correct.
23:13 gtmanfred you cannot, you have to have some other defining characteristic to isolate it
23:13 pidydx So what is the benefit of environments?
23:13 aagbds joined #salt
23:14 hemebond Managing multiple environments with one master. Allowing overlap. Could use environments for various "scales" and overrides.
23:14 gtmanfred see all the things i said above
23:15 pidydx Why wouldn't you just do all of that in base: with the minion_id matching?
23:15 pidydx What I am getting at is that environments in Salt don't provide the same kind of isolation as they would in something like Chef
23:15 gtmanfred salt is not chef
23:15 pidydx It appears that the prod/dev distinction has to be managed via minion_id
23:15 hemebond What kind of isolation does Chef provide?
23:15 gtmanfred it can do what you want, you just have to specify it more specifically in the top file
23:15 gtmanfred there is no default always applied environment in salt
23:16 gtmanfred or add that functionality to salt and make a pull request
23:16 pidydx gtmanfred: Right, but I am not clear what the point of using anything other than base: is if you have to manage the prod/dev distinction via the matching in top.sls
23:17 gtmanfred there is not a difference it that is all you want to do
23:17 hemebond Differences in the environments. Differences in the pillar data.
23:17 gtmanfred but there are a ton of different use cases for environments than the one you mentioned
23:17 gtmanfred just because it doesn't fit your usecase doesn't mean it is useless
23:17 hemebond Namespacing states.
23:18 pidydx I'm not saying it is useless.  I'm just saying the way that the documentation describes it seems to imply it is meant to fit the use case I am trying to do, but that it clearly doesn't, and I am trying to understand what other use cases it is supposed to meet
23:18 moloney joined #salt
23:18 pidydx that aren't otherwise already met by just putting everything in base: with a ton of matching rules
23:19 hemebond So you want to apply states from base+dev or base+prod?
23:19 pidydx the states are all the same
23:19 pidydx it is the pillar data that I am trying to deal with
23:19 gtmanfred i would name my servers webserver.dev* and webserver.prod* and then have base just have the webserver* match, and then it would work for you
23:20 numkem joined #salt
23:22 pidydx gtmanfred: That is what I am doing now.  It just means I have to replan naming conventions around Salt.  Not a big deal, but kinda weird to have to do that
23:22 gtmanfred it would be insecure, but you could match on grains
23:22 hemebond I still don't know what the problem is.
23:22 pidydx it also means that "prod environment" or "dev environment" don't really mean environment as salt calls it
23:23 gtmanfred i think your interpretation of the meaning is off, environment is just supposed to be a seperate location to look for for files and configurations and states and pillars etc
23:23 gtmanfred the base level environment is jsut
23:23 gtmanfred file_roots:
23:23 gtmanfred base:
23:23 gtmanfred - /srv/salt/base
23:23 gtmanfred prod:
23:23 gtmanfred - /srv/salt/prod
23:23 gtmanfred be it states or pillars, i think pillars uses pillar_roots
23:23 gtmanfred and it is just a different repository of files to use
23:24 gtmanfred then you say, hey you guys, you only manage files here, and you guys only manage files here, and you let users manage their pillars and states seperate from each other
23:25 gtmanfred you can use it as a logical seperation of states per app, or also then your seperation of environments as like dev, preprod, prod, but you can definitely use it to merge stuff forward and maintain different branches of states and pillars so that data can be updated in each environment
23:26 gtmanfred i used it to manage my preprod and dev and prod environments everything completely seperately so that I could make changes to dev first, and then merge them into my other sets of states as the releases that they needed to be applied for came out
23:26 gtmanfred current prod release doesn't require mongo, but the stuff in dev does.. great, put the mongo state in dev, work on it, let the app release with mongo in dev, it moves forward to preprod for testing with qa right before the release, merge my states from dev to preprod
23:27 gtmanfred then the night before the release, once preprod is stable, merge it all into prod and then push out the release in the morning
23:28 gtmanfred same goes for pillars and states* all in gitfs
23:31 aagbds joined #salt
23:34 pidydx It might be fine.  It just requires a significant overhaul to make things play right with shared configs
23:38 pidydx can salt-call be used to display what matches were found?
23:38 hemebond You can check from the master.
23:38 hemebond state.show_top I think
23:38 gtmanfred you should be able to do it from the minon too
23:38 hemebond What is your current setup and why do you have to redo it all?
23:40 pidydx We just did all our pillars with the idea that base: was like default
23:40 pidydx so we could put shared config there
23:40 hemebond Can you not do that?
23:41 pidydx Not with environments
23:41 hemebond Really? I use base as a fallback for my environments.
23:41 pidydx Maybe then?
23:41 hemebond What do your pillar_roots look like?
23:42 pidydx can you show the matching on pillars?
23:44 hemebond Not sure you can. Or at least, I don't think there's a way to see which environment it came from.
23:44 hemebond Since they can be merged.
23:45 pidydx I just want to test the matching because right now it isn't matching right at all
23:45 hemebond Well pillar.list will show the pillars without values. But I don't think there's something like show_top
23:46 hemebond Oh wait.
23:46 pidydx If you are using different file_roots wouldn't each environment have its own top.sls?
23:46 hemebond Yes
23:47 hemebond salt-run pillar.show_top myminion
23:47 pidydx ok...so we are back to why would you specify dev: and prod: etc in one top.sls if each environment root would have its own top.sls?
23:47 hemebond Wait, that doesn't seem to work properly for me.
23:49 pidydx Welp, thanks for the help.  I am going to try and figure this out tomorrow.
23:49 justan0theruser joined #salt
23:51 edrocks joined #salt
23:53 pipps joined #salt

| Channels | #salt index | Today | | Search | Google Search | Plain-Text | summary