Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-08-15

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

All times shown according to UTC.

Time Nick Message
00:02 bezeee joined #salt
00:03 bhosmer joined #salt
00:08 n8n joined #salt
00:14 TaiSHi Hi all, any news about the ubuntu repos for develop? cc: joehh
00:15 taterbase left #salt
00:16 srage joined #salt
00:17 yomilk joined #salt
00:19 conan_the_destro joined #salt
00:20 srage_ joined #salt
00:37 renoirb joined #salt
00:38 ajolo joined #salt
00:40 yomilk joined #salt
00:42 beneggett joined #salt
00:46 JZMatrix joined #salt
00:51 bhosmer joined #salt
00:57 ramishra joined #salt
00:57 beneggett joined #salt
01:04 elfixit joined #salt
01:07 TheThing joined #salt
01:09 capitalfellow joined #salt
01:09 bhosmer joined #salt
01:12 pengyao joined #salt
01:13 TOoSmOotH joined #salt
01:15 napper joined #salt
01:16 melinath joined #salt
01:17 TOoSmOotH So wuick question. Is there a way to manage a file as a template? example: Lets say I have a resolv.conf in centos and I want to template the resolver IPs. so like I want to use something like {{ pillar[‘static’][‘dns1’] }}
01:17 TOoSmOotH that way I can manage the dns servers from a pillar vs modifying the file every time
01:18 bhosmer joined #salt
01:19 SheetiS http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#jinja-in-files
01:19 SheetiS yep!
01:19 DrQuest is pretty damn useful
01:19 TOoSmOotH nice
01:19 TOoSmOotH This is what I was looking for :)
01:20 SheetiS I've also used the python renderer in files when jinja has failed to deliver.
01:22 TOoSmOotH so sticking with my example where my pillar looks like this:
01:22 TOoSmOotH staticinfo:
01:22 TOoSmOotH dns1: 192.168.2.8
01:22 TOoSmOotH dns2: 8.8.8.8
01:22 oz_akan joined #salt
01:23 DrQuest can I use an 'and' in matching minions in a top file?
01:23 TOoSmOotH in the resolv.conf on the master would I do this: {% from ‘static’ import staticinfp with context %}
01:23 DrQuest ( kernel:linux and 'qa-*' )
01:23 TOoSmOotH nameserver {{dns1}}
01:24 n8n joined #salt
01:25 TOoSmOotH my directory structure is pillar/static/ini.sls
01:25 TOoSmOotH init.sls even
01:25 SheetiS TOoSmOotH: you can reference your pillar dictionary directly in the template.  so you can {% salt['pillar.get']('staticinfo:dns1', '<default>') %}
01:25 TOoSmOotH ok
01:25 TOoSmOotH nice
01:25 SheetiS DrQuest: yeah use a compound match
01:26 SheetiS http://docs.saltstack.com/en/latest/topics/targeting/compound.html
01:27 SheetiS TOoSmOotH: you also don't have to reference a default when you pillar.get, but you will get an error if the information isn't in the pillar
01:27 SheetiS and sorry about the poor syntax above
01:27 TOoSmOotH ok
01:27 SheetiS should use {{ instead of {%
01:28 SheetiS unless you wanted to just get staticinfo
01:29 SheetiS you could get that as a variable {% set staticinfo = salt['pillar.get']('staticinfo', '<default>') %} and then reference staticinfo['dns1'] later on.
01:29 TOoSmOotH ok
01:29 TOoSmOotH I am testing the first method now
01:32 melinath joined #salt
01:37 bhosmer_ joined #salt
01:39 TOoSmOotH hrm
01:39 TOoSmOotH I must have missed something because the managed file has the jinja in it
01:39 TOoSmOotH oops forgot the -template declaration
01:40 SheetiS yeah
01:40 SheetiS need that :D
01:40 gzcwnk joined #salt
01:40 TOoSmOotH +search <default>
01:40 TOoSmOotH +nameserver <default>
01:40 TOoSmOotH +nameserver <default>
01:40 gzcwnk any idea what has failed here pls?  http://pastebin.com/HpxYSeLZ
01:40 TOoSmOotH that is what it put in there
01:41 TOoSmOotH maybe I need to reload the pillar data?
01:41 gzcwnk i have restarted teh slt-master but it does this all the time
01:45 thayne joined #salt
01:45 SheetiS TOoSmOotH: is your pillar inside of the /srv/pillar/top.sls?
01:45 SheetiS since you didn't hve defaults, it looks like it was taking that <default> since you put it there literally.
01:45 TOoSmOotH winner winner chicken dinner lol
01:45 TOoSmOotH works
01:45 TOoSmOotH sweet
01:45 TOoSmOotH thanks for the help
01:45 SheetiS gzcwnk: Are you trying to run states named remove-users and rsyslog?
01:45 TOoSmOotH now I can get crazy with this :)
01:45 gzcwnk yes
01:45 gzcwnk they were working
01:45 SheetiS salt '<target>' state.sls <state_name>
01:45 SheetiS you were missing the state.sls
01:46 melinath_ joined #salt
01:46 gzcwnk oops
01:46 SheetiS it doesn't know that 'remove-users' is a state unless you tell it that it is :D
01:47 gzcwnk yeah i made a typo, doh
01:47 gzcwnk thanks
01:48 SheetiS gzcwnk: You're welcome.
01:48 SheetiS TOoSmOotH: have fun and good luck.
01:48 TOoSmOotH Thanks again for your help!
01:56 delinquentme joined #salt
01:57 delinquentme if I want to issue a command to a RANGE of servers ... minion-02  through  minion-04 ... but NOT minion-01 ... how do ?
01:57 delinquentme salt 'minion-*' would get all of them
01:57 ramishra joined #salt
02:02 SheetiS delinquentme: compound match would work.  http://docs.saltstack.com/en/latest/topics/targeting/compound.html.  salt -C 'minion-* and not minion-01' i think would work
02:03 SheetiS add a test=True at the end so you don't apply it on accident if it is wrong.
02:05 bhosmer joined #salt
02:06 delinquentme joined #salt
02:08 yomilk joined #salt
02:14 dude051 joined #salt
02:22 orion_ joined #salt
02:22 otter768 joined #salt
02:28 Luke joined #salt
02:29 CeBe2 joined #salt
02:29 CeBe3 joined #salt
02:38 mgarfias joined #salt
02:39 mgarfias is there a way to get output of a command like 'app_hosts_yml = `salt -E '(app|deploy)\d' grains.get apps --out yaml`' on a non-salt master host?
02:39 ipmb joined #salt
02:39 mgarfias wanting the data to know what hosts to deploy an app to, but don't want to do it from salt-master
02:42 yomilk joined #salt
02:42 DrQuest left #salt
02:44 schimmy joined #salt
02:48 schimmy1 joined #salt
02:51 scoates_ joined #salt
02:53 possibilities joined #salt
03:07 aparsons joined #salt
03:12 snuffeluffegus joined #salt
03:14 ajolo joined #salt
03:14 melinath joined #salt
03:15 zentrung joined #salt
03:26 Ryan_Lane joined #salt
03:27 jalaziz joined #salt
03:27 Outlander_ joined #salt
03:31 andrej joined #salt
03:34 bezeee joined #salt
03:35 possibilities joined #salt
03:37 bhosmer joined #salt
03:39 yomilk joined #salt
03:43 catpigger joined #salt
03:46 schimmy joined #salt
03:50 schimmy1 joined #salt
03:55 thayne joined #salt
03:59 ramishra joined #salt
04:02 pastacino joined #salt
04:05 delinquentme joined #salt
04:10 claytron_ joined #salt
04:14 melinath joined #salt
04:16 pentabular joined #salt
04:19 m1crofarmer_ joined #salt
04:27 delinquentme joined #salt
04:29 kermit joined #salt
04:31 jnials joined #salt
04:36 orion_ joined #salt
04:43 jalbretsen joined #salt
04:46 panchisco joined #salt
04:55 ramishra joined #salt
05:01 panchisco joined #salt
05:04 johngrasty_ Is there a way to make salt run a validation successfully before restarting a service. For example,
05:04 johngrasty_ nginx -t before restarting nginx after modifying the watched nginx.conf file.
05:06 m1crofarmer joined #salt
05:06 napper joined #salt
05:07 yomilk joined #salt
05:08 luminous johngrasty_: you can use require on a service state you've defined, making that state dependent on successfully running/applying another state (such as a cmd.run with nginx -t)
05:09 johngrasty_ Bam. Perfect. Thanks!
05:09 johngrasty_ I'm still learning what I can and cannot do with the requires.
05:09 luminous :)
05:09 luminous you'll love require_in
05:09 luminous it's totally awesome when you need it
05:10 luminous good luck
05:15 cyberjames joined #salt
05:16 panchisco joined #salt
05:24 retr0h left #salt
05:26 bhosmer joined #salt
05:30 ramishra joined #salt
05:31 panchisco joined #salt
05:36 johngrasty_ Thanks.
05:36 cyberjames joined #salt
05:36 johngrasty_ BTW, is require in 2014.1 or coming up in 2014.7
05:39 jhauser joined #salt
05:46 panchisco joined #salt
05:46 ajolo joined #salt
05:50 Sauvin joined #salt
05:51 colttt joined #salt
05:59 orion_ joined #salt
06:01 panchisco joined #salt
06:02 delinquentme joined #salt
06:02 mosen joined #salt
06:12 jnials joined #salt
06:16 panchisco joined #salt
06:18 jnials joined #salt
06:23 Lewoco joined #salt
06:31 panchisco joined #salt
06:33 yomilk joined #salt
06:34 felskrone joined #salt
06:36 ramishra joined #salt
06:37 ramishra joined #salt
06:46 panchisco joined #salt
07:01 yomilk joined #salt
07:01 panchisco joined #salt
07:04 bhosmer joined #salt
07:12 snuffeluffegus joined #salt
07:15 bhosmer joined #salt
07:16 panchisco joined #salt
07:18 ramishra joined #salt
07:22 alanpearce joined #salt
07:25 linjan joined #salt
07:28 ramishra joined #salt
07:31 bvrry joined #salt
07:31 panchisco joined #salt
07:35 ramteid joined #salt
07:40 yomilk joined #salt
07:41 jhauser joined #salt
07:46 panchisco joined #salt
07:48 schimmy joined #salt
07:51 schimmy1 joined #salt
07:57 tyson_ joined #salt
07:58 srage joined #salt
07:58 yomilk joined #salt
08:01 panchisco joined #salt
08:02 srage joined #salt
08:03 alanpearce joined #salt
08:16 panchisco joined #salt
08:17 sectionme joined #salt
08:24 faddat joined #salt
08:27 intellix joined #salt
08:31 panchisco joined #salt
08:39 crashmag joined #salt
08:39 nnion joined #salt
08:46 panchisco joined #salt
08:54 ramishra joined #salt
08:54 ml_1 joined #salt
08:56 TyrfingMjolnir joined #salt
09:00 stbenjam joined #salt
09:01 panchisco joined #salt
09:03 bhosmer joined #salt
09:07 fejese left #salt
09:07 fejese joined #salt
09:16 panchisco joined #salt
09:18 fejese hi
09:18 nnion joined #salt
09:20 fejese is that intentional that if you include 2 pillars, a.sls and b.sls then values get merged (first level anyway) but if you one pillar from the other then values get totally overriden?
09:21 workingcats_ joined #salt
09:23 lietu my centos 6 has python 2.6 installed in system, used by system tools, thus to get 2.7 and 3.3 I need them installed in an alternate location, and I've now got them (each with their own pip) under /opt/rh/python(27|33)/root/usr/bin/(python|pip) and the package that installed them set up scripts /opt/rh/python(27|33)/enable which updates system environment to prioritize that python setup .. now I'm trying to get salt to set up a new virtualenv using ...
09:23 lietu ... one of those python versions with virtualenv.managed, and - python: /opt/rh/.../bin/python, but it causes an error: CommandNotFoundError: Could not find a `pip` binary .. any ideas?
09:24 lietu if I was using pip states manually it seems I could give it bin_env parameter to specify which pip to use, but there is no such option for virtualenv.managed
09:29 ajw0100 joined #salt
09:31 panchisco joined #salt
09:35 giantlock joined #salt
09:36 nnion_ joined #salt
09:40 fejese here's a sketch about the issue: http://pastebin.com/51e62Ufz
09:46 panchisco joined #salt
09:47 ramishra joined #salt
09:54 yomilk joined #salt
09:54 TyrfingMjolnir joined #salt
09:55 peters-tx joined #salt
09:59 babilen Why would I use the salt mine if I can run the corresponding functions directly ?
10:01 panchisco joined #salt
10:07 nnion joined #salt
10:08 vbabiy joined #salt
10:09 stbenjam is there a way to get a client to generate keys and send them to the master, without also listening for other commands? I want to get the keys accepted while in kickstart %post (the autosign entry is orchestrated and persists only for a short period of time), but applying config while in kickstart is not ideal
10:13 peters-tx joined #salt
10:16 panchisco joined #salt
10:18 vbabiy joined #salt
10:20 nnion joined #salt
10:24 jayne joined #salt
10:25 TheThing joined #salt
10:28 babilen When writing a custom grain how can I run pkg.version ?
10:29 matthiaswahl joined #salt
10:29 TyrfingMjolnir joined #salt
10:30 babilen I start to strongly dislike all this monkey patching of __salt__, __grains__ and __pillars__
10:30 babilen It is never clear what is available when and what magic has been performed yet.
10:31 panchisco joined #salt
10:33 TyrfingMjolnir joined #salt
10:46 panchisco joined #salt
10:52 bhosmer joined #salt
10:53 Twiglet_ joined #salt
10:55 ramishra joined #salt
10:56 ramishra joined #salt
10:58 ajprog_laptop joined #salt
10:59 lietu how could I make virtualenv.managed state run in another python environment? I don't want to use the system python, but a more recent version installed in a separate directory .. if I use - python: /path/to/alternate/python I get "Could not find a `pip` binary"
11:00 lietu .. centos 6 comes bundled with 2.6, and apparently upgrading the system python will break system tools, thus python 2.7 & 3.3 packages install under /opt/rh/pythonXX/...
11:00 ajolo_ joined #salt
11:01 panchisco joined #salt
11:01 diegows joined #salt
11:05 yomilk joined #salt
11:14 badon joined #salt
11:16 DanGarthwaite joined #salt
11:16 panchisco joined #salt
11:21 oz_akan joined #salt
11:23 capitalfellow joined #salt
11:31 panchisco joined #salt
11:34 hobakill joined #salt
11:42 homelinen_ joined #salt
11:46 panchisco joined #salt
11:47 homelinen joined #salt
11:49 bhosmer joined #salt
11:52 mechanicalduck joined #salt
12:01 mechanicalduck joined #salt
12:01 panchisco joined #salt
12:05 sectionme joined #salt
12:05 yomilk joined #salt
12:07 capitalfellow joined #salt
12:16 panchisco joined #salt
12:17 hobakill joined #salt
12:24 ggoZ joined #salt
12:29 orion_ joined #salt
12:30 orion_ joined #salt
12:31 panchisco joined #salt
12:36 lietu annoyingly my "virtualenv.managed" -issue seems to be as easy to fix manually as: source /opt/rh/python33/enable; mkvirtualenv --python=$(which python) test .. but running that enable script seems to be a mandatory step .. I could write a bash script that does this, but it seems rather silly
12:36 SheetiS joined #salt
12:38 lietu one would imagine that with centos being a fairly popular distro, and running python >2.6 a fairly common thing, this would be easily possible
12:41 bhosmer_ joined #salt
12:41 Hell_Fire joined #salt
12:41 giantlock joined #salt
12:47 oz_akan joined #salt
12:53 cpowell joined #salt
13:01 bhosmer joined #salt
13:06 dccc joined #salt
13:08 bhosmer joined #salt
13:09 Kelsar_ joined #salt
13:09 toastedpenguin joined #salt
13:10 goki joined #salt
13:11 cyberjames joined #salt
13:12 srage_ joined #salt
13:12 mschiff_ joined #salt
13:12 mschiff_ joined #salt
13:13 Twiglet__ joined #salt
13:14 msciciel_ joined #salt
13:14 ggoZ1 joined #salt
13:17 ntropy_ joined #salt
13:19 MaZ-_ joined #salt
13:22 martoss joined #salt
13:24 jgelens joined #salt
13:25 vejdmn joined #salt
13:25 cb joined #salt
13:29 Jarus joined #salt
13:32 toastedpenguin joined #salt
13:33 mpanetta joined #salt
13:35 GnuLxUsr_ joined #salt
13:37 linjan joined #salt
13:38 zooz joined #salt
13:39 sectionme joined #salt
13:43 mapu joined #salt
13:45 MrTango joined #salt
13:51 yano joined #salt
13:55 thayne joined #salt
13:55 jaimed joined #salt
13:55 dude051 joined #salt
13:55 tk75 joined #salt
13:56 rawkode joined #salt
13:56 dramagods joined #salt
13:57 rojem joined #salt
13:57 rawkode joined #salt
13:57 martoss joined #salt
13:59 kt76 joined #salt
14:00 orion joined #salt
14:02 rawkode Hi all - I have the ec2-reactor accepting keys, but not bootstrapping to the auto-scaled machine. Can somebody point me in the direction I should be reading up on?
14:05 kaptk2 joined #salt
14:05 Ahlee salt MINION state.single mycustomstate.function should work on a minion that's sync'd with saltutil.sync_states, right?
14:06 ipmb joined #salt
14:11 aquinas joined #salt
14:11 intellix joined #salt
14:15 AdamSewell joined #salt
14:17 aquinas joined #salt
14:18 jnials joined #salt
14:21 Twiglet_ joined #salt
14:26 patrek joined #salt
14:30 ajprog_laptop joined #salt
14:32 capitalfellow joined #salt
14:34 Nazzy joined #salt
14:37 abe_music joined #salt
14:40 seanz joined #salt
14:41 seanz Greetings. I was curious if there's anything special I have to do to set grain values on a masterless minion.
14:42 seanz I do salt-call grains.setval mykey myval...
14:43 Ahlee and /etc/salt/grains isn't reflecting?
14:43 seanz Then I get a response back that the grain is now set to that value, but when I check the value a moment later, it's back to the default I had in the minion config.
14:43 seanz Ahlee: I see the value there, but that seems to be overridden by my custom minion configuration.
14:44 Ahlee I've never tried to do aything with masterless, so that's the extent of my insight
14:45 seanz Ahlee: Maybe I just forget the minion configuration and favor setting it on the command line instead.
14:48 seanz Ahlee: Do you know the syntax for setting a grain value that is a list?
14:48 seanz I tried comma-separated, but that did not do what I expected.
14:48 rallytime joined #salt
14:49 beneggett joined #salt
14:49 Ahlee salt minion grains.setval foo [bar,baz]
14:49 seanz Ahlee: Ah, thanks!
14:49 Ahlee no problem
14:49 seanz Ok, one last question:
14:49 seanz What about appending a value to a list.
14:50 Ahlee getval, manipulate, setval
14:50 m1crofarmer joined #salt
14:50 Ahlee to the best of my knoweldge there is no append, only set
14:50 seanz Those must be newer features. I don't see them in the v0.16.4 docs.
14:50 Ahlee ah, i'm on 0.17.5
14:51 seanz Ah yes, I see a lot more functionality there.
14:51 Ahlee and what we do is salt minion getval, mangle it in python, then second call ssetval
14:51 econnell joined #salt
14:55 jalbretsen joined #salt
14:56 patarr "robawt: So I have to apologize that I never answered your "yo!" earlier -- since it was in with the rest of those mentions I misread and thought it was patarr mentioning me.  =)" ooooh I see how it is basepi. If I mentioned your name you wouldn't respond? >:(
14:56 mr_chris joined #salt
14:57 mr_chris Do you have to do your own compound matching in a py rendered state or does salt provide anything to make it easier?
14:58 mr_chris For example, I'm writing a fancy users pillar setup and parsing it with a py rendered state. I'm specifying in the pillar which grains to match on.
15:00 icebourg joined #salt
15:02 basepi patarr: hahaha, I did respond! And again just now! ;)
15:04 patarr :D
15:06 SheetiS mr_chris: if it's a py rendered state and not a py rendered file.managed, what you should be returnins is a python dictionary that could have the [{match: compound},] or equivalent in it depending on your need I would think.  Is it something that you could share an example on as I don't think there is a quick canned answer without better context.
15:06 SheetiS pardon my poor pseudo-dict there as well.  match and compound should have been quoted.
15:07 to_json joined #salt
15:07 mr_chris SheetiS, Sure. Let me set up a paste.
15:07 patrek joined #salt
15:08 ipmb_ joined #salt
15:08 thayne joined #salt
15:09 mr_chris SheetiS, Here's an example of the yaml I am parsing in a py state. http://paste.linux-help.org/view/a3cc6d26
15:10 mr_chris Under grains, my intention is to specify which grains the user will be applied to.
15:10 mr_chris But with how I have it now, that means matching one grain at a time.
15:10 pclermont joined #salt
15:11 mr_chris Right now my matching looks like this http://paste.linux-help.org/view/a474d9c9
15:11 mr_chris But I know it can be better.
15:11 pclermont Hi, before I go with a module.run in a state. is there a state that can use extended attributes for permissions (setfacl)
15:12 mr_chris I'm just trying to figure out if I have to implement my own compound matching or if salt has some type of helper for that for py rendered states.
15:14 mr_chris pclermont, The closest I can find is a module. http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.linux_acl.html
15:14 mr_chris But you're looking for a state.
15:14 SheetiS But you're needing to handle the matching yourself rather than pass it back as part of the state itself?  I guess I'm not understanding the specific end goal.  Even when I use the py renderer, I typically still let salt handle my matching.
15:14 beneggett joined #salt
15:15 pclermont mr_chris: Yeah my ggoogle-fu ended up with the same result
15:15 repl1cant joined #salt
15:15 pass_by_value joined #salt
15:16 mr_chris SheetiS, We have many users. The goal to set up a system where I can see them laid out concisely in a single yaml file managed by a py rendered state. The python is responsible for generating the state objects.
15:16 Gareth morning morning
15:16 kballou joined #salt
15:16 mr_chris That yaml file, of course, being a pillar.
15:19 pass_by_value Morning Gareth!
15:19 SheetiS so the user gets added to a machine if the role grain is matched according to what the pillar says?
15:19 SheetiS Am I understanding correctly?
15:19 patarr mr_chris: there is a salt-users formula available.
15:20 mr_chris SheetiS, Correct.
15:20 mr_chris patarr, I've not worked with formulas. Looking into it now.
15:21 SheetiS https://github.com/saltstack-formulas/users-formula is what patarr is talking about
15:22 SheetiS In any case you don't have to have python do the compound matching.  Just return the match inside your dictionary similar to how you would return it in yaml in a jina-rendered template.
15:22 patarr mr_chris: always check out that github repo before you roll your own and then you can save yourself some time :)
15:23 * patarr reminds himself of how he set up a rabbitmq clustering state before he found out there was one in salt-formulas repo.
15:23 mr_chris patarr, Lesson learned.
15:23 metaphore joined #salt
15:24 mr_chris SheetiS, I don't fully understand what you mean by, "Just return the match inside your dictionary similar to how you would return it in yaml in a jina-rendered template." What would an example of that look like?
15:24 mr_chris SheetiS, patarr Thanks for your time.
15:26 ericof joined #salt
15:28 mr_chris patarr, I see how the users formula works and I'm reading up usage of it. It doesn't make it clear how you specify which servers get which users. Can that only be done in the pillar and state top files?
15:29 mr_chris *reading up on the usage...
15:33 patarr mr_chris: right.
15:33 patarr Well, you can add jinja in the pillar file also.
15:33 patarr Sort of like an if/elif etc on hostname or something.
15:33 mr_chris patarr, Which is what I have now. That's what I'm trying to get away from. We have so many exceptions for who needs what where that it's becoming unreadable.
15:34 patarr I would be interested in hearing a different solution also.
15:35 mr_chris patarr, My goal is to have the users state applied to all servers. The pillar looks like this. http://paste.linux-help.org/view/a3cc6d26
15:36 mr_chris The inital stuff under the user name (fullname, shell, etc) sets the defaults for the users.
15:36 mr_chris Under grains, you specify where you would like to have the user applied. In our setup, roles:default is everything. You can do id or localhost for specific hosts.
15:36 mr_chris You can put overrides to the what the user has under there.
15:37 mr_chris Different passwords, different keys. Anything under the grains would override the defaults from the first section.
15:37 mr_chris So instead of having the pillar read as "if server then these users" it would read "this user has these servers"
15:38 elfixit joined #salt
15:38 mr_chris If I manage to make this work, I really should turn it into a formula now that I know of the existence of them.
15:41 to_json joined #salt
15:41 mr_chris SheetiS, I'm starting to get what you mean. Make the yaml translate into a dictionary of the type of match I am looking for.
15:44 rlarkin joined #salt
15:46 stevednd joined #salt
15:47 to_json joined #salt
15:51 beneggett joined #salt
15:52 rojem joined #salt
15:54 pass_by_value joined #salt
15:56 tligda joined #salt
15:57 napper joined #salt
16:03 n8n joined #salt
16:04 BrendanGilmore joined #salt
16:04 ipmb joined #salt
16:13 wendall911 joined #salt
16:18 rlarkin joined #salt
16:19 dccc joined #salt
16:20 napper joined #salt
16:21 KyleG joined #salt
16:21 KyleG joined #salt
16:22 MatthewsFace joined #salt
16:24 tkharju joined #salt
16:27 Ryan_Lane joined #salt
16:27 bhosmer joined #salt
16:28 TyrfingMjolnir joined #salt
16:29 aparsons joined #salt
16:29 rawkode joined #salt
16:30 jhulten joined #salt
16:34 felskrone joined #salt
16:38 TheThing joined #salt
16:39 forrest joined #salt
16:42 aw110f joined #salt
16:45 UtahDave joined #salt
16:47 robawt patarr: it's all good
16:47 scoates_ joined #salt
16:48 colinjohnson joined #salt
16:51 ajw0100 joined #salt
16:57 aparsons_ joined #salt
16:58 chrisjones joined #salt
17:01 iggy I've got a user/group that won't add to certain machines... I've tried running the server with -l all and salt with -l all and I'm not seeing any reason why it's failing. How can I get more info out of salt to figure out what's going on?
17:01 aparsons joined #salt
17:02 bhosmer joined #salt
17:02 aparsons joined #salt
17:03 iggy and of course... when I try running salt-minion with -l all on one of the failing hosts, it starts working
17:03 aw110f joined #salt
17:06 pass_by_value joined #salt
17:06 schimmy joined #salt
17:07 schimmy1 joined #salt
17:07 bhosmer joined #salt
17:09 cpowell joined #salt
17:15 panchisco joined #salt
17:17 ml_1 joined #salt
17:18 druonysus joined #salt
17:18 druonysus joined #salt
17:22 TOoSmOotH packages:
17:22 TOoSmOotH pkg.latest:
17:22 TOoSmOotH pkg:
17:22 TOoSmOotH - name: numactl
17:22 TOoSmOotH - name: tcpdump
17:22 TOoSmOotH Anyone know why I am getting a list error on that?
17:23 cpowell joined #salt
17:23 TOoSmOotH The state "packages" in sls sensors is not formed as a list
17:23 robawt hey folks. If you have a public and restricted (private) pillar repos, you should only have 1 top.sls to control them, right?
17:24 robawt since pillar is "flattened", two top.sls files could conflict with one another, and it's last-read policy?
17:25 mpanetta TOoSmOotH: Take a look at http://docs.saltstack.com/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html it may help.
17:26 mpanetta I can't put my finger on it, but your yaml looks wrong, I am not sure about the -name: thing  I think you can only use - name once.
17:26 mr_chris In a py rendered state, is there a built in salt method I could pass "G@roles:web and G@datacenter:CA" to that could return whether the minion the state is currently running on matches.
17:27 forrest TOoSmOotH, use pkgs
17:27 mpanetta There ya go :)
17:27 forrest TOoSmOotH, also it should be - pkgs:\n  - name: ....
17:28 forrest so missing a dash, missing an s
17:28 forrest and you don't use - name
17:28 mpanetta It is just pkgs and then a list of names right?
17:28 forrest TOoSmOotH, http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.installed and then ctrl-f '- pkgs'
17:28 forrest mpanetta, right
17:28 mpanetta pkgs:\n - pkg1\n - pkg2 etc
17:29 napper joined #salt
17:30 forrest mpanetta, yep
17:30 TOoSmOotH yea.. looks like it wasn’t digging my spacing
17:30 TOoSmOotH wroking now
17:30 TOoSmOotH thanks all!!
17:30 TOoSmOotH :)
17:33 forrest cool
17:34 rap424 joined #salt
17:35 rojem joined #salt
17:35 srage joined #salt
17:37 dstokes hey guys, what's the state for fetching files over http? can't find one in the state list
17:37 forrest dstokes, you mean with file.managed?
17:37 manfred dstokes: you can use file.managed
17:37 forrest dstokes, yep, just use - source: and then the path, like: - source: https://launchpad.net/tomdroid/beta/0.7.3/+download/tomdroid-src-0.7.3.tar.gz
17:37 dstokes source: http://path/to/file ?
17:38 dstokes nice! thx guys
17:40 catpig joined #salt
17:41 dstokes forrest: will file.managed avoid re-downloading if the file is already there, or do i need an unless statement?
17:41 manfred dstokes: tias?
17:42 manfred dstokes: it should have the file in /var/cache/salt/minion for the first time it is downloaded, and then put in place
17:42 forrest right
17:42 dstokes cool, thx again
17:42 tcotav don't you need source_hash for certain sources?
17:43 manfred you will have to have a source_hash in there, if you change the source_hash, it would download the new version
17:43 aparsons joined #salt
17:43 tcotav yeah -- that's what I was recalling.  that's for http and ftp scenarios right?
17:44 manfred it might be for more, i wouldhave to double check
17:44 tcotav http://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.managed
17:44 tcotav salt will tell you if you need it :)
17:44 smcquay joined #salt
17:44 capitalfellow joined #salt
17:47 tk75 joined #salt
17:51 mr_chris Found it!
17:51 mr_chris __salt__['match.compound']
17:53 chrisjones joined #salt
17:53 mr_chris So in my previous example, in a py rendered I could do __salt__['match.compound']("G@roles:web and G@datacenter:CA") and it would if the current minion matches.
17:56 bhosmer joined #salt
17:59 ckao joined #salt
18:01 srage joined #salt
18:01 martoss joined #salt
18:03 n8n joined #salt
18:04 dstokes there a way to disable hash checking in the file.managed state (for files loaded over https)?
18:04 centinel__ joined #salt
18:06 manfred dstokes: no? when you run the state the first time, it saves it to /var/cache/salt/minion, then it checks the hash against that, on the next run, it should just check the has to see if it is the same, and if it is you don't download it again, if it doesn't match, it attempts to download it
18:06 manfred or that is how i would have written it
18:07 dstokes got an error on first download b/c file state couldn't determine how to caculate the hash
18:07 dstokes "Unable to determine upstream hash of source file https://..."
18:08 srage joined #salt
18:17 tcotav dstokes: do you have - source_hash: set?
18:18 dstokes nope. wanted to avoid checking it at all (i trust the source). setting it for now
18:18 tcotav think its required
18:18 manfred &^^
18:18 manfred it is required
18:18 dstokes tcotav: thx
18:18 dstokes be nice to disable it for some requests
18:18 manfred If the file is hosted on a HTTP or FTP server then the source_hash argument is also required
18:20 pass_by_value joined #salt
18:28 forrest vagrant seriously doesn't support running states for salt?
18:28 forrest only highstates?
18:30 centinel__ I've installed Salt on an OS X 10.7.5 machine via Homebrew. When I run salt-minion from the plist I made, none of the pkg execution module's functions work. When I run salt-minion manually, the functions do work. I'm thinking it may have to do with my plist... http://pastebin.com/dAdZ9YF5
18:30 manfred i believe that is it
18:30 rojem joined #salt
18:30 manfred forrest: you cold set the startup_states: sls and set sls_list: ?
18:33 forrest manfred, yea
18:33 forrest just... annoying
18:33 manfred agreed
18:33 dalexander joined #salt
18:34 tcotav forrest: do you mean at provision?
18:34 forrest tcotav, yea, for the vagrantfile
18:34 forrest dipping into this a bit today to help out some devs get up and running more quickly
18:34 tcotav forest: ah yeah I always end up having to dump some stuff into a shell file to run at the end of a provision
18:35 tcotav (I owe you an 'r'...)
18:35 forrest tcotav, yeah that's what I might have to do
18:35 forrest their docs are just... limited
18:36 tcotav agreed.  that's why I end up using shell script -- I *know* what that'll do
18:37 forrest tcotav, yea, I mean if you mount /srv/, that's making the assumption it's already installed right? Which is pointless
18:37 forrest I'm not very familiar with vagrant though
18:37 tcotav I've had problems with that actually
18:37 forrest I don't want to mount /srv/, no one has that on their machine ready to go :P
18:37 tcotav I've used it a lot (year of chef consulting prior to being in salt now)
18:37 forrest ahh ok
18:37 tcotav I do end up mounting it
18:38 forrest but your salt content all lives under /srv/ on the host system right?
18:38 tcotav yes
18:38 forrest yea that's worthless to me
18:38 forrest I want the vagrant file to check everything out and do all of that
18:38 tcotav and I usually have that symlinked over to the users git repo -- so they end up having to modify the vagrantfile
18:39 forrest hmm
18:39 tcotav because honestly I don't want to git pull every time I spin up a vagrant instance
18:39 tcotav (we have this one ridiculously large repo that takes forever)
18:40 forrest ahh yea, that's not an issue here, especially since the repo is internal, only takes a few seconds to pull in
18:40 tcotav do devs have the repos on their host already though?
18:40 forrest no that's the thing
18:40 forrest I want to say 'ok install vagrant/virtualbox, pull this, and run it.'
18:41 forrest I already have all the salt stuff ready to go
18:41 tcotav ah
18:42 cheus joined #salt
18:42 tcotav so what I've done a bit here is created a custom vagrant box that has the repos pre-seeded
18:42 tcotav they'll be out of date, but at least you can do a git pull on them to get them up to date
18:42 forrest Hmm
18:43 forrest The repos being preseeded isn't a concern for me since it's all internal, and it pulls in fast.
18:43 forrest It's more the fact that this would be someone's laptop (mac/linux)
18:44 tcotav but you need /srv pulled, right?>
18:44 otter768 joined #salt
18:45 forrest That's what it seems like looking at these examples :\
18:45 forrest I don't ever use vagrant since I'm on linux
18:45 forrest but isn't it creating a full file tree?
18:45 forrest so it has it's own sub area with /srv?
18:46 tcotav its a linux vm yeah -- full system
18:46 tcotav it would have /srv if you made it
18:47 forrest right, it's more the usage in the example of 'synced_folder'
18:47 forrest which is not my plan at all :P
18:47 tcotav oh on that salt vagrant provision page.  yeah, I don't follow that
18:47 forrest I'll have to do some stuff to get this working correctly to checkout the salt formulas I need, then move the subdirs to the proper locations
18:49 tcotav you could write a shell script to run at provision that 1) stops salt on the host, 2) does all your file moves and then 3) starts it again
18:49 forrest tcotav, right
18:49 tcotav the other thing I found with vagrant-salt provision is that it kind of takes a while
18:49 forrest tcotav, I'm a bit disappointed that vagrant requires so much manual work with shell scripts
18:50 forrest I thoughti t was smarter than that for some reason
18:50 forrest it's like... ghetto salt cloud
18:50 forrest *thought it
18:50 tcotav well, I will say, the chef stuff has had a lot more work put into it than the salt stuff.  it works pretty well
18:50 forrest Right, but I mean prepping the environment for salt
18:51 forrest I still have to pull in the repos with the actual states and so on
18:51 metaphore joined #salt
18:51 tcotav well, if you went the standard route, you'd sync your /srv, have the minion config that points to them, and it'd just work
18:51 forrest tcotav, right, but that's not really user friendly for devs
18:51 tcotav *sync_folder your srv I mean
18:51 forrest since they'd still have to copy the repos down, then move content
18:52 tcotav they don't have to move it though -- you're essentially symlinked to the same copy they pulled down
18:52 tcotav I think it works great as they can then use their IDE to make changes and those changes magically appear in their VM via the /vagrant  mount point
18:52 forrest right that's the whole point
18:53 forrest since we have front end guys working on this, so it's super important they have IDEs and browsers to view it localy
18:53 forrest *locally
18:53 tcotav but they already have to git pull the other code down, right?
18:53 forrest no
18:53 tcotav their front end code
18:53 forrest my salt stuff does everything for them
18:54 tcotav hrm
18:54 forrest installs all the required packages, sets up the fake databases, and pulls in all required repos minus the states.
18:54 forrest Basically all I need vagrant to do is install salt, pull down the formula repos, and put those files in the right location, then run the state.
18:55 tcotav and all the required repos for the dev are in /vagrant or some other mount point accessible outside of the vm?
18:56 forrest well, my plan was to just do a git pull on them
18:56 forrest so git pull the formula repo, move the subdirs, run it
18:56 tcotav right, but where do the devs do their work?  where do they change files?
18:56 forrest oh that's inside of /vagrant once salt is configured, sorry.
18:57 tcotav ah ok
18:57 tcotav well... since Vagrantfile is just a ruby file, you could actually do the git pulls into /vagrant before you spun up an instance
18:58 tcotav or invoked a shell script that does it BEFORE you got to vm creation
18:58 forrest heh
18:58 forrest That's my plan
18:58 tcotav hehe
18:58 forrest I just felt like there should be a .... smoother? way to do it
18:58 forrest I don't know
18:58 forrest Salt has spoiled me
18:58 tcotav well, this is sort of a chicken and egg thing I think
18:58 forrest Right
18:58 tcotav if salt managed the dev's workstations -- you'd be totally set :D
18:59 forrest I actually proposed that :P
18:59 forrest if everyone ran linux I'd just have LXCs ready to go
18:59 forrest then they could just log in, salt-call state.sls 'my_project.build'
18:59 forrest and they'd be up
19:00 tcotav you could give them docker images
19:00 mgarfias i need access to some info from the master on a minion.  that is, i need hostnames that match a certain grain.  is this possible somehow?
19:00 forrest but that does't provide them the functionality that the devs need of using their IDEs
19:00 forrest that's the bonus of vagrant
19:01 mgarfias (for app deployment, dont want this on the salt master instance)
19:01 tcotav yeah -- you could link to a local dir from docker, but you'd still need to get those repos local first
19:01 forrest tcotav, yep!
19:02 orion__ joined #salt
19:02 schmutz joined #salt
19:02 mklauber joined #salt
19:02 vejdmn joined #salt
19:05 gothix joined #salt
19:05 mklauber Hey all, I'm trying to setup salt.  I've installed salt-master and salt-minion on the same ubuntu 14.04 x64 instance.  I started both services, ran "salt-key -a #id#" and I'm now getting authentication issues.
19:06 forrest mklauber, did you modify your minion conf to point at the master?
19:06 mklauber Yes, I believe so.  In my minion I put in the IP of the master.
19:06 mklauber I tried setting the minion to open_mode: True and I got this: This is my minion log.  https://gist.github.com/mklauber/c9a5baec9a7f6f42cca0
19:06 forrest mklauber, ok and you restarted?
19:06 forrest mklauber, the minion that is
19:07 mklauber Indeed.  salt-minion refuses to stay started now.
19:07 forrest mklauber, seems odd, what happens when you do salt-key -L
19:07 forrest I'm assuming you installed/configured as root/sudo?
19:07 mklauber YEs.
19:08 mklauber I can see the accepted key.
19:08 mklauber Is/could there be an issue with running the both the master and the minion on the same machine?
19:08 forrest ok, what happens when you sudo salt 'minion' test.ping?
19:08 forrest mklauber, no
19:08 forrest mklauber, tons of people do that
19:08 forrest I am doing it right now
19:09 mklauber "Failed to authenticate, is this user permitted to execute commands?"
19:09 ajprog_laptop joined #salt
19:09 forrest mklauber, hmm, ok, can you restart the master real quick?
19:09 mklauber sure.
19:10 forrest also, try sudo salt-call --local test.ping
19:10 forrest if that fails, there's an issue with the minion for sure (specifying --local only uses the minion, NOT the master)
19:10 scoates joined #salt
19:11 mklauber salt-call returns True.  restarting salt-master doesn't change the salt-key call or the salt 'minion' test.ping
19:11 mklauber It's a master/minion communication issue then?
19:12 forrest mklauber, it could be, but being able to accept the key seems odd. I'd suggest to do the steps here: https://gist.github.com/gravyboat/e6b93a6c1e6f9a776062 as well as salt-key -d minion_id
19:12 forrest so basically clean everything off on the minion, clear the minion from the master, and try to re-initialize. Also what version of salt are you running? The master and minion are the same correct?
19:13 forrest I probably should have asked that first, heh
19:14 rap424 joined #salt
19:15 mklauber master and minion are the same.   2014.1.10
19:15 forrest hmm
19:15 GnuLxUsr joined #salt
19:16 tcotav run this and restart -- https://gist.github.com/tcotav/a42d6b530e8bfda9f5cc
19:16 mklauber It's possible I have some corrupted/leftover data.  I'd run into issues and have run a apt-get purge salt-master salt-minion to get here.
19:16 tcotav the minion
19:16 forrest tcotav, that was what I just linked him :P
19:16 forrest tcotav, I forked yours yesterday
19:16 tcotav oh :-/
19:16 forrest tcotav, I didn't realize you were in Seattle as well, you should have come to the doc sprint!
19:16 tcotav oopsies
19:17 tcotav you're in seattle too?  I caught just a bit of that doc sprint going on.  Didn't realize it was local.
19:17 forrest Yea the shop I work at was hosting a location
19:18 forrest No one came :P
19:18 rawkode joined #salt
19:18 tcotav hehe
19:18 tcotav well that's a bummer
19:18 forrest It happens
19:18 forrest I just attended the hangout
19:18 tcotav to be fair -- it just further proves that no one likes to document evar :-p
19:18 forrest lol
19:19 forrest I enjoy writing documentation
19:19 rawkode Hey folks - could somebody help me with a quick question, please? I've got my salt-master accepting keys using ec2-autoscale-reactor, but it's not bootstrapping the machines. Should I be installing salt-minion on these through an init script, or should the reactor be doing it? :/
19:19 forrest Ryan_Lane, are you around?
19:21 mapu joined #salt
19:21 mklauber Are there any restrictions on salt server ids?
19:21 mklauber *minion ids
19:21 forrest mklauber, dates don't work
19:21 forrest I believe a bug was opened for that
19:21 mklauber dashes?
19:21 forrest but it might be a yaml pproblem
19:21 forrest uhh dash should be ok...
19:22 forrest I'm using dashes myself
19:22 mklauber name of minion is vpc-mgmt
19:22 forrest that should be fine
19:22 whytewolf joined #salt
19:22 forrest rawkode, I'm not familiar enough with the formula to provide much help past what the readme has, sorry :(
19:22 cron0 joined #salt
19:22 rawkode No problems. Thanks anyway, forrest
19:24 rawkode Starting to wish I'd spent more time with python, rather than php, these last few years
19:24 forrest heh
19:26 SheetiS I've been a big fan of python.  It was one of my main reasons for giving salt a try.
19:28 aparsons joined #salt
19:29 bhosmer joined #salt
19:31 mklauber forrest: Thanks for the assist.  I think this instance is borked.
19:31 forrest mklauber, yeah np
19:31 forrest that sucks though
19:31 forrest they do work on a single system though
19:31 forrest as a heads up
19:32 mklauber meh.  I was just starting to work on it.  Not losing too much.
19:32 forrest cool
19:34 aquinas joined #salt
19:36 TOoSmOotH joined #salt
19:39 nkuttler joined #salt
19:42 aparsons joined #salt
19:46 martoss joined #salt
19:47 aparsons joined #salt
19:51 chrisjones joined #salt
19:51 tyson_ joined #salt
19:53 centinel__ joined #salt
19:54 Hydrosine joined #salt
19:54 mklauber forrest:  Ok, so I'm not sure what I did to screw it up, but I found that my master had a couple zombie salt processes that seemed to be screwing things up.  A reboot solved that.
19:55 icebourg joined #salt
19:56 kermit joined #salt
19:57 transmutated joined #salt
19:59 nkuttler joined #salt
20:05 vejdmn joined #salt
20:07 beebeeep joined #salt
20:07 rigor789|away joined #salt
20:09 tyson_ joined #salt
20:12 ipmb joined #salt
20:18 orion_ joined #salt
20:19 marcinkuzminski joined #salt
20:20 Eugene Before I go write my own, is there a salt-passwd command running around I can steal?
20:22 robawt Eugene: you are generating a hash or setting a pw somewhere?
20:22 Eugene "set user's password on the named minion"
20:22 Eugene Via shadow.set_password
20:22 SheetiS joined #salt
20:25 ericof joined #salt
20:26 snuffeluffegus joined #salt
20:29 panchisco joined #salt
20:30 tyson_ joined #salt
20:30 forrest mklauber, good to know, sorry went to lunch
20:30 robawt you're better off passing a hash to the user creation, or updating user record against known pillar data
20:31 robawt ping pass_by_value
20:31 pass_by_value hi robawt
20:33 forrest pass_by_value, You've been slacking on the commits lately .:P
20:33 pass_by_value i'm a total slacker ;)
20:34 forrest fair enough
20:36 pass_by_value forrest: nice to hear from you btw!
20:37 forrest pass_by_value, haha, I always forget you are in here.
20:37 forrest pass_by_value, How goes things on the east coast?
20:37 pass_by_value I've been tied up with some other stuff, so I've not had the chance to log in for a while.
20:38 forrest ahh ok
20:38 pass_by_value Not too bad, some rain
20:39 capitalfellow joined #salt
20:40 forrest nice
20:40 pass_by_value How about Seattle?
20:41 forrest Good! Lots going on which is nice, pretty good weather
20:43 Eugene I forgot how moist it gets around here. I'm pondering a dehumidifier
20:43 pass_by_value Nice, there's been stuff going on here as well. Summer is so nice.
20:43 Eugene My office feels like the inside of an armpit :-/
20:43 pass_by_value lol Eugene I was just gonna say that it is really humid ;)
20:46 forrest pass_by_value, yea I've been enjoying it.
20:46 forrest Eugene, lol, I got rid of my humidifier when I moved here from Arizona
20:46 Eugene robawt - the point is that the user themself needs to do the password setting(or updating the hash in pillar, or whatever), because *I* don't want to touch their KeePass database
20:47 robawt gotcha
20:47 pass_by_value Ah, I didn't realize y'all might be talking about Seattle. Upstate NY also gets humid during summer
20:47 robawt and access to that file isn't that easy
20:48 Eugene Hence, give users a salt-passwd command they can run(optionally with a minion or other selector) to self-service
20:48 centinel__ joined #salt
20:50 aparsons joined #salt
20:50 forrest pass_by_value, yeah it does get humid here, but it isn't that bad thankfully
20:55 UtahDave Ah, it's a nice 24% humidity here in Salt Lake City
20:55 rigor789|away joined #salt
20:56 dude joined #salt
20:56 mklauber left #salt
20:57 aparsons joined #salt
20:59 rlarkin joined #salt
21:01 Guest96173 how can you override a pillar value via the CLI? i've tried salt '*' state.highstate pillar="{foo: 'bar'}", pillar="{'foo': 'bar'}", pillar='{foo: "bar"}', etc. (i've seen some or all of these suggestions in various places). i'm not even able to get this working to set a *new* pillar key, let alone override an existing one :)
21:02 forrest Guest96173, there was this issue: https://github.com/saltstack/salt/issues/3579, and then https://github.com/saltstack/salt/issues/4467
21:02 forrest both contained examples
21:02 forrest whiteinge was using the api in the second example
21:03 forrest Guest96173, I created this issue to document it as well: https://github.com/saltstack/salt/issues/14217
21:05 forrest UtahDave, are you around?
21:05 UtahDave yep!
21:06 forrest UtahDave, do you remember the pillar variable format for passing stuff through on the command line? I should have notated it in my original issue..
21:06 UtahDave Yeah, let me find a good example.
21:06 forrest cool
21:07 Guest96173 ugh. got it
21:07 forrest Guest96173, cool, can you notate it on that issue I created (14217)
21:07 forrest UtahDave, nevermind he's got it
21:07 Guest96173 was trying to get the value in a pillar file (to override the default)
21:08 UtahDave forrest: I always end up asking whiteinge, but he's on a plane right now
21:08 forrest UtahDave, haha, yeah I would have asked him but I knew he wasn't here :P
21:08 Guest96173 there actually is an 'official' example here: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#salt.modules.state.sls
21:08 forrest oh sweet
21:08 forrest I didn't even know that was around
21:08 Guest96173 and that format works for me
21:08 forrest awesome, going to add that to the issue I have
21:08 forrest so it gets in the actual pillar docs :D
21:08 Guest96173 but i didn't know it because i was trying to get it in a pillar :)
21:09 Guest96173 cool
21:09 Guest96173 yeah it took some searching
21:09 UtahDave there you go.  We should add that to pillar docs, too
21:09 Guest96173 and kept seeing different formats
21:09 nyx joined #salt
21:09 forrest UtahDave, yea I have 14217 open just for that
21:09 UtahDave cool
21:09 forrest good find Guest96173
21:10 aparsons joined #salt
21:11 hdiogenes joined #salt
21:12 aparsons joined #salt
21:17 Guest96173 forrest: ok now that i know the format, how would you suggest overriding an existing pillar value? i could set a different pillar key on the CLI and use that if set, otherwise the default pillar value, but i don't have access to the new pillar key in the pillar file. i'd like to check for it in one place
21:17 tyson_ joined #salt
21:18 kermit joined #salt
21:22 forrest Guest96173, so you need a specific pillar value for two different systems?
21:23 Guest96173 forrest: no i want one pillar key (foo) and set a default value for it (bar) in a pillar file. but sometimes i'll want to change that value for one CLI run
21:23 forrest I thought you said you just figured out how to set it on the CLI?
21:23 forrest I thought you could just override straigth from the CLI
21:24 forrest by doing bar = foo2
21:25 panchisco joined #salt
21:26 Guest96173 forrest: actually, i think it's complicated by the fact that the key is nested, so in my pillar file it's {a: {b: c}, {d: e}}. i want to override b's value to something else via the CLI. but if i do pillar="{a: {b: 'z'}}", it replaces *all* of a (so i lose the d key)
21:26 Guest96173 so that's why i was thinking setting a different 'top-level' var on the CLI and checking for that would be better
21:26 forrest Guest96173, oh I see, yes that is quite problematic.
21:26 Guest96173 but i can't check for that var in the pillar file
21:27 forrest Guest96173, ok, let's start from the bottom and see if we can work our way up. Is the pillar value used in a managed file?
21:28 Guest96173 the only solution i see right now is to move b to the top level and do pillar="{b: 'z'}" to override it. but then it's not organized :)
21:28 forrest and also, what says that the pillar value would change?
21:29 forrest and by that I mean, what determines that the pillar value would be different? Type of machine? Or just totally random?
21:29 Guest96173 maybe making it concrete will be easier: the value is a git revision. i want it to default to master, but be able to specify any tree-ish on the CLI if i want to deploy some other revision
21:29 orion__ joined #salt
21:30 forrest Guest96173, Ahh alright, that sucks then, we can't take advantage of the other stuff Salt offers
21:30 Guest96173 what kind of stuff?
21:30 forrest Guest96173, ok so what about this.
21:30 forrest hang on let me gist it real quick
21:31 Guest96173 k. oh you just meant different values for different machines, etc.
21:31 forrest Guest96173, right
21:31 Guest96173 using maps or whatnot
21:31 Guest96173 k
21:31 Guest96173 yeah this would be the same across all targeted minions
21:32 mrothe left #salt
21:33 druonysuse joined #salt
21:33 forrest Guest96173, https://gist.github.com/gravyboat/d71458688ee84dc0ca66
21:33 forrest what do you think of something like that?
21:33 forrest my syntax MIGHT be wrong on that call
21:33 forrest I didn't look it up
21:34 forrest then you could specify on the command line that the git:env value = dev, and deploy the other revision (or whatever you might have)
21:35 forrest it's definitely not perfect, but I don't know if there is a way to set a specific key to a value and join it with the existing stuff :\
21:38 schmutz joined #salt
21:39 Guest96173 forrest: i have other stuff inside that git key, so setting git:env on the CLI would blow away the rest of it.. but if i set some new key pillar="{rev: 'asdf1234'}", then i should be able to check for that and default to git:rev in a *state* file. i use this var in a few places though, so i'd have to do this logic everywhere (and remember to do it everywhere). so i wanted to be able to check and set it in one place (the pillar file).
21:40 Guest96173 oh well, i'll mess with it some more. just wanted to see if i was missing something
21:42 smcquay joined #salt
21:44 forrest Guest96173, gotcha, yea that would suck. I'd suggest to post on the mailing list. Someone there more familiar with pillar values being passed through on the CLI might have an idea of how to do a merge or something
21:44 Guest96173 forrest: cool thanks for the help
21:45 Guest96173 i'll let you know if i figure something decent out :)
21:45 forrest Guest96173, yea I'd appreciate it, especially if you can comment on https://github.com/saltstack/salt/issues/14217
21:45 forrest then we can get it updated across the board with overwriting variables so other users aren't confused
21:46 Thiggy joined #salt
21:46 Guest96173 forrest: definitely
21:47 Thiggy I submitted a PR backporting a fix to the 0.16 branch (https://github.com/saltstack/salt/pull/15037), should I open a an issue referencing this as well or is a PR sufficient?
21:48 forrest Thiggy, uhh you know I don't know if they're still taking PRs for backports, usually those are 'locked. UtahDave has the opinion on that changed recently around the office?
21:48 forrest Thiggy, is there a reason you can't just port it to your own copy?
21:48 Thiggy All our provisioning scripts use the bootstrap with a 0.16 branch specified
21:48 UtahDave Thiggy: a PR is sufficient. We don't support 0.16 anymore, but I'm not sure if it's actually blocked or not.
21:49 Thiggy the bootstrap script broke recently as it seemed to stop supporting tags
21:49 Thiggy so we had to go through and update it to point to the branches
21:49 UtahDave Thiggy: bootstrap should still support tags, I believe
21:49 forrest yea it still supports tags unless s0undt3ch pulled that out
21:49 Thiggy I'm not sure, it was during a production outage and I was trying to spin up some new instances
21:50 forrest Thiggy, as a work around you could always modify the bootstrap to pull from your git fork
21:50 forrest Thiggy, gotcha
21:50 Thiggy started getting all kinds of weird errors and debugged it to the bootstrap script installing lastest 2014 instead of the specified v0.16 tag
21:50 forrest Thiggy, weird
21:50 ajolo_ joined #salt
21:51 forrest thiggy, if you can duplicate that, could you please open an issue on github? I can't see any reason why that functionality would purposefully be pulled :\
21:51 Thiggy I haven't tried since that day, and it was pretty hectic that day
21:51 skyler Hi, I am just learning salt, and I am starting by setting up some users. I set up the user information, used the salt command, and it worked. Then I changed the passwd in the .sls file, and ran salt again. Salt said everything was up to date and did not update the passwords.
21:51 Thiggy I'll try it again and see, we've already updated all our provisioning scripts to reflect the branches
21:51 skyler How do I get it to update the passwords?
21:51 bhosmer joined #salt
21:52 forrest Thiggy, ok thanks.
21:52 UtahDave skyler: what version of Salt and which os?
21:53 skyler @UtahDave: I am using salt 2014.1.10 (Hydrogen) and Ubuntu 12.04.4
21:56 UtahDave skyler: could you open an issue on that? I'm pretty sure it should update the password for you.
21:56 manfred skyler: enforce_password should default to True...
21:57 manfred it should
21:57 manfred enforce_password
21:57 manfred Set to False to keep the password from being changed if it has already been set and the password hash differs from what is specified in the "password" field. This option will be ignored if "password" is not specified, Default is True.
21:57 manfred skyler: using user.present right?
21:57 UtahDave ah, thanks, manfred. I hadn't noticed those new options.
21:58 skyler manfred: Yes, user.present.
21:58 manfred it should be changing it ...
21:58 manfred ¯\(°_o)/¯
21:58 forrest yea I'm surprised it isn't
21:58 skyler Just a sec, I am going to try out enforce_password
21:58 forrest seems very odd
21:59 manfred enforce_password defaults to True
21:59 skyler oh, I see.
21:59 marcinkuzminski joined #salt
22:00 skyler Ah, I have discovered the source of the problem: me. I specified 'passwd' instead of 'password' because I saw 'passwd' in the output for creating a user.
22:00 manfred that would do it :)
22:01 tk75 I think you'd have seen ninja errors in the logs or output ... nothing?
22:01 tk75 err, jinja
22:01 aparsons joined #salt
22:02 viq joined #salt
22:05 Emantor joined #salt
22:08 centinel__ joined #salt
22:09 elfixit joined #salt
22:11 aparsons joined #salt
22:13 jhulten joined #salt
22:14 bray joined #salt
22:14 panchisco joined #salt
22:15 bray joined #salt
22:16 smcquay joined #salt
22:17 Ryan_Lane joined #salt
22:20 capitalf_ joined #salt
22:24 aparsons joined #salt
22:26 icebourg joined #salt
22:29 Nazzy joined #salt
22:32 Thiggy joined #salt
22:39 ajolo_ joined #salt
22:46 mapu joined #salt
22:50 druonysuse joined #salt
22:52 skyler What are best practices for version control, relating to states and pillars? For example, would you usually do two repositories, one for each?
22:53 forrest skyler, in what sense? different environments?
22:55 skyler forrest, I mean it is probably okay for everyone to see your states, but you wouldn't want everyone looking at the pillars because they could have secure data in them. So you wouldn't want pillars in your version control with states, right?
22:55 forrest skyler, right, we store secure pillar data only on the master (so only users with elevated perms can review them) that get merged into the rest of the pillars
22:57 skyler forrest, so would I put all insecure pillars in the same repository as the states?
22:57 Thiggy Hey @forrest what's your @name on github?
22:57 forrest Thiggy, it's gravyboat
22:57 Thiggy ok thanks
22:57 forrest Thiggy, https://github.com/gravyboat/
22:57 forrest Thiggy, yea np
22:58 n8n joined #salt
22:58 Thiggy I just repro'd the tags not working bootstrap bug , submitting a PR, gonna cc you
22:58 Thiggy err submitting an issue
22:58 oz_akan joined #salt
22:58 forrest thiggy sounds good
22:58 forrest hopefully s0undt3ch takes a look, I haven't worked on the bootstrap in a few months
23:00 forrest skyler, couple of options: http://docs.saltstack.com/en/latest/ref/configuration/master.html#pillar-roots
23:01 bhosmer joined #salt
23:03 forrest skyler, this is how I did it for a smaller scale project: https://github.com/gravyboat/hungryadmin-sls/tree/master/pillar
23:04 forrest granted that's a full file tree as an example, so don't do that :P
23:04 panchisco joined #salt
23:04 forrest but I just have all the pillar data (non secure) in one place. Then I can just pull in updates. Depending on the size of your environment however, that might not be a good plan
23:04 forrest for collisions
23:06 skyler forrest, what do you mean by don't do a full file tree?
23:06 forrest in that example if you go up one directory I have the full tree for salt that would exist under /srv :P
23:06 forrest so my formulas and states are in that repo as well
23:09 skyler Hmm... So it would be a good idea to keep my formulas in a different place and use gitfs, right?
23:09 forrest skyler, of course
23:09 forrest skyler, I only do that because it's part of a tutorial I wrote
23:09 forrest and I wanted to make it easy for users
23:10 forrest skyler, did you already look at ext_pillars? http://salt.readthedocs.org/en/latest/topics/development/external_pillars.html
23:10 skyler I see. Basically I am just trying to figure out where all the seperations are right now so I can lay out my project well. I am also new to configuration management, so I am learning a lot of concepts.
23:11 forrest skyler, Oh yeah totally understandable, I wasn't trying to sound condescending :D
23:11 skyler I have not yet. I will read over that.
23:11 forrest cool
23:12 forrest skyler, the ext_pillar stuff is mostly for generating data. I'm trying to think if there's a good example...
23:12 CheKoLyN joined #salt
23:13 Hazelesque joined #salt
23:13 manfred etcd
23:13 forrest manfred, ?
23:14 manfred you can store your pillars in etcd
23:14 manfred that is how coreos shares information about docker clusters
23:14 forrest manfred, oh yeah that could work as well
23:14 forrest manfred, are you guys storing pillars in git?
23:14 forrest for non-sensitive data
23:14 manfred i am not
23:14 forrest or how are you handling that
23:14 manfred i haven't gotten around to it yet
23:14 forrest so where are you storing pillar?
23:14 forrest just on the master?
23:14 manfred yeah
23:15 forrest gotcha
23:15 manfred terminalmage was working on the git auth for pygit2 so you could use authenticated gitfs/ext_pillar
23:15 manfred soonish
23:15 forrest that would be sick
23:17 manfred yes
23:18 skyler So here is where I am at right now in terms laying out my repos. Basically, the git repo would include all custom states, and all insecure pillars.
23:19 skyler The only things not included would be formulas and secure data. formulas would be accessible as forks from saltstack-formulas on a local machine.
23:19 srage joined #salt
23:19 skyler Secure data would be stored on the salt master, and possibly under version control (seperate and secure version control from the rest of it).
23:19 skyler Does this sound like a reasonable organization?
23:21 forrest skyler, I'd be concerned about changes in one pillar affecting another, or if they were in separate repos, too many, but  it seems reasonable to me.
23:21 forrest we're basically checking in all our insecure pillar data since we use reclass
23:21 forrest so I can't really talk
23:21 forrest but it's only me and one other guy that run the whole salt show
23:21 forrest so collisions are rare
23:23 skyler When you say one pillar affecting another, you mean clobbering names in pillars or something like that?
23:24 forrest no I just mean you make changes in pillar file A and push, coworker makes changes in pillar file B and pushes, you pull to the master, OH GOD CHANGE B BROKE ALL THE THINGS
23:24 srage_ joined #salt
23:25 skyler Ah, yes, I see. That could be an issue, but it will just be two guys here, and I have all of our changes going through gerrit for code review, so we should at least check out each others changes before they go into use.
23:25 tcotav we manage name collision in pillars with the honor system
23:26 tcotav and a prefix (we have four groups mucking about in there)
23:26 forrest skyler, should be ok then
23:26 forrest tcotav, right I'm not saying it can't be done, just that it is something to be wary of.
23:26 Nazzy joined #salt
23:26 tcotav no definitely -- I meant to reinforce your point rather than contradict :D
23:27 forrest tcotav, gotcha
23:28 skyler So for secure data, do you follow some convention for leaving example pillars so that someone can construct a pillar containing the proper secure data without looking at the secure pillar?
23:29 icebourg joined #salt
23:30 icebourg joined #salt
23:30 icebourg joined #salt
23:33 srage joined #salt
23:36 SheetiS joined #salt
23:36 forrest skyler, yes, all my repos contain example pillars that include all fields
23:37 forrest skyler, I'll just do something like password: fake_pass
23:37 forrest or something
23:37 skyler forrest, do you provide example pillars for insecure data as well, or do the insecure pillars already count as that?
23:38 forrest skyler, so for each set of states (or formula), I put a pillar.example file in the repo, that has everything secure and insecure
23:38 skyler forrest: Alright. Thanks a ton! You are the bomb. I am going to stop hounding you with questions for now.
23:39 forrest skyler, no worries, it's almost time to go home anyways, so things have gotten a bit more quiet. I'm going to create an issue to update the best practices again with how that stuff should be structured.
23:39 stanchan joined #salt
23:39 SheetiS :D
23:40 skyler forrest: Awesome, sounds great.
23:42 aparsons joined #salt
23:46 TheThing joined #salt
23:48 oz_akan joined #salt
23:51 forrest skyler, https://github.com/saltstack/salt/issues/15041 if you have comments to add.
23:54 forrest carmony, are you around?
23:57 TheThing_ joined #salt

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