Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-11-12

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

All times shown according to UTC.

Time Nick Message
00:09 hunmonk is there a way to run an upgrade of all system packages from a state file? i see pkg.upgrade as a module function, but am having trouble finding the state file equivalent
00:10 nicksloan hunmonk: in 2014.7 there is pkg.upgrade_all
00:10 jalbretsen joined #salt
00:10 skyler joined #salt
00:10 nicksloan and by that I mean pkg.uptodate: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.uptodate
00:12 bhosmer joined #salt
00:12 hunmonk nicksloan: yeah, that's what i'm looking for, thanks!
00:13 cmthornton iggy: |+ or |n+ allows you to keep n whitespace characters... I've only seen it used once or twice
00:17 jameswarren joined #salt
00:17 Setsuna666 joined #salt
00:18 speed145a joined #salt
00:27 gothix joined #salt
00:28 gothix left #salt
00:28 hal58th joined #salt
00:28 aqua^mac joined #salt
00:31 gothix joined #salt
00:31 murrdoc is there a way to do {% from "global/map.jinja" import * with context %}
00:31 murrdoc where * means, import all
00:32 gothix joined #salt
00:35 ajolo joined #salt
00:35 pipps99 joined #salt
00:41 Ryan_Lane murrdoc: you could probably make a function that iterates over the sls files in a given directory and imports it with context
00:41 Ryan_Lane then call the function for the directory
00:41 murrdoc yeah
00:42 murrdoc good call
00:44 baconbeckons joined #salt
00:45 baconbeckons i started getting the error “salt.exceptions.LoaderError: The renderer yaml_jinja is unavailable, this error is often because the needed software is unavailable” after trying to use salt-bootstrap to install v2014.7.0rc7
00:50 srage_ joined #salt
00:51 baconbeckons looks like it was a bad install. i installed again and things appear to work
00:55 thayne joined #salt
00:55 aparsons_ joined #salt
01:00 aqua^mac joined #salt
01:03 b1nar1 joined #salt
01:06 ajolo joined #salt
01:21 baconbeckons actually, the problem was that i’m using the salt formula to manage the salt master. when i installed 2014.7.0rc7, i used bootstrap. when my states ran on the saltmaster, the formula expects salt to be installed as a pkg. since the bootstrap script doesn’t install it as a package, it was installed again (as 2014.1.x). if I reinstall salt using the bootstrap after this, then it seems to work because the pkg shows it is installed. how do
01:21 baconbeckons install using bootstrap and manage salt with the formula though?
01:24 murrdoc joined #salt
01:25 b1nar1 joined #salt
01:26 TheThing joined #salt
01:36 wendall911 joined #salt
01:45 tmh1999 joined #salt
01:48 Ryan_Lane joined #salt
01:48 TTimo joined #salt
01:50 aquinas joined #salt
01:51 skyler baconbeckons: I just have my own state for salt that I use to manage salt. The state uses packages by default, but uses the bootstrap script if I provide an alternate version in a pillar.
01:59 aquinas joined #salt
02:00 aqua^mac joined #salt
02:00 baconbeckons skyler: that sounds like something that should be in the formula :)
02:00 bhosmer joined #salt
02:05 gywang joined #salt
02:07 gywang Hi all, I can't find service.enable in salt functions, why?
02:08 ajolo joined #salt
02:08 gywang if not 'service.enable' in __salt__ or not 'service.enabled' in __salt__:   it cames false
02:09 aquinas joined #salt
02:10 jaimed joined #salt
02:14 aquinas joined #salt
02:21 aquinas joined #salt
02:25 justlooks joined #salt
02:25 Nexpro1 joined #salt
02:28 wendall911 joined #salt
02:28 jab416171 joined #salt
02:29 wendall911 joined #salt
02:43 justlooks when i use salt 'host' cmd.run 'echo $JAVA_HOME'  ,i get nothing ,but i set JAVA_HOME env variable in /etc/profile why?
02:45 justlooks anyone can help?
02:53 gywang add a line like 'source /etc/profile'
02:55 justlooks gywang: but why not ,event i restart salt minion?
02:55 mosen joined #salt
02:56 rotanid joined #salt
02:57 rotanid left #salt
02:59 perfectsine joined #salt
03:02 gywang It seems that cmd.run doesn't execute /etc/profile as env
03:05 justlooks gywang: so some command will cause different result ,when it depend on env variables in /etc/profile
03:07 justlooks gywang:  one of my classmate use salt ,when he run java command ,it failed ,but the minion has java env set on /etc/profile, he installed a new jdk ,his action cause tomcat can not provide normal service
03:08 genediazjr joined #salt
03:09 Mso150_x joined #salt
03:09 gywang justlooks: yeah, seems that, as my experience
03:09 justlooks gywang: i think it very dangerous
03:10 genediazjr joined #salt
03:11 johtso joined #salt
03:13 gywang justlooks: :)
03:14 justlooks gywang: why do not let salt cmd.run read the /etc/profile ?
03:16 gywang justlooks: Neither did I know.
03:37 asyncsrc joined #salt
03:38 pdayton joined #salt
03:39 asyncsrc Does anybody know of a way to output the contents of a jinja variable without needing to use {{ show_full_context() }}?  i'd love to quickly be able to see a specific variable's value when debugging a state file
03:39 Bremsstrahlung joined #salt
03:39 asyncsrc (And also without needing to set the minion in debug mode manually)
03:39 rm_jorge joined #salt
03:43 pdayton joined #salt
03:49 bhosmer joined #salt
03:53 hunmonk can the master remember which minions did not receive a command if some are offline when one is issued?
04:00 basepi hunmonk: no. it's a feature we eventually want to build in, but currently it just publishes the job once and then receives the returns which come, nothing more.
04:02 hunmonk basepi: cool, thx for the answer. is there at least some way to get a list of the servers that didn't receive the command? i imagine it would be pretty easy to roll my own thing over top of that
04:02 basepi Try passing in `--show-timeout`
04:04 hunmonk basepi: will do
04:07 mdasilva joined #salt
04:08 KyleG joined #salt
04:08 KyleG joined #salt
04:10 genediazjr joined #salt
04:13 rojem joined #salt
04:14 jameswarren joined #salt
04:25 Ryan_Lane joined #salt
04:25 Ryan_Lane joined #salt
04:33 favadi_ joined #salt
04:44 genediazjr joined #salt
04:52 smcquay joined #salt
04:54 genediazjr joined #salt
05:04 genediazjr joined #salt
05:10 jameswarren joined #salt
05:12 geekatcmu If you think salt, or the design thereof, has anything to do with why /etc/profile is not sourced for non-interactive sessions, then you need to spend a little time getting familiar with unix in general and /bin/sh in particular.
05:20 joehh geekatcmu: I think I understand what you are saying, but am not entirely sure
05:21 joehh I understand that you are saying that salt is correct in not sourceing /etc/profile
05:21 joehh is that correct?
05:22 gmcwhistler joined #salt
05:23 geekatcmu salt has NOTHING to do with it.
05:23 geekatcmu Salt is a pythong program.
05:23 geekatcmu /etc/profile is for shell scripts.
05:23 geekatcmu Specifically, /etc/profile is for interactive shell scripts.
05:23 geekatcmu None of the daemons that get started by init have /etc/profile sourced, because they are started by non-interactive scripts.
05:23 geekatcmu This is by design.
05:24 geekatcmu So, as I sed, you really need to spend some time learning about unix in general and /bin/sh in particular.
05:24 geekatcmu s/pythong/python/
05:24 geekatcmu I don't know why I keep typing pythong.
05:24 geekatcmu But I've been doing it for more than a decade now.
05:25 joehh good - we are on the same page
05:25 thayne joined #salt
05:25 joehh was unclear if there was an issue with packaged init scripts
05:26 geekatcmu nope
05:26 geekatcmu They are behaving as designed
05:26 aqua^mac joined #salt
05:29 Reiner0316 joined #salt
05:37 TyrfingMjolnir joined #salt
05:37 bhosmer joined #salt
05:45 felskrone joined #salt
05:45 bhosmer joined #salt
05:53 eguess joined #salt
05:54 eguess hello!
05:55 eguess I'm just starting with salt and having a bit of an issue: I'm trying to connect a salt-minion working in a docker container with salt-master and it doesn't seem to see it
05:56 eguess when i'm editing the salt-minion config file by just uncommenting the #master: salt line it gives me an error at minion startup :[ERROR   ] Error parsing configuration file: /etc/salt/minion - conf should be a document, not <type 'str'>.
05:57 NV bah, does anyone know a way to append to a dict in jinja?
06:00 eguess http://stackoverflow.com/questions/11047886/modifying-dictionary-attributes-in-jinja2 may be it will help;)
06:01 NV does salt support do?
06:02 eguess have no idea
06:02 eguess i'm just starting with it
06:05 pdayton joined #salt
06:06 eguess well it seems i fixed the problem with parsing error...
06:07 genediazjr joined #salt
06:08 eguess so to fully describe  the problem - i'm running salt-master on a mac and salt-minions are on the same machine running in the docker container. the default settings don't seem to work, but when i changed the interface setting for master in /etc/salt/master it refused to bind the ports
06:09 eguess any info is much appreciated;)
06:11 NV looks like the do extension is in salt after all
06:11 NV sadly I don't know much about docker
06:15 eguess no problem;) may be by morning someone would be able to give some hint;)
06:20 shookees joined #salt
06:29 saravanans joined #salt
06:30 genediazjr joined #salt
06:32 n8n joined #salt
06:33 seydu joined #salt
06:36 n8n joined #salt
06:36 garthk joined #salt
06:37 jhauser joined #salt
06:38 nethershaw joined #salt
06:39 rm_jorge joined #salt
06:42 linjan joined #salt
06:46 saravana_ joined #salt
06:48 catpigger joined #salt
06:54 oyvjel joined #salt
06:54 TTimo joined #salt
06:59 CeBe joined #salt
07:01 colttt joined #salt
07:05 saravanans joined #salt
07:10 ndrei joined #salt
07:14 genediazjr joined #salt
07:14 wnkz_ joined #salt
07:15 saravanans joined #salt
07:24 wvds-nl joined #salt
07:25 genediazjr joined #salt
07:26 nethershaw joined #salt
07:26 bhosmer joined #salt
07:29 saravanans joined #salt
07:30 flyboy joined #salt
07:33 ramishra joined #salt
07:36 aparsons joined #salt
07:37 saravana_ joined #salt
07:39 aparsons_ joined #salt
07:42 saravanans joined #salt
07:43 lcavassa joined #salt
07:44 trikke joined #salt
07:45 b1nar1_ joined #salt
07:46 xsteadfastx joined #salt
07:48 saravanans joined #salt
07:52 jdmf joined #salt
07:54 saravanans joined #salt
07:54 seydu joined #salt
07:55 TTimo joined #salt
07:56 jdmf joined #salt
07:57 genediazjr joined #salt
07:58 jdmf joined #salt
08:00 __gotcha joined #salt
08:00 __gotcha1 joined #salt
08:04 dRiN joined #salt
08:04 genediazjr joined #salt
08:06 __gotcha joined #salt
08:07 \ask joined #salt
08:09 __gotcha1 joined #salt
08:10 trikke joined #salt
08:11 xyl joined #salt
08:14 xyl joined #salt
08:14 jdmf joined #salt
08:14 shorty_mu joined #salt
08:15 linjan joined #salt
08:26 P0bailey joined #salt
08:26 P0bailey joined #salt
08:27 ramishra joined #salt
08:29 Zr40 joined #salt
08:31 Reiner0316 joined #salt
08:32 eseyman joined #salt
08:32 genediazjr joined #salt
08:32 godber joined #salt
08:36 alexr__ joined #salt
08:39 PI-Lloyd joined #salt
08:40 ramishra joined #salt
08:41 alexr__ joined #salt
08:56 TTimo joined #salt
09:00 ramishra joined #salt
09:03 ckao joined #salt
09:05 eightyeight joined #salt
09:06 bahadir joined #salt
09:07 genediazjr joined #salt
09:09 bhi joined #salt
09:14 bhosmer joined #salt
09:15 rhand joined #salt
09:15 jalbretsen joined #salt
09:19 rattmuff joined #salt
09:25 alexr__ joined #salt
09:27 __gotcha joined #salt
09:28 ramishra joined #salt
09:31 genediazjr joined #salt
09:32 intellix joined #salt
09:34 genediazjr joined #salt
09:35 lkthomas joined #salt
09:35 lkthomas hey guys
09:35 Zr40 left #salt
09:37 AirOnSkin heyho
09:37 lkthomas does saltstack is ready for production system ?
09:39 jrluis joined #salt
09:39 ramishra joined #salt
09:39 lkthomas also, if I want to compare md5sum value from both servers, can I use bash script to get it done ?
09:43 genediazjr joined #salt
09:44 babilen lkthomas: We are very much using it in production and you can use something like "salt '*' cmd.run 'md5sum /path/to/file" to run that command on all minions.
09:44 AirOnSkin lkthomas: It sure is ready for production use. The question is how you configure it...
09:45 lkthomas I see
09:45 lkthomas so if I want to compare value between two servers, how should I do that ?
09:45 lkthomas I know single command execution just fine
09:45 lkthomas but how to use bash script to do result compare then execute another command is my question
09:46 babilen That sounds like a question for #bash rather than #salt
09:46 babilen What are you really trying to do?
09:46 lkthomas not yet
09:46 lkthomas I know bash
09:46 AxelFooley joined #salt
09:46 babilen show me
09:47 lkthomas babilen, my question is, do I have to write login on saltstack using what it based or required
09:47 lkthomas or I could just use bash to so call "bind" all command together ?
09:47 babilen I don't understand that question. What do you mean by "write login on saltstack using what it based or required" ?
09:47 bhosmer joined #salt
09:47 lkthomas writing logic*
09:48 lkthomas sorry, typo
09:48 babilen Waht are you trying to achieve?
09:48 lkthomas for example, on MCollective, I have to use ruby
09:48 babilen *What
09:48 lkthomas OK, I got some file checksum between Satellite server and core server
09:49 AxelFooley hey guys, i'm using the gitfs backend, and when i push a modification to a state file (or a pillar, or whatever), i have to restart the master to make it up to date
09:49 AxelFooley there is a way to clear the gitfs cache without restarting the master every time?
09:49 babilen AxelFooley: No, you don't. Just wait or run "salt-run fileserver.update"
09:49 lkthomas different  Satellite server will contain different files that need to do checksum
09:49 jalaziz joined #salt
09:49 AxelFooley babilen: thanks you a lot
09:49 lkthomas but it's all consolidated into core server
09:49 AxelFooley babilen: thank you a lot
09:49 jalaziz_ joined #salt
09:50 wnkz_ joined #salt
09:50 lkthomas after checksum complete (Assume without mismatch, if mismatch, trigger alert), then do second step of whatever it needs to run
09:51 babilen So you want to run a command on all boxes, gather their results and then perform two different actions based on the result?
09:52 babilen lkthomas: That is, typically, not really how saltstack works. You should rather adopt an approach in which you describe the state that you want to achieve rather than to describe in detail which actions should happen in certain situations.
09:53 lkthomas I know, I want you know in detail of what I am trying to do
09:53 lkthomas so back to my question, can I program all logic in bash and combine MD5sum result fetching using saltstack ?
09:54 xsteadfastx joined #salt
09:55 babilen lkthomas: You would rather implement that in Jinja/Python (or any of the other renderers) and use orchestrate. What I was trying to say was: Rather then checking if the md5sum is the same on all, why don't you simply use salt to *ensure* that they are all the same. You have, presumably, some way of "updating" your boxes and I wonder why you don't simply ensure that they are all up-to-date
09:57 lkthomas babilen, those files changing everyday
09:57 lkthomas babilen, filename change based on date
09:57 lkthomas use salt to ensure they are all the same <- how ?!
09:58 sashka_ua joined #salt
09:58 babilen Are you simply looking for a way to automatically trigger an alert if the md5sums don't match?
09:59 lkthomas babilen, big picture, yes
09:59 lkthomas or trigger file retransfer
09:59 lkthomas whatever action I want to do
10:00 babilen Why don't you trigger "file retransfer" all the time *unless* the md5sum is different? You do, presumably, have some reference implementation that you want to achieve?
10:00 babilen s/different/identical/ -- :)
10:04 Emantor joined #salt
10:05 ramishra joined #salt
10:11 N-Mi_ joined #salt
10:12 lkthomas babilen, it's not solving my concern, we need to at which point md5sum doesn't match
10:12 lkthomas babilen, how is these steps related with saltstack ?
10:12 lkthomas I know I could run everything on bash, but it's not scalable
10:13 lkthomas so how should I compare md5sum on saltstack ?
10:17 babilen lkthomas: You could maintain the md5sums in the salt.mine and then use orchestrate, possibly written in Python, to run the "upgrade job" whenever the list of unique md5sums contains more than one element.
10:18 babilen All I am saying is: Why don't you simply run the "enforce correct md5sums" action to begin with?
10:18 lkthomas what do you mean by enforce correct?
10:18 lkthomas is it done on saltstack level or bash level ?
10:19 __gotcha joined #salt
10:19 babilen You do, presumably, have some command that you use to "synchronise files" that you run whenever you find that the md5sums don't match. Why don't you run that to begin with regardless of the md5sum state?
10:20 lkthomas babilen, your logic having issue, what if it keeps failing ?
10:20 babilen And, anyway, why do you care about md5sums and file comparisons anyway? Can't you use some shared storage or a repository that you checkout or *something along those lines* to ensure that you have the correct data on your boxes?
10:20 lkthomas babilen, no, that's our business requirement
10:21 babilen Your business requirement is to do this in an awkward way?
10:21 lkthomas babilen, I don't define the rule, my job is to find solution dude
10:22 babilen So, what do you do when the md5sums don't match? What do you do when that fails?
10:22 lkthomas md5sum don't match, and it will need to try and send out alert
10:24 babilen you might be able to write a returner that does that, but I cannot give any more advice. My impression is that you are doing something weird and ill defined and that it is therefore impossible to implement it. (or advise on good ways to achieve that)
10:25 babilen You typically have some goal that you want to achieve (e.g. "file /path/to/something is the same on all boxes") and you would implement *that* with salt
10:26 babilen Maybe it helps if you were to write a mail to the salt-users mailing list with all the details you deem important and a clear statement of "I want to do ...".
10:27 lkthomas anyway, let's see who else have similar experience which could share a bit later on
10:27 lkthomas time to go home
10:27 lkthomas brb
10:29 Reiner0316 joined #salt
10:30 AxelFooley joined #salt
10:38 ramishra joined #salt
10:45 catsinsofas lkthomas, you dont have to manually do the md5sums when you use salt
10:45 catsinsofas you just tell it what files you want where and it takes care of such things
10:47 babilen .. but that's not their "business requirement"
10:47 catsinsofas babilen, thats not a business requirement ^^
10:48 diegows joined #salt
10:48 giantlock joined #salt
10:49 babilen Apparently, for some reason that is beyond me, this has to be based on md5sum comparisons and cannot be achieved simply by making sure that the latest (or a specific) version of $SOMETHING is available on all minions
10:51 lkthomas catsinsofas, how does saltstack handle md5sum value compare ?
10:52 viq lkthomas: sounds like you want HIDS like OSSEC or samhain or tripwire, not necessarily CM tool like salt
10:52 catsinsofas lkthomas, i assume it uses python's md5sum lib
10:52 catsinsofas but it doesnt matter
10:52 lkthomas viq, no, it's not for security  reason
10:52 jalaziz joined #salt
10:53 lkthomas catsinsofas, how would you do to take return from each md5sum and compare ?
10:53 catsinsofas lkthomas, srsly, that's an implementation detail. not a business requirement. the business requirement is broken
10:53 catsinsofas i wouldnt
10:53 catsinsofas i would tell business to stop being morons and let me do my job
10:53 catsinsofas sorry..
10:53 viq lkthomas: then could you again explain what exactly problem are you trying to solve?
10:54 lkthomas I have multiple servers generate data daily, and will ftp transfer to core server
10:54 babilen (round and round in circles)
10:54 catsinsofas and i agree with the others that this isnt a task for salt
10:54 catsinsofas lkthomas, hold on, you worry about security and you use FTP?
10:54 babilen heh
10:54 lkthomas I want to ensure transfer data would be same after transfer
10:55 catsinsofas no offense but tell your business side to remove their heads from their rear ends and let you do your job. they should do theirs, which is, dunno, whatever your company does. it is *NOT* their job to tell you how to compare files
10:55 viq lkthomas: kind of simplest solution - why not upload a checksum together with the data?
10:55 catsinsofas good idea
10:55 lkthomas viq, do it before or after doesn't matter
10:56 catsinsofas simple, obvious, easy to document
10:56 viq lkthomas: no, generate the checksum on uploader, upload it together with the data, check checksum on target
10:56 * babilen is glad that lkthomas finally specified the actual problem
10:56 catsinsofas hehe
10:56 catsinsofas yep
10:57 catsinsofas security and FTP.. i cannot believe it
10:57 catsinsofas sorry </ot> </rant> ;)
10:58 viq catsinsofas: TBH I don't think he mentioned security at any point
10:58 mietki joined #salt
10:58 babilen "11:52:49 lkthomas > viq, no, it's not for security  reason"
10:59 __gotcha joined #salt
10:59 lkthomas sounds like in my case, other than restarting service in massive clusters, nothing else would be useful
10:59 viq lkthomas: hm?
10:59 lkthomas then I don't know what exactly does saltstack use for
10:59 viq babilen: yes, that's a negation of security concerns
11:00 mietki babilen: several days ago you offered me learning virtual machines for saltstack
11:00 babilen mietki: Yes, one second please.
11:00 mietki have you got the exposed somewhere? :)
11:00 viq lkthomas: make sure that your servers have same, desired configuration all over them. Run updates on them. Run commands on them. Simplest examples.
11:00 lkthomas viq, I already have puppet deployed
11:01 babilen mietki: I'll prepare a gist
11:01 mietki great :)
11:01 viq lkthomas: and if you have mcollective too, and you're happy with it, then there indeed may not be any need to switch to salt. Use whatever works for you.
11:02 lkthomas mcollective have a steep learning curve
11:02 lkthomas I find salt is easy to use
11:02 lkthomas easier to implement within bash
11:02 viq Yes, salt is easy to use. So use it in a way that works for you.
11:03 lkthomas for orchestration, so second step after md5sum is the same, then start some execution
11:03 bhosmer joined #salt
11:03 lkthomas I am not sure where does salt will fit, but somehow a program will need to wait for md5sum confirmation before execute second step
11:04 lkthomas maybe salt could store and compare value first and trigger another action ?
11:04 viq From what you're saying it sounds like the only part you want to use salt for is to reach to machines and execute commands - therefore you will have to have all your logic in your bash script.
11:04 catsinsofas lkthomas, you realise what you're asking is also the entire point of rsync..
11:05 catsinsofas why do you want to use totally unsuitable tasks for this tool?
11:05 catsinsofas use a *TWO COMMAND* bash script or rsync...
11:05 catsinsofas *tools for this task
11:05 lkthomas catsinsofas, then why do you need saltstack ? use ssh shared key and execute command via ssh
11:06 catsinsofas lkthomas, i'm not stupid, i dont use salt as a ssh-replacement
11:06 catsinsofas and it's not shared key..
11:06 viq lkthomas: it sounds like it would be possibly the best solution for you actually, since you don't want to put logic within salt.
11:06 catsinsofas i mean ssh. that doesn't use shared keys
11:06 lkthomas catsinsofas, you are self-contradict, everything you are doing could be done via ssh
11:06 viq catsinsofas: shared keys?
11:07 catsinsofas i use salt as a configuration management tool. that's what it is designed for. that's what it's good for
11:07 viq Well, it did start out as a remote execution tool...
11:07 lkthomas catsinsofas, why not use rsync to sync up all config file using share key via ssh then ?
11:07 catsinsofas lkthomas, sorry but cba with your trolling /ignore
11:07 viq lkthomas: because salt has conditionals and templates, for one
11:07 lkthomas catsinsofas, I am more welcome if you could ignore me, please
11:08 lkthomas viq, that's exactly I am looking for
11:08 lkthomas but I haven't seen anyone mention something close to that
11:08 lkthomas put it this way, I am actually planning to deploy execution server
11:08 viq lkthomas: but for that you need to work within salt, not wrap it with bash scripts
11:08 lkthomas which means, all execution will consolidated into single platform and fire from here
11:08 lkthomas viq, within salt = python ?
11:09 viq well, mostly yaml and jinja, though you could use python instead
11:09 lkthomas yaml is easy to understand
11:10 lkthomas but it's for parameter setting right ?
11:10 viq ..ish. Puppet has it's DSL, salt uses YAML
11:10 lkthomas http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html
11:10 lkthomas like this ?
11:11 viq yeah
11:11 lkthomas LOL
11:11 lkthomas 10 times easier compare with MCollective
11:11 lkthomas which is ruby
11:12 lkthomas viq, you do notice the syntax is close to bash right ?
11:12 viq jinja? Not quite
11:13 lkthomas so the language itself is good. How does it work together with salt ?
11:14 viq rephrase/elaborate, as I don't know what you're asking
11:16 lkthomas in my case, if I want to use salt.modules.file.check_hash with jinja as renders to compare result, how would it go together ?
11:17 viq http://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html
11:17 johtso joined #salt
11:18 lkthomas viq, I know how to execute one command and get result, how to run logic with multiple results ?!
11:18 viq states, orchestration, possibly custom module.
11:19 viq Maybe reactor.
11:20 viq possibly publish could be used for that.
11:22 lkthomas I will have a look later
11:22 lkthomas thanks
11:22 lkthomas at least now I know I need to use state = file
11:22 lkthomas brb
11:30 paull1953 joined #salt
11:37 mohae_ joined #salt
11:44 linjan joined #salt
11:47 paull1953 joined #salt
11:51 fredvd joined #salt
11:51 __gotcha joined #salt
11:58 TTimo joined #salt
12:02 Neco_ joined #salt
12:03 Neco_ hello, anyone use the salt minion on Windows and manage windows update with it? Can't get win_update.* to work, it's not recognized even after sync_all and all that
12:03 aqua^mac joined #salt
12:04 viq Neco_: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.win_update.html  ?
12:04 viq Neco_: which version of salt are you using?
12:05 hobakill joined #salt
12:05 Neco_ salt 2014.7.0 (Helium) but 2014.1.13 I think on the minion, I can get the master to the latest as well
12:05 Neco_ but when I had them both at the same version I didn't even have win_update.py in the modules directory on the master
12:06 viq Neco_: you need to have both on 2014.7
12:06 madduck joined #salt
12:06 Neco_ ah
12:06 Neco_ but the manual build instructions lead to 404 links so I can't build it on windows sadly
12:06 Neco_ or rather I gave up at that point
12:07 viq you maybe possibly could get away with controlling 2014.7 minion with 2014.1 master, but it's the minion that does the work, and has to know how to do what you ask it to
12:08 Neco_ on the docs site it lists the latest release as 2014.1.13
12:08 viq http://docs.saltstack.com/downloads/ has RC7 packages
12:08 Neco_ oh
12:08 Neco_ neat
12:08 viq yeah, 2014.7 hasn't been announced yet, they ususally do that once the packages have been built
12:08 Neco_ ah
12:08 Neco_ makes sense
12:10 Neco_ then I wasn't going crazy
12:10 viq Dunno, you are using windows after all ;)
12:11 shorty_mu viq: Funny thing is in CentOS 7.0 EPEL Helium arrived today.
12:11 viq oh, interesting
12:12 viq When I checked EPEL 6 couple hours ago it wasn't there, neither is it in wheezy repos
12:12 shorty_mu More like confusing...
12:12 shorty_mu Right, not in 6.0 EPEL
12:12 joehh viq: check the wheezy-tessting repo...
12:13 Neco_ well I want to script away all my mindnumbing windows update jobs
12:13 Neco_ s/script/manage/
12:13 babilen viq: it's in wheezy testing
12:13 viq Neco_: yeah, certainly can understand that. I just tend to stay away from windows
12:13 babilen (saltstack repos)
12:14 viq Right. Though I don't think I'll enable testing repos on my production boxes
12:14 babilen no, surely not
12:14 shorty_mu +1 ;)
12:14 viq But it's good to know if I'll find a while to try out in a lab the pillar merging
12:15 viq As I've seen 2014.7 in epel-testing as well
12:15 babilen I sort of regret not using wheezy-saltstack-2014-01 repositories as that would have allowed me to switch when i want to. I might roll that out beforehand. It will, however, not help in the case a colleague decides to install a new minion by following http://docs.saltstack.com/en/latest/topics/installation/debian.html
12:16 aqua^mac joined #salt
12:16 Neco_ Windows-Test: Windows is up to date.
12:16 Neco_ yay \o/
12:16 viq Neco_: cool :)
12:17 Neco_ last example on http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.win_update.html#module-salt.modules.win_update is missing some quotes as well...
12:20 hobakill good morning/afternoon all. i have a minion with 2014.7.0 that is not reporting back to a master that's at 2014.1.13. "manage.status" shows as down and it's not responding to pings. I know i should have the master at the same or a higher version of salt than the minions but i'm surprised as this hasn't been an issue before. the box in question is a non-production test box but still.... is this expected behavior?
12:20 __gotcha1 joined #salt
12:20 babilen hobakill: You have to ensure that $MASTER_VERSION >= $MINION_VERSION
12:21 hobakill babilen: figured. thanks.
12:21 babilen (and the range shouldn't be too large, preferably you want both versions to be identical)
12:21 babilen But a newer minion than master is definitely not supported
12:22 hobakill babilen: yeah the minion is pulling from EPEL testing where as the master and all the other minions pull from normal EPEL. i just feel like i've had master < minion before and it wasn't an issue. not a big deal. thank again babilen
12:23 babilen Well, it *can* work, but it is definitely not supported.
12:23 babilen Nobody intentionally breaks that :D
12:23 hobakill speaking of which it would be nice if 2014.7.0 got out of the testing repo ... ./........
12:23 hobakill of course . :)
12:23 babilen I dread that day
12:24 hobakill why's that?
12:24 bhosmer joined #salt
12:24 ThomasJ Seems to work ok-ish here. Didn't pin the version and the debian packages (master) has not been pushed yet while many of the minions are on Centos7 which do have the packages pushed
12:24 babilen Because I fear that everything will be broken and that we will discover a bunch of horrible bugs.
12:24 babilen So, I kindly let you guys upgrade first ;)
12:25 hobakill sounds fair!
12:25 joehh a few times :)
12:25 * Shish looks forward to the release of 2014.7.1 :P
12:25 joehh 2014.7.7 :)
12:26 ThomasJ By 2020.1.0 we will have salt world domination with salt master having AI
12:26 babilen Like everyone else I am really looking forward to finally getting my hand on the new features, but I value a running/usable system over $NEW_TOYS. I guess it will become clear pretty fast if .0 is a release one can deploy or not.
12:34 ramishra joined #salt
12:36 ramishra_ joined #salt
12:37 williamthekid joined #salt
12:49 bhosmer joined #salt
12:50 TTimo joined #salt
12:52 bhosmer_ joined #salt
12:53 dooshtuRabbit1 joined #salt
12:55 jbub joined #salt
12:55 thayne joined #salt
12:56 __gotcha joined #salt
12:57 trikke joined #salt
12:59 ramishra joined #salt
12:59 jalaziz joined #salt
12:59 AxelFooley joined #salt
13:00 thawes joined #salt
13:06 __gotcha1 joined #salt
13:07 ajolo joined #salt
13:08 intellix joined #salt
13:11 wincus joined #salt
13:11 ramishra joined #salt
13:31 thawes joined #salt
13:36 CeBe joined #salt
13:38 ramishra joined #salt
13:44 tligda joined #salt
13:53 ramishra joined #salt
13:55 tmh1999 joined #salt
13:56 nebuchad` joined #salt
13:57 lahwran joined #salt
13:58 sumpos are there any good (preferably well commented) examples of complete salt setups that I can browse through? There's lots of examples of specific states, but I can't find much that integrates everything including the pillar files with servers.
13:59 sumpos basically, I'm looking for a salt "best practices" example - complete (though with dummy server information, obviously)
13:59 ramteid joined #salt
13:59 cpowell joined #salt
14:00 sumpos I'm struggling a bit to understand how to reference server groups within a template file, and think I might be looking at it wrong - in the more "ansible" way
14:00 __gotcha joined #salt
14:00 viq sumpos: what exactly?
14:02 GnuLxUsr joined #salt
14:03 ramishra joined #salt
14:03 viq sumpos: it seems to be one of those tools where there are (too?) many things to do anything. Your mention of server groups makes me mostly think of top.sls, and there I usually match by names or grains.
14:04 viq As for an extensive example, here's one I looked up some things on https://github.com/jesusaurus/hpcs-salt-state/
14:04 ThomasJ nodegroups/compound matchers are probably what you want, and I do believe you can use them in templates as-well if memory serves
14:05 lcavassa joined #salt
14:06 TTimo joined #salt
14:06 ndrei joined #salt
14:06 viq as in withing a file.managed template: jinja  ?
14:07 saravanans joined #salt
14:08 gngsk joined #salt
14:08 tligda joined #salt
14:08 sumpos viq: yeah, top.sls seems to work the other way - you're telling salt what states to run on certain hosts. In ansible you split all your hosts into groups in an ini file. So, if I have a group called "desktop", I can reference that from a template. You also have tags, and endless other ways of achieving the same thing. Salt is a little more straightforward and less frustrating, but there's still a lot of options
14:09 sumpos a lot of ways of achieving the same thing - hence the importance of carefully studying a "best practices" case study - if such a thing exists
14:09 sumpos preferably a fairly complex one
14:09 sumpos I'm having a look at the jesusaurus (giggles) github - thanks
14:10 mdasilva joined #salt
14:11 sumpos I think I need to pass the variables in pillars. I've just reached that sort of plateau in going through the docs where there's more information than I can absorb and I want to start learning by doing practical things
14:11 peters-tx joined #salt
14:11 viq TIMTOWTDI ;)
14:12 viq Though if you have specific question I'm certain you can get a plethora of answers here and on the lists ;)
14:13 sumpos basically in my .profile jinja template file I already have certain conditionals set for matching grain information, but I also want to have conditionals that match whether or not a server is in a particular group that I define - e.g. public, private
14:13 viq I would put that in grain
14:14 gmcwhistler joined #salt
14:14 sumpos yeah, TIMTOWTDI - which is the nature of configuration management, so I'm not complaining, I'd just like to see a working example of someone's whole /srv/salt directory - someone who knows the pitfalls and how to avoid them
14:14 viq For example we put in grains what client the server belongs to, or what's the update policy
14:16 sumpos you mean in a pillar? I thought the term "grain" was exclusively for the information gleaned by salt from the server itself
14:16 mdasilva morning all
14:16 viq No, you can set grains yourself
14:16 sumpos oh wait, you mean you put that information in a file on the minion?
14:16 viq One pitfall that requires some thinking to get around is that you can't reference pillars from pillars
14:16 viq sumpos: well, that's where they end up, but I set them via states
14:17 jaimed joined #salt
14:18 viq http://docs.saltstack.com/en/latest/ref/states/all/salt.states.grains.html
14:20 viq Another thing that the new release solves, is that if you tried to assign values to same pillar from different files, the latter would overwrite the former.
14:20 viq Well, those are the pitfalls I know of and encoutered, but admittedly my use of salt is not very exciting
14:20 sumpos viq: ok, cool, that makes sense. So you have a state.sls file that sets all extra grains on each box. Makes sense.
14:21 viq Or grains.client.clientA and grains.client.clientB and grains.updates.immediate and grains.updates.contact etc
14:21 iwishiwerearobot joined #salt
14:21 viq And assign those states as appropriate
14:22 toastedpenguin joined #salt
14:24 genediazjr joined #salt
14:25 mpanetta joined #salt
14:28 saravanans left #salt
14:28 primechuck joined #salt
14:30 TTimo joined #salt
14:34 rojem joined #salt
14:35 racooper joined #salt
14:37 babilen With 2014.7.* I'd like to keep my pillar in the same repository as my states (and use the gpg renderer for sensitive data). Are there any best practices regarding this that I should be aware of? Would you use _pillar as root?
14:39 miqui joined #salt
14:39 Deevolution joined #salt
14:41 bhosmer joined #salt
14:41 rojem joined #salt
14:41 ramishra joined #salt
14:42 prosper_ joined #salt
14:43 alanpearce joined #salt
14:44 thedodd joined #salt
14:45 viq sumpos: also I don't know how "best practices" it is, but I'm somewhat following https://github.com/Akilesh1597/salt-openstack
14:47 rojem joined #salt
14:49 _prime_ left #salt
14:49 _prime_ joined #salt
14:49 KaaK joined #salt
14:50 babilen Ah, not a bad idea either.
14:51 viq erm, I guess the URL should have been https://github.com/CSSCorp/openstack-automation
14:51 babilen yeah, adopted
14:51 babilen (I have my uncreative hour)
14:53 prosper_ joined #salt
14:55 viq joined #salt
14:55 viq joined #salt
14:56 babilen I wonder if the salt-formula supports per-remote configuration parameters already
14:56 babilen It does \o/
14:57 housl joined #salt
14:58 teebes joined #salt
15:00 favadi_ joined #salt
15:01 babilen to raet or not to raet?
15:02 mbrgm joined #salt
15:03 mbrgm what does the
15:03 mbrgm sry...
15:04 mbrgm what does the `salt` command connect to? the unix socket? could it also connect via a tcp socket? my goal is to invoke the `salt` command from a host different to the host running the salt-master _without_ ssh'ing or otherwise logging into the host. is this even possible?
15:04 mbrgm different from*
15:04 viq mbrgm: look up salt-api
15:08 dude051 joined #salt
15:09 mbrgm viq: I scanned the docs for salt-api, but it seemed to me that it was a way for setting up remote APIs, such like a REST API. can I also use it to work directly with the `salt` command from a remote host?
15:09 Neco_ just add ssh infront of it? unless you are gonna create your own framework
15:10 Neco_ ssh host sudo salt herp.derp
15:10 perfectsine joined #salt
15:10 whiteinge mbrgm: pepper may fit that bill (which uses the REST API) https://github.com/saltstack/pepper
15:10 mpanetta Wow, that openstack formula is intense
15:11 mpanetta huge even :P
15:11 mpanetta Very cool to learn from I think.
15:11 mbrgm Neco_: I thought of that way, however, was looking for a way to do it without SSH, so that I could have a docker container running salt-master and another one running sshd. I'd then connect to the sshd container, but to work with salt, I'd somehow have to connect those two.
15:12 mbrgm whiteinge: pepper looks promising. I will have a look at it. ty!
15:15 mgw joined #salt
15:15 srage joined #salt
15:17 ramishra joined #salt
15:19 hobakill left #salt
15:20 babilen Hmm, one problem I run into when using the gpg renderer is that I would have to make the private gpg key available locally if I want to test my setup in vagrant. I don't really like the idea of having that key on all boxes, but without it the locally running (test) master wouldn't be able to decrypt the gpg encrypted data.
15:21 babilen Any good ideas on how to deal with this? I like that other developers will be able to just use the *public* key and I plan to keep that one in the repo, but in order to test it the master needs the private one.
15:21 babilen I don't really want the pair to leave the master
15:21 * iggy shakes his head at another person trying to shoehorn things into containers when they don't fit
15:22 mpanetta iggy: But, DOCKER!!!11!!!
15:22 babilen me?
15:22 babilen Ah, *phew*
15:22 viq babilen: have a script or something that re-encrypts with all the minions' keys?
15:23 mpanetta Is there any way to get a list of available states on a master?
15:23 babilen I can't really get around the need to have the unencrypted key locally if I want to decrypt that data ...
15:23 babilen mpanetta: there is
15:23 iggy cp.list_master
15:23 iggy is a very heavy-handed way
15:23 mpanetta Hm
15:24 babilen I'm never sure if it is cp.list_master or cp.master_list or fileserver.refresh_pillar or fileserver.pillar_refresh or ...
15:24 mpanetta haha the pillar one gets me all the time
15:24 babilen I just use ^Rrefresh to search for the last call these days ;)
15:25 pacopablo joined #salt
15:25 mpanetta yep!
15:25 mpanetta wow damn cp.list_master lists *everything*
15:25 mpanetta Including my .git folder...
15:25 babilen https://www.youtube.com/watch?v=74BzSTQCl_c
15:25 iggy I _did_ say it was heavy-handed
15:26 mpanetta I take it cp.list_master is a file listing?
15:26 mpanetta You did :)
15:26 Jellyfrog joined #salt
15:26 iggy it is a file listing
15:26 iggy there's also cp.list_states
15:26 iggy never used it, so I don't know what it is
15:26 jbub joined #salt
15:27 n8n joined #salt
15:27 nitti joined #salt
15:27 mpanetta iggy: Apparently what it says it is.  It is definitely listing only states...
15:30 thayne joined #salt
15:31 mdasilva ive switched pygit2 for my gitfs_remotes but im receiving a GitError: This transport isn't implemented. Sorry error.  Its the same SSH url that is working successfully for my pillar remotes.  any ideas?
15:31 mdasilva tia
15:33 linjan joined #salt
15:34 kaptk2 joined #salt
15:35 n8n joined #salt
15:35 iggy mdasilva: what version of salt?
15:36 mbrgm joined #salt
15:36 alanpearce joined #salt
15:36 mdasilva salt 2014.7.0rc6 (Helium)
15:36 iggy do you have all the required dependencies?
15:37 iggy also... pillar remotes are handled by _completely_ different code than gitfs
15:37 tmh1999 joined #salt
15:38 mdasilva yeah i was using pygit2 with https authentication prior
15:39 mdasilva had some issues with flaky syncing so decided to go ssh instead to see if that would help
15:39 mdasilva yeah i figure the pillar remotes use different logic.. thats been working very well
15:39 ajolo joined #salt
15:42 ramishra joined #salt
15:44 stooj joined #salt
15:44 seydu joined #salt
15:44 pdayton joined #salt
15:48 genediazjr joined #salt
15:50 bhosmer joined #salt
15:52 KaaK if the hostname on a minion is changed, will its ID also change?
15:52 viq KaaK: no
15:53 KaaK viq, thanks
15:53 viq KaaK: /etc/salt/minion_id
15:55 alexhayes joined #salt
15:55 ghanima joined #salt
15:55 asyncsrc joined #salt
15:56 thayne joined #salt
15:57 asyncsrc Hi there.  I was wondering if anyone has experienced an issue where you have a managed file that you want created on a remote machine, but instead of the file being copied over, it creates a directory name with that filename instead? It seems like a bug in the version of salt I'm using, but I'm not 100% sure
15:58 viq asyncsrc: paste your state somewhere, and which version of salt are you using?
15:59 conan_the_destro joined #salt
15:59 asyncsrc Will do.  Using version salt 2014.7.0 (Helium)
15:59 asyncsrc http://pastie.org/9714628
16:00 viq and I assume you're talking about line 13 ?
16:00 b1nar1 joined #salt
16:00 asyncsrc at location /root/geolocation_old_queue_debug/ instead of a local_settings.py file being created as a file, it creates a new folder called local_settings.py/  -- exactly viq
16:01 viq asyncsrc: and salt://docker/geolocation/{{ local_settings }}/local_settings.py
16:01 asyncsrc thanks for your help looking at this.  I really appreciate it
16:01 viq is a file, yes ?
16:02 asyncsrc that's correct.  here's stdout of an ls + cat http://pastie.org/9714633
16:02 thayne joined #salt
16:04 n8n joined #salt
16:04 viq asyncsrc: try moving require from file.directory to file.managed, see what happens?
16:05 iggy or just take it out... top-down
16:05 asyncsrc okay, i have it removed.  I'll give it another whirl.  one sec
16:06 iggy one thing I'd do in this case (just as a data point) would be to comment out the whole file.managed state and see what the file.directory state does on it's own, then add it back in
16:07 asyncsrc okay I removed the /root/geolocation_old_queue_debug folder completely and re-ran the salt state, and unfortunately it's still creating the folder, oddly enough.  I'll try that, iggy.
16:07 viq Also you can add makedirs: True to file.managed
16:08 iggy ^
16:08 viq http://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.managed for all available options
16:08 asyncsrc okay after removing file.managed, it does appear it's creating a local_settings.py folder underneath it
16:08 iggy that's probably the cleanest fix (I like short and concise)
16:08 SheetiS joined #salt
16:08 felskrone joined #salt
16:09 linjan joined #salt
16:09 Ozack1 joined #salt
16:09 asyncsrc thank you.  I agree I like the shorter approach.  I'm not entirely sure why it would be creating a local_settings.py folder underneath it, given the code I pasted.  Is there an easy way to output the value of a jinja template variable without using the show_all_context() function within the state file?
16:10 asyncsrc I'm not sure if /root/{{geolocation}} would have something other than what I'm setting it to at the top of the file, but I don't really have another explanation for what might be happening
16:11 iggy if it had something else, the set at the top of the file would be overwriting it (unless you aren't showing us the whole state file, in which case... shame on you)
16:13 asyncsrc well, I can send it to you.  I just didn't find it relevant ;)  shame on me indeed.  actually I think perhaps it was code that I didn't paste.  http://pastie.org/9714659 I'm guessing doing the docker -binds section might be doing it
16:13 bersace Hi, is it possible to use pillar values in other pillar sls files ?
16:13 viq bersace: no
16:13 iggy not consistently
16:14 bersace that's fair :-)
16:14 iggy you can sometimes rely on inheritance/merging
16:14 iggy but even that is documented as being "non-deterministic"
16:16 bersace thanks
16:16 perfectsine joined #salt
16:16 kermit joined #salt
16:22 ghanima joined #salt
16:24 UtahDave joined #salt
16:25 quickdry21 joined #salt
16:28 genediazjr joined #salt
16:29 KaaK is there any way to decommission a minion via a single command? Or do you have to just purge out the keys?
16:30 bhosmer_ joined #salt
16:30 iggy manage.$something
16:30 StDiluted joined #salt
16:30 viq define "decommission"
16:31 iggy salt-run manage.down removekeys=True
16:31 iggy but read the docs first
16:32 iggy because that too is a bit heavy handed
16:33 hasues joined #salt
16:36 ale__ joined #salt
16:38 sylphid joined #salt
16:39 mbrgm joined #salt
16:44 hasues left #salt
16:44 cleme1mp joined #salt
16:45 druonysus joined #salt
16:45 druonysus joined #salt
16:46 tligda joined #salt
16:47 rypeck joined #salt
16:49 n8n joined #salt
16:49 sylphid joehh: got a 2014.7.0 deb question for you (assuming you are the correct person to talk to about it), should the python-urllib3 bpo70 debs be included in the repo to fulfill the dep requirements for requests?
16:50 masterkorp Are there any guidelines on releasing tags on saltstack-formulas formulas ?
16:52 UtahDave masterkorp: I don't think we have anything official.  I think that for now, if you're helping manage a formula feel free to add a tag when it makes senese.
16:52 UtahDave sense
16:53 UtahDave coordinate with anyone else that has been helping manage it.
16:53 UtahDave I'd like to formalize that a little bit as the formulas become more mature and we see what works.
16:53 UtahDave thoughts, masterkorp?
16:59 masterkorp UtahDave: i am maintaing the influxdb-formula currently
16:59 masterkorp i love semver
17:00 masterkorp there is not reason we cannot employ it on formulas
17:01 mbrgm joined #salt
17:01 UtahDave masterkorp: I'm totally down with that. Let's start with your influxdb-formula and see how it goes.
17:03 iggy masterkorp: we're working on getting a formulas list (to have these kinds of discussions)
17:03 SheetiS Would be nice to know when a change is backwards incompatible on formulas and semver accounts for that.  I think this would be an overall plus.
17:03 iggy and bug 12179 may be of interest
17:03 UtahDave iggy: Oh yeah. let me check on that.
17:03 SheetiS I'd love to be on a formulas list if/when there is one.
17:04 saravanans joined #salt
17:04 masterkorp iggy: I've read the thread
17:04 masterkorp its a +1 from my part obviously
17:04 iggy cool, that's the other thing I was looking for
17:04 viq SheetiS: I believe there already is one, I already subscribed ;)
17:05 ndrei joined #salt
17:05 SheetiS viq: able to point me to it? ;-)
17:06 iggy I'm not sure how I feel about someone outside of salt being in charge of it, but I suppose I'll roll with it for now
17:06 iggy https://groups.google.com/forum/#!forum/salt-formulas
17:07 UtahDave iggy: I've asked to be made an owner of it.
17:07 masterkorp iggy: cool
17:08 masterkorp when its official, it should be announced on the official salt-users
17:08 smcquay joined #salt
17:08 UtahDave Yeah, good idea. I'll do that as soon as I get that sorted out.
17:08 KyleG joined #salt
17:08 KyleG joined #salt
17:09 masterkorp Cool tip, for non Google email users, the way to subscribe its to use salt-formulas+subscribe@googlegroups.com
17:10 SheetiS you mean all people don't at least have a throw-away google account?  I didn't realize that was possible :P
17:10 viq XDb
17:10 viq erm, wrong window
17:11 wendall911 joined #salt
17:14 elfixit joined #salt
17:16 zlhgo joined #salt
17:16 masterkorp SheetiS: i have, you just don't use it to read the mailing lists
17:17 * masterkorp has his own postfix server
17:17 felskrone joined #salt
17:17 SheetiS masterkorp: I was just kidding anyhow ;-).
17:17 viq speaking of email, we just got spam from address zombie-harassment-example@jedstock.com
17:17 masterkorp SheetiS: i was just showing my chest hair :p
17:18 mpanetta viq: At least they were semi-creative...
17:18 viq and amusing ;)
17:18 viq anyway, I'm off
17:18 mpanetta Oh?  Is the message contents just as amusing as the address? heh
17:19 mpanetta see ya viq
17:19 SheetiS I'm actually glad I am not responsible for any postfix servers anymore.  Lot of extra work back in my isp admin days that I'm glad is off the table.
17:19 thedodd joined #salt
17:22 aparsons joined #salt
17:29 repl1cant "isp admin days" *fist bump*
17:29 cpt-oblivious joined #salt
17:29 cpt-oblivious joined #salt
17:30 * dork loves postfix personally
17:32 repl1cant i was a dan bernstein fan boy back in the day, so ya ... qmail ;-)
17:32 skyler I have a postfix server, and it is working fine for me, but I haven't had to do anything beyond configuring it with salt.
17:33 dork postfix/amavisd-new/clamd/SA w/ bayesian on postfix make great smart hosts. i replace barracudas with that stack with serious prejudice
17:33 troyready joined #salt
17:34 SheetiS1 joined #salt
17:35 beneggett joined #salt
17:37 skyler iggy: Nice summary on the formulas mailing list. I think that covers the discussion pretty well.
17:38 babilen iggy: thanks for the summary!
17:39 babilen I think it is time to spent some quality time on best practices (which is quite inconsistent)
17:40 g4rlic joined #salt
17:40 babilen Does anybody know if saltstack have an internal style guide that we might be able to get our hands on?
17:40 desposo joined #salt
17:40 dlam joined #salt
17:41 iggy I think that question was asked the other day and utahdave said no
17:41 iggy but then, that's all python code
17:41 iggy so it has it's own style guides etc
17:41 SheetiS1 Possibly look at extending/updating http://docs.saltstack.com/en/latest/topics/best_practices.html
17:41 iggy we are talking about 95% yaml+jinja
17:42 iggy (which is also one of the reasons I think pypi is a terrible method for deploying formulas)
17:42 babilen SheetiS1: yeah, that one definitely needs some love, but I was thinking about something a bit more terse (something like http://google-styleguide.googlecode.com/svn/trunk/pyguide.html)
17:43 babilen iggy: yeah, it really doesn't make sense to put them in the cheeseshop
17:43 iggy python has a few (pep8, etc)
17:43 iggy there are some things we can probably pull from yaml docs
17:44 babilen I'm just not opinionated enough (yet) to draft a document in toto
17:44 iggy it would be really nice if salt had a way to output the rendered yaml files (to do yaml linting at least)
17:45 * babilen nods
17:45 iggy or write a yaml linter that understood jinja (which sounds like a pita)
17:45 SheetiS I think stylization of yaml itself is easy (indent 2 spaces... profit).   It's merging that stylization with Jinja that gets messier.
17:45 iggy yeah, I definitely wasn't insinuating that's the only style guildlines we should have
17:45 SheetiS and the jinja lint would have to be able to import all the salt modules and read the pillar, etc
17:46 spookah joined #salt
17:46 iggy I think we'd be better off picking 5-10 formulas that everybody likes and then boiling their features down into something that can be written out
17:47 babilen SheetiS: Well, I am thinking about state naming conventions. Ways to implement defaults in formulas (e.g. use a macro with defaults in map.jinja/defaults.jinja, call pillar.get('some:pillar', default_val), ...), the need to adhere to best practices and formula conventions (and what they are in a nutshell), ...
17:47 babilen iggy: Agreed
17:47 iggy I was reading the graphite formula earlier... I used to like it... now I want to rewrite half of it
17:48 SheetiS babilen: I definitely agree there.  I also think defaults should be in some type of defaults.jinja for the cleanest look of things.
17:48 g4rlic iggy: salt-call -l debug will show yaml with jinja rendered.
17:49 SheetiS There are some real simple things that could _really_ improve formulas (e.g. if you wrote your formula so that it requires yum or apt directly, it's probably not the right way to handle it.)
17:49 wnkz_ joined #salt
17:50 KaaK can I do jinja template imports from pillar sls files?
17:50 MrFuzz joined #salt
17:50 iggy and at some point we could have an example-formula that someone can copy and it already has all this stuff in it: map.jinja, defaults.jinja, README.md with all the sections (dependencies, etc.)
17:50 mpanetta iggy: I thought that was what the template formula was for?
17:50 mdasilva joined #salt
17:51 murrdoc joined #salt
17:51 iggy never heard of it... so it's probably not mentioned enough
17:51 mpanetta iggy: https://github.com/saltstack-formulas/template-formula
17:51 KaaK more concisely, when doing jinja imports from pillar sls files, what directory are imports relative to?
17:52 mpanetta Hm, never did jinja in pillar, didn't know you could...
17:53 iggy there are 143 formulas (just in saltstack-formulas)... that has little chance of being seen sadly
17:53 SheetiS KaaK: imports in pillars are relative to the pillar root.  so my pillar root is /srv/pillar and if  I wanted to import /srv/pillar/foo/bar.sls I could just import foo.bar
17:53 skyler iggy: It is referenced in the documentation on how to make a formula, let me see if I can find it.
17:54 babilen iggy: I really do like the idea of an example formula, maybe we should work on that first and then write documentation for it that will, at one point, serve as style guide?
17:54 timoguin That makes good sense to me.
17:54 iggy it's mentioned
17:54 KaaK SheetiS, sorry, not the pillar 'include' keyword, but rather jinja imports. e.g. {% from "some/place/in/pillar_root?/map.jinja" import common_variable with context %}
17:54 iggy in a single sentence
17:55 iggy and it could use some improvements
17:55 SheetiS KaaK: it should still be relative to the pillar root so I'd do {% from "foo/bar.sls" import baz with context %}
17:56 KaaK SheetiS, thanks!
17:56 skyler iggy: Agreed. It is definitely not easy enough to find. It is here for those interested http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#repository-structure
17:56 babilen Maybe the best way formward is to work on that template formula so that we are happy with it, discuss issues in issues/pull requests and try to get it to the point that it exemplifies more complex setups too.
17:56 iggy we just don't want it to be too complex
17:57 iggy we don't want some 2nd day salter stumbling across something like the zookeeper-formula and throwing in the towel before they even get started
17:57 murrdoc heh zookeerp formula
17:58 Cottser fwiw, newbie perspective: it took me a couple weeks of playing with salt to even find that formulas existed :)
17:58 SheetiS For most things, the emphasis should be first on readability.  That's suppsed to be the benefit of using yaml with jinja (when necessary).  We can get deep into it with jinja (and believe me I have for some things), but most things don't need to be that complex.
17:59 babilen "Only works if 'zookeeper' is one of the roles (grains) of the node" :(
17:59 babilen IMHO a nono
17:59 timoguin yea leave that to the top.sls
17:59 iggy the graphite one does the same
17:59 iggy and it's always bothered me
17:59 cleme1mp_ joined #salt
17:59 babilen horrible, you should target yourself
17:59 murrdoc graphite one only works with diamond
17:59 forrest joined #salt
17:59 iggy I'm assuming they were written by the same person
17:59 iggy they both have an overly complex settings.sls
18:00 SheetiS If someone wants to make formulas work with roles, etc in their environment, that's fine, but don't make it part of a public formula.  We should be able to abstract an environment's targeting mechanism from the formula itself.
18:00 babilen o_O
18:00 iggy (and sadly one of my coworkers copied it thinking that was "the right way")
18:00 BrendanGilmore joined #salt
18:00 rawzone joined #salt
18:00 murrdoc :|
18:01 iggy one place I like grain/etc targeting in the formula is (f.ex.) targeting the node that's receiving data
18:02 blast_hardcheese joined #salt
18:02 mpanetta Grain targeting is nice for complete automation, when your node names are meaningless and possibly auto-generated...
18:03 mpanetta Only issue I would have with doing it exclusively in the top file is that means you only get matching when running the highstate.
18:03 iggy I added it to the collectd formula in the ping plugin... you can specify a host and/or you can use host_from_grains
18:04 iggy and I'll probably end up adding it to other formulas since pillar merging went all wonky on me a couple of weeks ago
18:04 SheetiS I definitely use 'role' and 'category' grains for all my targetting in my local environment, but try and keep that separate from the formulas completely.  If I absolutely need it, so far I only keep it in my local fork.
18:05 thedodd joined #salt
18:05 iggy and this is why I don't ever see formulas being more than convenient templates... not ready to run pypi modules that are strictly versioned
18:05 faust joined #salt
18:06 iggy but hey... that's just me
18:06 ekristen joined #salt
18:07 ekristen basepi: should the documentation for the salt-cloud 0.8 be the same in terms of what it supports for the cloud providers now that it is in salt?
18:07 asyncsrc joined #salt
18:08 ekristen basepi: it seems that the yaml that used to work for network_interfaces on ec2 cloud provider doesn’t work anymore now that salt-cloud is built in
18:08 SheetiS To be honest I kinda want to refactor my whole salt installation at this point because I tried really hard at first to always use saltstack formulas and contribute back what I did to make them work for my needs to share with the community.  I think it has left my overall layout/configs way messier than I would have otherwise wanted.
18:09 basepi ekristen: honestly, I have no idea.
18:09 cmthornton Regarding complex formulas vs simple ones, you guys are saying it's better for a formula to contain just the basics? What do you do when you need to do more than the formula provides? `extend` the states the formula provides?
18:09 basepi Salt cloud is a weakness in my salt knowledge.
18:10 cmthornton salt-cloud was confusing to setup, might still be, because the config file names and format got changed
18:10 timoguin ekristen: I'm using network_interfaces to define ip info, subnet, and security group in my profiles for AWS
18:10 SheetiS ekristen: I can provide a link of how my cloud profiles for ec2 look including network_interfaces
18:10 SheetiS I have that working ok in salt-cloud atm.
18:10 ekristen timoguin: http://docs.saltstack.com/en/latest/topics/cloud/aws.html#cloud-profiles the (#auto assign public IP (NOT EIP) doesn’t seem to work anymore
18:11 conan_the_destro joined #salt
18:11 aparsons joined #salt
18:11 hal58th1 joined #salt
18:11 ekristen when I was running salt-cloud installed separated from saltstack and saltstack was running as 2014.1.0, it worked, but now that I am on 2014.7.0rc5, it doesn’t work
18:12 timoguin ekristen: I'm using that exact syntax, and it's working fine for me. I'm on 2014.1 though.
18:12 SheetiS ahh I'm using 2014.1
18:12 ekristen timoguin: I think you were the one that originally helped me with it 11 months ago, lol
18:12 SheetiS https://bpaste.net/show/7f4e01709681 is how mine looks.
18:13 ekristen yup, I think that something changed when salt-cloud was merged into saltstack
18:13 ekristen guess I’ll have to poen a ticket
18:13 timoguin 2014.1 had it merged in too.
18:13 timoguin I'm only using what comes with Salt.
18:14 iggy cmthornton: if it makes sense for a formula to be complex, so be it, but don't make it complex just because you copied someone else's formula and it was godawful
18:14 timoguin cmthornton: yea there's a fine line between complex and feature-full
18:15 iggy you don't need 1000 sloc to install screen and conversely if you've got 100 lines to install and setup a mongo cluster, you're probably cutting some corners
18:15 rap424 joined #salt
18:15 SheetiS ekristen: I know some of the stuff was extended for launching an ec2 instance into a vpc in 2014.7, but I haven't messed with it yet.
18:16 SheetiS http://docs.saltstack.com/en/latest/topics/cloud/aws.html#launching-instances-into-a-vpc
18:17 KyleG joined #salt
18:17 KyleG joined #salt
18:17 ekristen hrm
18:17 ekristen so I see where the interface gets created
18:17 ekristen so I see the salt-cloud call to create the network interface
18:17 ekristen and the options it sends
18:17 ekristen I see no errors
18:17 ekristen but no public ip is on the network interface
18:17 g4rlic So, quick Q about 2014.7.  I see a tag has been cut over a week ago, but I'm still seeing commits to 2014.7 branch, and no word on timing of the release.  Can anyone speak to when we might see an official 2014.7.x release?
18:18 Ryan_Lane joined #salt
18:18 chitown ^^^^ yes, please
18:18 aw110f joined #salt
18:18 ekristen wonder if there is a public ip limits I’m hitting but the salt-cloud isn’t returning the error from ec2
18:18 pipps joined #salt
18:19 chitown if we have to roll our own pkgs, thats ok... i just dont want to take the time to have a pkg come out an hour later :/
18:19 bhosmer_ joined #salt
18:19 skyler I think that formulas can be complex as long as they are modular. I mean, you should be able to pick it up and go for a minimal configuration. All of the other stuff should be added as other states. I don't see a problem with there being a lot of states in a formula.
18:19 monkey66 joined #salt
18:19 timoguin g4rlic: 2014.7.0 has been cut, just giving packagers time. New commits on that branch will go into 2014.7.1
18:20 timoguin At least that's how things have worked for a while now.
18:20 Ahlee neat, then I can target 2014.1.13 now
18:20 Ahlee upgrade time!
18:20 workingcats joined #salt
18:20 UtahDave joined #salt
18:20 babilen most packages are done anyway
18:21 g4rlic timoguin: Excellent, thanks!  Just wanted to know if I coudl start upgrading our internal package now.
18:21 GnuLxUsr joined #salt
18:23 cmthornton So what do you do if the formula does too little? (1) not use it and write your own, or (2) write your own states that include/extend the original formula, or (3) something else? I'm wondering what you guys do in this situation because currently I stop using most formulas when I need to do more than they offer. I didn't like the extend/include approach, it makes the states harder to follow, plus I often end up making heavy use of `
18:24 Ahlee cmthornton: I use no formulas, and everything is internally developed
18:24 mbrgm joined #salt
18:25 skyler cmthornton: I would like to extend and then commit upstream. What I actually do is either (1) or (2), more likely (1).
18:25 thedodd joined #salt
18:26 timoguin I try to add new capabilities/features to formulas and then commit back upstream.
18:26 timoguin Sometimes the learning curve for figuring out how the formula works prevents that and I'll just throw something quick together that's I keep private
18:30 kermit joined #salt
18:30 kermit joined #salt
18:30 jalbretsen joined #salt
18:31 mdasilva joined #salt
18:31 smcquay joined #salt
18:36 murrdoc joined #salt
18:37 pdayton joined #salt
18:37 mohae joined #salt
18:37 murrdoc iggy:  what dont you like about grains defining roles
18:38 perfectsine joined #salt
18:38 Ryan_Lane jinja is printing u'a_string' into a template. any idea why it's doing this, rather than just printing the string?
18:38 iggy murrdoc: I do like it... I just don't think it should be the only way a formula should function
18:39 murrdoc ok
18:39 iggy Ryan_Lane: because python2's utf handling blows?
18:39 Ryan_Lane yes, yes, but how do I fix it? :)
18:40 murrdoc https://pythonhosted.org/six/ + unicode
18:41 iggy wherever that variable is coming from is being seen as UTF8
18:41 iggy without more info...
18:41 alexbst are there any usage pattern example docs/guides for salt ?
18:41 thedodd joined #salt
18:42 murrdoc unrelated but this is impressive https://reinvent.awsevents.com/live/keynote.html
18:42 kermit joined #salt
18:42 Ryan_Lane iggy: it's from the etcd external pillar
18:43 felskrone joined #salt
18:44 Ryan_Lane the values come back as u'' rather than ''
18:44 iggy alexbst: some... I'd read ryandlane.com/blog for some info the salt docs are obviously a good source of info... digital ocean has something specific to their cloud (as does at least GCE)
18:45 babilen alexbst: http://docs.saltstack.com/en/latest/topics/best_practices.html + http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
18:45 cmthornton Ryan_Lane: if the file utf-8 encoded you could use `iconv` and convert it into latin1
18:45 Ryan_Lane in jinja I can do this?
18:45 cmthornton iconv is a commandline utility
18:46 iggy Ryan_Lane: filter it through |string maybe?
18:46 Ryan_Lane |string doesn't help
18:46 Ryan_Lane .encode('ascii') doesn't help either
18:48 murrdoc you are using the etc external pillar ?
18:48 murrdoc got link to the code ?
18:48 Gareth morning morning
18:49 teebes joined #salt
18:49 Ryan_Lane murrdoc: to the etcd pillar code? :)
18:50 Ryan_Lane murrdoc: or an example of how I'm using it?
18:50 thawes joined #salt
18:50 Ryan_Lane I'm using it as a normal pillar
18:50 murrdoc the former
18:50 murrdoc i feel like the cleaner way would be to fix the python
18:50 murrdoc instead of do this at the jinja level :)
18:51 SheetiS |string() actually makes a string unicode if it is not already in jinja
18:51 SheetiS so backwards :(
18:51 Ryan_Lane agreed
18:51 gmcwhistler joined #salt
18:51 Ryan_Lane murrdoc: it's in core
18:52 murrdoc oh my bad
18:52 Ryan_Lane https://github.com/saltstack/salt/blob/develop/salt/pillar/etcd_pillar.py
18:53 murrdoc https://github.com/saltstack/salt/blob/develop/salt/utils/etcd_util.py#L102
18:54 alexr joined #salt
18:55 joehh sylphid: probably - I haven't had a chance to test dependencies yet, and that wouldn't surprise me
18:55 joehh I'll check and add it
18:56 thawes joined #salt
18:56 Ryan_Lane murrdoc: ?
18:56 joehh I'm still working on a backport of requests for squeeze
18:58 SheetiS It looks like the keys get mapped to a str on line 96, but the value is just returned as whatever it is with no care for encoding (on etcd_util.py).
18:58 murrdoc Ryan_Lane:  uh , i was thinking thats where the 'fix' would have to be
18:58 Ryan_Lane ah. gotcha
18:58 Ryan_Lane is just casting to string the correct action?
18:58 SheetiS Ryan_Lane: does the value from etc end up in yaml anywhere?
18:59 diegows joined #salt
18:59 Ryan_Lane SheetiS: it does
18:59 primechuck joined #salt
19:00 Ryan_Lane we take the pillar, then inject it into the template using context
19:00 Ryan_Lane from a state
19:01 SheetiS yaml is probably messing it up then.  It doesnt' understand unicode by default.  I think you can toggle a yaml_utf8 setting in your config for your master/minion, but it is experimental.
19:02 SheetiS http://docs.saltstack.com/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html#yaml-support-only-plain-ascii
19:02 Ryan_Lane I see.
19:02 pjs joined #salt
19:02 Ryan_Lane yeah. I think that's the problem.
19:02 thayne joined #salt
19:03 SheetiS Think it's just 'yaml_utf8: True' in your config to test.
19:04 Ryan_Lane that was it
19:04 Ryan_Lane thanks for the help :)
19:04 SheetiS :D
19:04 Ryan_Lane I think we're a little worried to use something salt marks as experimental ;)
19:06 SheetiS The other way to fix it would be to put ther pillar data directly into the templated file instead of passing it with context.  I think jinja should handle it ok, but it's yaml fubaring the data that got you there.
19:06 Ryan_Lane that's what we did
19:06 SheetiS Because none of us have ever had yaml mess with our data, have we? ;-)
19:07 mpanetta Noooo never! heh
19:07 Ryan_Lane our other consideration was to do .encode('utf-8') on the string in the sls file
19:08 aparsons joined #salt
19:10 ndrei joined #salt
19:10 SheetiS Ryan_Lane: would that work?  By the time yaml has messed with it, I'd think you would end up with a utf8 string that had the contents of "u'<foo>'", but would be curious to what would happen.
19:11 Ryan_Lane well, jinja is what's including the pillar, so it should work
19:12 Ryan_Lane I'd be changing the encoding of the string before it's added to the yaml (sls) file
19:12 Ryan_Lane it doesn't work from the template, for sure
19:12 SheetiS ahh I see what you mean.
19:13 gothix Can I run a local command on the master when a state triggers something? Cant really find anything in the docs or in cmd run or script run.
19:13 mpanetta gothix: You could use a minion on the master to do that
19:13 g4rlic gothix: I believe that's he purpose of Reactor, no?
19:14 pdayton joined #salt
19:14 SheetiS How do you like using etcd as an external pillar?  I've been looking at a way of separating per-instance pillar data in a sane manner without doing anything too crazy.
19:14 g4rlic http://docs.saltstack.com/en/latest/topics/reactor/index.html
19:14 gothix mpanetta, Never tried that, okay makes sense.
19:14 Ryan_Lane SheetiS: we're considering some fun stuff with it ;)
19:14 Ryan_Lane we're using masterless
19:14 mpanetta Reactor cant call things directly though, you have to use a minion IIRC
19:15 Ryan_Lane so, we're considering using it for service discovery, where we have a really simple daemon that does watches and just runs state.sls
19:15 SheetiS Ryan_Lane: I bet that really helps with masterless.
19:15 Bryanstein joined #salt
19:15 iggy gothix: orchestrate might also come in handy (depending on what you're doing... which you weren't terribly clear about)
19:15 Ryan_Lane so everything is managed the same way, but we can immediately update portions of the running system without doing deploys to individual services
19:16 gothix iggy, Just tring to run a one line script when a new machine is build
19:16 Ryan_Lane we may eventually end up with zookeeper, though
19:16 Ryan_Lane which means we'll need to add zookeeper modules/pillars/etc
19:16 iggy oh, definitely want reactor for that then
19:16 * iggy shudders at zookeeper
19:17 Ryan_Lane zookeeper is a lot more stable than etcd
19:17 Ryan_Lane and way more battle tested
19:17 iggy although I have to say, the zookeeper formula "just works" for the most part
19:17 gothix g4rlic, iggy, Thanks Ill look into reactor then thanks!
19:17 Ryan_Lane we don't use formulas :)
19:17 iggy sucker
19:17 Ryan_Lane they're not written to be run sequentially
19:17 SheetiS right now I've got a jinja macro that says something like {% if grains['id'] in some_yaml_load %}\n {{ some_yaml_load[grains['id']] }}\n {% else %}\n {{ some_yaml_load['default'] }}\n {% endif %} that i use for each of my pillars.
19:18 Ryan_Lane almost all of them use requires, and a lot of them actually use order, which makes me shudder
19:18 SheetiS Hard-set order in a public formula scares me.
19:18 SheetiS I can almost live with requires.
19:19 Ryan_Lane I can't live with requires
19:19 Ryan_Lane it fucks with the order
19:19 mbrgm joined #salt
19:19 iggy I haven't seen one that used more than "service requires package"
19:19 iggy which seems sane enough
19:20 _JZ_ joined #salt
19:20 SheetiS as long as you have strict ordered runs that are done sanely and correctly from the ground up, I like not using requires.
19:20 baconbeckons joined #salt
19:20 Ryan_Lane +1
19:20 Ryan_Lane I use listen/listen_in nearly exclusively
19:20 SheetiS iggy: even that simple require will make the order non-deterministic for everything else.
19:21 Ryan_Lane watch/watch_in mess with ordering too
19:21 Ryan_Lane they imply require
19:21 babilen What's wrong with requires? In the end all you care about is a sensible topological sort of the dependency graph. Why wouldn't you want that and do that manually?
19:21 thawes joined #salt
19:21 baconbeckons i have a file.managed state that hangs the first time it runs in my highstate. if i cancell the highstate and run it again, then it completes. how can i figure out what is causing it to hang?
19:21 murrdoc it breaks the top down execution
19:21 murrdoc which is so awesome
19:21 babilen "mess with the ordering" ? I mean if something requires something else then it *has* to run afterwards.
19:22 Ryan_Lane I /don't/ care about a graph
19:22 babilen murrdoc: Who cares? In the end all you care about is that a state has been achieved. If salt has to reorder states because you got it wrong then so be it.
19:22 Ryan_Lane in fact, I don't want a graph
19:22 Ryan_Lane I want the state to execute in the order I define
19:22 Ryan_Lane explicitly :)
19:23 murrdoc ryan sounds like someone who has used puppet
19:23 babilen Why?
19:23 murrdoc o/ puppet high five
19:23 babilen Who cares about the order if all states have been achieved at the end?
19:23 SheetiS The good thing is that it doesn't matter which way you prefer because salt is flexible enough to do both.
19:23 babilen I much rather add a "require: pkg: foo" than having to reorder all my states/sls includes/... manually all the time just to ensure that some dependency is satisfied.
19:23 Ryan_Lane because understanding what's going wrong when something goes wrong is very difficult when you don't know the order of execution
19:24 babilen Ryan_Lane: You can always see the order of execution in your run
19:24 Ryan_Lane and yes, puppet has taught me this well ;)
19:24 Ryan_Lane babilen: but you don't know the order it'll run when you write it
19:24 babilen requirements are one of the great things in salt, I'd *hate* it if I have to take care of proper order manually in complex setups.
19:24 Ryan_Lane and you don't know the order of the first run vs additional runs
19:25 murrdoc i have had to use dot files to figure out who broke what by changing what
19:25 murrdoc thanks puppet
19:25 babilen Ryan_Lane: Why would you have to know the order? If your state has requirements then express then so that a topological sort will sort that state after the required ones. If it doesn't then it does also not matter when it is executed.
19:26 babilen *them
19:26 murrdoc if the requirement is important to a followup state , failhard:true should / could handle that yeah ?
19:27 KennethWilke joined #salt
19:27 pipps joined #salt
19:28 babilen One example: I write a SLS file in which I create a directory that should belong to a specific user. I use "include: - users" and "require: - user: foo" and salt takes care of the rest.
19:29 babilen If I couldn't do that I would have to manually reorder my states (so they are no longer alphabetically ordered in my top.sls) all the time just to take care of changing requirements and run into easily preventable errors in my *manual* order if I had expressed all depdendencies to begin with.
19:29 babilen You happily accept this behaviour in a package manager. Why not salt?
19:29 babilen I mean in the end: "If all states have been achieved why care in which order they ran?"
19:31 babilen You would also have to split larger SLS files into single-state-sls files only to be able to order them independently of the rest while salt works happily with requirements on single state ids
19:31 babilen Sorry, I *really* don't get this.
19:31 jalaziz joined #salt
19:36 cbaesema joined #salt
19:36 yambo joined #salt
19:37 p0rkmaster joined #salt
19:38 ajolo_ joined #salt
19:38 rap424 joined #salt
19:39 mdasilva joined #salt
19:42 cmthornton I don't get listen/listen_in, they don't modify the order of the states, so why are they needed?
19:42 AubreyF joined #salt
19:46 iggy to react to changes in other states
19:47 babilen By doing what?
19:48 babilen http://docs.saltstack.com/en/latest/ref/states/requisites.html#listen-listen-in really isn't clear on what it does.
19:48 babilen "similar to how watch its counterpart watch_in" ??
19:48 cmthornton I re-read the description in the docs, I think I get it, basically the `service <service> reload` happens after the whole sls file is done
19:48 babilen Wouldn't that reorder the state?
19:49 cmthornton but why not just move the config file above the service.running? then no need to listen
19:49 gmcwhistler left #salt
19:49 cmthornton and that's the behavior you desire if you're using listen/listen_in, right?
19:49 murrdoc yup
19:49 babilen I'm still not sure how that differs from watch/watch_in
19:50 cmthornton with watch, I think as soon as the config file state is executed, the service reloads
19:50 cmthornton but with listen, it happens at the end of the sls file
19:51 babilen So one would actually always want listen/listen_in ?
19:51 cmthornton anyone know for sure if that's right?
19:51 babilen I'm also not sure what "mod_wait functions for states" refers to exactly.
19:52 babilen When I read that my impression is that they want to somewhow accumulate actions that will be executed at the end of the state run to ensure that changes are "applied", but I don't really find that spelled out in the docs.
19:53 Ryan_Lane babilen: listen/listen_in run after the state run
19:53 Ryan_Lane and they run in the order defined
19:53 babilen cmthornton: And why would service.running + listen call "service FOO reload" ? Up until now I implemented that with module.wait
19:53 Ryan_Lane the issue with config management and ordering is that someone will always forget a require somewhere
19:54 babilen Ryan_Lane: Well, then you can still rely on order
19:54 Ryan_Lane and that state will execute in some order you didn't expect and it'll cause a state run failure
19:54 Ryan_Lane and it'll happen after a change to your requirements
19:54 Ryan_Lane and it'll happen only for initial runs, but not for subsequent runs
19:54 Ryan_Lane so you'll have a broken initial run and have no clue
19:54 Ryan_Lane if you autoscale, that's an outager
19:54 cmthornton I can see how that'd simplify some things, like, you're bringing up a server for the first time, you're server is in an unstable state while it's provisioning, so you don't care when the daemon gets restarted, it just needs to be restarted after all the other provisioning is done
19:54 babilen Well, that's why I test my states
19:54 Ryan_Lane *outage
19:55 Ryan_Lane you have automated tests that test initial runs?
19:55 Ryan_Lane for every change?
19:55 babilen Ryan_Lane: I typically test my changes before I push them into production, yeah
19:55 Ryan_Lane (we build containers from scratch nightly, so in effect we do)
19:55 Ryan_Lane you test a full creation every time before you push to production?
19:55 cmthornton I do
19:56 babilen I don't necessarily provision boxes from scratch *while* I develop them, but before they enter production they get a full local test run.
19:56 SheetiS Ryan_Lane: do you ever have problems with versioning of data in your etcd ext_pillar?
19:56 Ryan_Lane SheetiS: we're only using etcd for dev/ci right now
19:56 Ryan_Lane for what we call "supervagrant"
19:56 SheetiS ahh
19:56 Ryan_Lane which runs coreos+docker+etcd
19:56 babilen cmthornton: Do you understand how the reload works there?
19:56 Ryan_Lane our containers can reference each other using hostnames, which are populated in etcd
19:57 hal58th joined #salt
19:57 cmthornton babilen: for listen?
19:57 SheetiS Our docker stuff isn't managed with salt currently, though I really wish it were.
19:58 Ryan_Lane ours isn't either
19:58 Ryan_Lane since we're using coreos we can't
19:58 babilen cmthornton: yeah
19:59 Ryan_Lane babilen: even assuming we did full creation tests for every change, I wouldn't want to track down bugs due to ordering defined by requires
19:59 babilen cmthornton: Or would that actually be a "restart" and you simply mentioned "reload" because you thought that that would be more appropriate in some cases?
20:00 nethershaw joined #salt
20:00 cmthornton babilen: ahh, yeah, I'd be a restart, but you can make it do a reload by setting `- reload: True` in the service state iirc
20:00 babilen Ryan_Lane: So you rather track down bugs due to ordering defined by your top-down order? How do you deal with the case that I mentioned earlier?
20:00 Ryan_Lane I haven't had any issue with that
20:00 babilen cmthornton: Okay, you totally threw me of track with that as I was very surprised why it should behave like that.
20:01 Ryan_Lane it's no different from writing regular code
20:01 Ryan_Lane (which is the entire point, our salt code is also maintained by our developers)
20:01 babilen apart from the fact that you cannot call any functions that are defined elsewhere
20:01 Ryan_Lane of course you can
20:01 babilen (if this where code)
20:01 Ryan_Lane you can do includes
20:01 babilen No, that would change the order.
20:01 Ryan_Lane it doesn't
20:01 Ryan_Lane if you use jinja includes
20:02 Ryan_Lane https://github.com/saltstack/salt/issues/14899#issuecomment-62775208
20:02 Ryan_Lane includes always happen first, too
20:02 Ryan_Lane so if you put include: at the top of the state, you always know what's going to happen anyway
20:03 mbrgm joined #salt
20:04 iggy what if you have include: nginx and then further down in your top file you have nginx listed?
20:04 babilen If you have "-a -b -c" in your top.sls and a.sls includes c.sls the order will be changed, won't it?
20:04 iggy bam top-down ordering blown to hell
20:04 babilen exactly
20:05 babilen And I don't see how that differs from requirements apart from their granularity (and you would *still* have to include the entire SLS if you want to use a require
20:05 babilen )
20:05 jdmf joined #salt
20:07 jdmf joined #salt
20:07 tristianc joined #salt
20:07 babilen cmthornton: https://www.refheap.com/93241 (restart and reload)
20:07 bhosmer_ joined #salt
20:12 cmthornton babilen: so that lets you restart a service by `- require: foo-restart` (similarily for reload) if you need to start the service after a state executes? why not use watch/watch_in?
20:13 cmthornton need to restart* the service
20:18 babilen cmthornton: In particular it allows you to differentiate between reloads and restarts. And yes, one of them is superfluous.
20:18 babilen (in the strict sense)
20:19 cmthornton I see, but you do want to restart the service typically after bringing up the node, but then reload once the db/web server is handling requests
20:19 babilen And you would just "watch: module: foo-restart" or "watch: module: foo-reload" depending on if you want to do. You could, naturally, use "watch: service: foo-service" for restarts and "watch: module: foo-reload" for reloads.
20:19 cmthornton cool, thanks for that, I've never used module.wait and I can see it's really flexible
20:19 babilen cmthornton: For changes to, say, the apache config a reload is all that is needed and less intrusive.
20:20 cmthornton yep
20:27 mdasilva iggy: i got it sorted
20:28 mdasilva the libgit2 library that was installed with my package manager didnt build in libssh support
20:28 mdasilva it wasn't a problem before since i was using pygit2 with https
20:28 iggy gotcha
20:29 mdasilva when i actually read the error message i realized what was going on
20:29 mdasilva reading + thinking = good things
20:30 jeffspeff joined #salt
20:31 jeffspeff i have a regex i'm trying to use in file.replace, it matches and replaces the line i'm wanting, but it deletes the rest of the file after that line. http://regex101.com/r/lO8sQ1/1   any suggestions?
20:32 iggy s/$/\n/ ?
20:33 iggy no clue really... I suck at regex's
20:34 Nazzy joined #salt
20:34 Nazzy joined #salt
20:34 cmthornton file.sed and use backreferences \1?
20:35 cmthornton not sure how file.replace works, never used it, but sed can definitely put the content back
20:35 iggy sed is deprecated
20:35 mdasilva jeffspeff: that regex looks good to me
20:35 cmthornton ugh :\
20:36 mapu joined #salt
20:36 mdasilva thought it might neede a line anchor but you have one there
20:38 jeffspeff in my file.replace, the repl is "repl: 'hostname: foo-Office' "  is it maybe the replace that's deleting the rest of the lines?
20:40 iggy are you using multiline?
20:40 pipps joined #salt
20:40 iggy (it's in your regex101 post)
20:40 jeffspeff iggy, here's the exerpt from the init.sls
20:40 jeffspeff http://pastebin.com/xfJr3kFE
20:41 jeffspeff i'm pretty unfamiliar with regex's. am i supposed to a /igm after the expression in pattern?
20:41 iggy that's the whole state? if so, then no, you aren't
20:41 iggy no, you'd use - flags: ['A', 'B']
20:42 SheetiS should use flags MULTILINE and file buffering
20:42 Nacmac joined #salt
20:42 SheetiS Per this: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.file.html#salt.modules.file.replace which the state just passes everything to this.
20:43 iggy bufsize: file
20:43 jeffspeff like so? http://pastebin.com/xfJr3kFE
20:43 iggy check out the docs
20:43 AubreyF Greetings! Looks like Vagrant is installing salt-call 2014.1.13 for hashicorp/precise64 VMs on my Windows 8 dev box. What's the best way for me to upgrate VMs a newer salt stack?
20:43 AubreyF I need at least 2014.7.0 for git.latest support.
20:43 AubreyF Looks like I should be able to use the salt.install_type = "git" vagrantfile option, but docs say it "isn't supported" on windows platforms?
20:43 iggy I don't remember what it is off the top of my head... the A and B were examples
20:44 kermit joined #salt
20:44 SheetiS I think "- flags: ['MULTILINE']" would work and then "- bufsize: file" to buffer the whole file
20:44 iggy AubreyF: you don't need 2014.7 for git.latest
20:45 to_json joined #salt
20:45 jeffspeff SheetiS, thanks. where'd you get the bufsize option from?
20:45 iggy the docs...
20:45 SheetiS http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.file.html#salt.modules.file.replace
20:45 jeffspeff nvm
20:45 jeffspeff found it
20:47 AubreyF hmm, thanks Iggy. I'm getting an "Specified state git.latest is unavailable" when attempting to install Node.js from source. pasting salt template now
20:47 AubreyF http://pastebin.com/i9n4dTw1
20:48 AubreyF node install template execution: http://pastebin.com/DnzcEyjD
20:48 __gotcha joined #salt
20:49 micah_chatt joined #salt
20:50 SheetiS I'm running git.latest with 2014.1.13.
20:51 AubreyF Did I simply screw something up in the install template? http://pastebin.com/i9n4dTw1
20:52 claytonk joined #salt
20:52 mapu joined #salt
20:52 SheetiS try and - require:\n  - pkg: git on the git.latest?  You'll  need git installed for the git.latest to work.
20:53 SheetiS I also gave a '- rev: <branchname>' on mine which it does not appear you had.
20:53 murrdoc - unless: if [ -z $(node --version) ];
20:53 murrdoc will work also
20:54 KaaK how can I call `state.highstate` from a reactor sls?
20:55 Ryan_Lane babilen: maintaining the ordering is easy. just never use require or watch
20:56 Ryan_Lane if you do that, it'll execute in the order defined
20:56 AubreyF Sheetis: Your suggestions make perfect sense, but I'm still getting the same error: http://pastebin.com/BAKeuePS
20:56 Ryan_Lane I include base and <service> from the top.sls, and <service> includes anything it needs
20:57 wendall911 joined #salt
20:57 __gotcha joined #salt
20:58 Ryan_Lane I also set global failhard, so that any specific state failure will cause a full failure
20:58 murrdoc this is essential btw
20:58 murrdoc the global failhard
20:58 Ryan_Lane yep
20:59 baconbeckons joined #salt
20:59 murrdoc also in the latest salt you can do a '- failhard: true' in any state
20:59 murrdoc that you end up requiring in too many places
20:59 SheetiS AubreyF: do you have a state for the git pkg that says something like git:\n pkg.installed at least somewhere that is either included or in the same state file as what you pasted?
21:00 AubreyF SheetiS: just added one, looks like everything's working now...
21:00 AubreyF Thx for the help, first day with Salt
21:00 AubreyF Loving it!
21:00 SheetiS Good luck going forward :D
21:00 g4rlic left #salt
21:01 AubreyF node -v
21:01 Ryan_Lane murrdoc: yeah, I'm using it for orchestration, where we don't use failhard
21:01 SheetiS -irc: node: command not found
21:02 Ryan_Lane I do want /some/ things to cause a failure there, though :)
21:02 murrdoc makes sense
21:03 KaaK or a better question -- how can I troubleshoot a reactor sls? Even in log level `debug` i just get a " Failed to render "/srv/reactor/start.sls""
21:03 Ryan_Lane KaaK: it's really hard, unfortunately :(
21:03 SheetiS KaaK: It's hard for reactors.
21:03 SheetiS You could bpaste/pastebin it here and maybe one of us can catch it.
21:03 KaaK I can see that it gets fired ... it just fails to render ....
21:04 SheetiS KaaK: if it has a syntax error rather than a failed state, unfortunately that is all you will see usually.
21:05 KaaK SheetiS, Ryan_Lane, http://paste.debian.net/131492/
21:06 KaaK i just want to call highstate when a minion starts up
21:06 pdayton joined #salt
21:06 SheetiS KaaK: To prevent a key error, I'd switch the first like to say {% if 'id' in data %} to start with.
21:07 jalbretsen joined #salt
21:08 SheetiS Other than that, I think it looks good if you are running 2014.1.xx
21:08 timoguin cmd was changed to local in 2014.7, so local.state.highstate
21:09 KaaK yeah, I'm running 2014.1.10
21:10 murrdoc KaaK:  thats an option in the config file
21:10 SheetiS I'd change your if at the top first to be like what I said above and try that.
21:10 murrdoc to run highstate on boot
21:10 murrdoc i mean i thought it was
21:11 timoguin startup_states: highstate
21:11 mgw joined #salt
21:11 murrdoc yup
21:11 murrdoc there it is
21:11 murrdoc no need to reactor it up kaak
21:11 KaaK SheetiS, i swapped it to a membership test -- same useless render error
21:12 KaaK murrdoc, awesome!
21:12 murrdoc well timoguin too but yeah it is awesome
21:12 SheetiS found the error btw:     - tgt: {{ data['id' }}  <== closing bracket missing ]
21:13 SheetiS I missed it the first time through
21:13 SheetiS just in case you need the reactor for something else
21:13 jeffspeff SheetiS, i'm getting an exception error now. here's the state and the error http://pastebin.com/XWwrdmut
21:13 druonysus joined #salt
21:13 druonysus joined #salt
21:13 KaaK SheetiS, ... I can't believe I missed that
21:13 timoguin Man, better reactor errors would be nice. Something like the <============== errors with states/templates
21:14 timoguin debugging reactors is not fun
21:15 teebes joined #salt
21:16 nitti joined #salt
21:16 SheetiS jeffspeff: what version of salt are you running?
21:17 timoguin something tells me there's a better way of managing the salt minion config...
21:17 jeffspeff 2014.1.13 on the master and 2014.1.10 on the minion
21:17 jeffspeff timoguin, i'm all ears if you know of a better way
21:18 nitti joined #salt
21:18 timoguin Well I'm personally using the salt-formula with pillar driving the minion config
21:18 timoguin It's initially set on minion provisioning via salt-cloud
21:18 __gotcha1 joined #salt
21:19 SheetiS jeffspeff: do you have a python file called operator anywhere in any of your salt configs for anything py rendered or otherwise?
21:19 jeffspeff SheetiS, no, my configs are pretty basic.
21:20 nicksloan I'm using pillar_contents, and getting empty files, but the task is succeeding, and pillar.items shows the correct data
21:20 nicksloan any ideas?
21:20 SheetiS the module file imports operator to utilize operator.__or__ there for your error.
21:20 nicksloan using zmq transport, btw
21:20 SheetiS but it passed the import but said operator is not available.
21:21 jeffspeff SheetiS, so, should i re-install the minion?
21:21 SheetiS I'm not sure that is it.
21:22 jeffspeff i wasn't having this issue until i added the flags and bufsize options. this is the only part that's having that error
21:22 SheetiS Operator is part of the std library https://docs.python.org/2/library/operator.html
21:22 p0rkmaster joined #salt
21:22 SheetiS What version of python are you running on the minion (Since it appeared to be windows)
21:23 smcquay joined #salt
21:23 Stew_ joined #salt
21:23 timoguin SheetiS: the salt minion installer for windows bundles python 2.7
21:23 jeffspeff it's 2.7
21:24 jeffspeff all the py*.dll files have 27.dll
21:24 jeffspeff i haven't upgraded it or messed with python. nothing else on the system uses python
21:26 muckmuck joined #salt
21:28 muckmuck I'm just beginning to use Salt and can't tell where to put the configuration information for a mysql returner. The docs says to add it to the master or minion config but which file is that?
21:28 aquinas joined #salt
21:29 aquinas_ joined #salt
21:29 timoguin muckmuck: /etc/salt/master is default for master, /etc/salt/minion for minions
21:30 SheetiS jeffspeff: you could try a re-install of the minion since it is windows.  I don't know why that would give that error.   I know why it would never come up until you add the flags (because the code that gave the error never gets run without flags), but as for the error itself, I am not sure why.  My thought is that there is another operator.py or variable named operator somewhere that is getting pulled in instead.
21:30 SheetiS Alternatively you could use the integer value for re.MULTILINE in that spot
21:30 SheetiS which is 8
21:30 muckmuck So I can put in "mysql.user" in there it doesn't look like YAML to me
21:31 SheetiS jeffspeff: https://bpaste.net/show/0c65f721315a shows the value of MULTILINE.
21:32 jeffspeff SheetiS, thanks. it would still need to be in brackets right? ['8']
21:33 timoguin muckmuck: what doesn't look like yaml? the master/minion configs definitely are
21:33 SheetiS jeffspeff: no brackets
21:34 jeffspeff ty
21:34 SheetiS Though the fact that using the named list failed on windows might be worthy of a bug report
21:34 SheetiS this is just getting you worked around in the meantime
21:35 SheetiS the 'reduce(operator.__or__, [re.MULTILINE])' function works for me on a command line test on my mac.
21:35 muckmuck I see now after looking at the doc. Not sure what I was thinking. thanks for your help.
21:35 SheetiS I don't have windows handy to test at the moment.
21:37 tristianc joined #salt
21:38 jeffspeff SheetiS, so, i changed to the int, re-ran it, it didn't error this time but it deleted all of the lines in the file after the line it matched and replaced. here's the state and the output (those typos in the output are really from the console, including the extra 'e' after 'foo-Office')
21:38 jeffspeff http://pastebin.com/L0uuqvnT
21:39 jalaziz joined #salt
21:45 perfectsine joined #salt
21:46 MTecknology viq: I don't suppose you've had a chance to look at gitlab-ci? I'm starting to consider just deploying it by hand on. I tried diving through your formula and adopting it and then I started crying.
21:47 SheetiS jeffspeff: I am going to try the state locally and see if I can reproduce.  Give me a minute or 3
21:47 jeffspeff ok
21:49 ze- Hey. Is there a way to change the PATH for all cmd.run, everything launched by salt? (beside changing it *before* starting salt-minion)
21:50 SheetiS jeffspeff: it _must_ be a windows specific thing
21:50 SheetiS it worked exactly as expected for me on my test vm
21:50 SheetiS here is the diff I got
21:50 SheetiS https://bpaste.net/show/268ada859e1f
21:50 MTecknology ze-: I'm curious if a cmd state that exports it as a dependency would work... I usually just specify the full path to commands that aren't in the standard path
21:51 SheetiS only line I changed is my minion file was at /etc/salt/minion because linux.
21:51 ze- MTecknology: i'm trying to launch a script with sheebang being /usr/bin/environ python
21:51 ze- but python is in /usr/pkg/bin :)
21:51 SheetiS I don't have a windows minion handy at the moment to go further :(
21:51 manfred MTecknology:  it would not, because would be a seperate bash environment
21:51 jeffspeff let me try upgrading the minion to see if either of the 2 newer versions have fixed the problem
21:51 ze- MTecknology: just found an environ state/module.
21:52 giantlock joined #salt
21:52 tafa2 joined #salt
21:53 ze- ... there is some documentation about it, but doesn't seem available on my host.
21:53 MTecknology manfred: I should have thought of that... thanks for correcting me :)
21:54 jeffspeff just curious, if i upgrade my master to 2014.7.0 and my minions are still on 2014.1.10 will there be problems?
21:55 Ahlee There shouldn't be
21:55 Ahlee Master needs to always be equal to or newer than minion versions
21:56 * ze- sighs. there is a module, but only in develop, not in any release.
21:56 bhosmer_ joined #salt
21:56 SheetiS ze-: sync it as a custom module in /srv/_modules or your equiv location.  Usually you can just take them and use that way.
21:57 ze- SheetiS: yeah. I'll probably end up doing something like that. It's a shame it's not even in 2014.7
21:57 timoguin The environ state/module is in 2014.7.
21:57 ze- mmm... is there also a _state ?
21:58 manfred yes
21:58 mpanetta timoguin: I successfully pulled that one in to 2014.1.x by using _modules and _states
21:58 kickerdog joined #salt
21:58 mpanetta as is, no changes needed :)
21:58 babilen ze-: http://docs.saltstack.com/en/latest/ref/states/writing.html#using-custom-state-modules
21:59 * ze- nods. just haven't had any use for them so far.
21:59 ze- guess i'll also deploy the test state. will be better than cmd.run true
22:01 p0rkmaster joined #salt
22:03 bemehow joined #salt
22:04 kballou joined #salt
22:04 kickerdog Looks like AssociatePublicIpAddress is broken in salt-cloud on the dev branch
22:08 cmthornton ze-: you can add `-env:\n   - PATH: /usr/pkg/bin` to your cmd states. That works ok in my experience, but if all binaries are in /usr/pkg/bin, that'd be really annoying to do for every state
22:09 ze- cmthornton: yeah. For now, adding something like that to the couple runs that might have the missing values. But would rather find a better way to change it globaly
22:10 ze- arg. the environ module need an event listener in the minion to be able to modify the global environment variable.
22:11 cmthornton yep, totally understandable, I want to add /usr/local/bin to my path for all cmd states by default, but I haven't looked too hard on finding a real solution to that because I rarely need have to do it
22:11 londo joined #salt
22:12 ze- cmthornton: a work around would be to export PATH *before* starting the minion
22:12 _JZ_ joined #salt
22:12 tafa2 anyone use AWS lifecycle rules?
22:15 * ze- sighs. ok, the environ module is nice, but tends to only work with current process.
22:15 ze- to update the parent process for further calls, you'd need to have it already aware of the event that would be fired to update its env
22:16 ze- can still be used in state dependencies.
22:16 ze- have it environ.setenv called with order: 1 or something like that, to make it be called before your regular states
22:19 XenophonF joined #salt
22:19 UtahDave joined #salt
22:20 XenophonF hi all - i need to deploy a tar file on a minion
22:20 XenophonF i noticed file.recurse, but i really want to maintain the tar file's permissions, etc.
22:21 XenophonF is there a way to push the tar file to the minion temporarily and untar it?
22:21 XenophonF or is there a good way to use file.recurse + something else to fix up file permissions?
22:21 ze- file.manage it somewhere, ! cmd.run to untar it ?
22:21 jalaziz joined #salt
22:21 XenophonF i could do that
22:21 ze- XenophonF: file.recurse uses single set of perm, not per file rights
22:22 XenophonF i suppose leaving the tar file on the minion isn't that big of a deal
22:22 XenophonF exactly, ze-, that's the issue for me
22:22 ze- you could have the cmd wath on the tar file update, so it only untar if the tarfile actualy changed.
22:24 bhosmer joined #salt
22:24 kermit joined #salt
22:25 UtahDave XenophonF: does that archive state do what you want?
22:27 jalaziz joined #salt
22:28 perfectsine joined #salt
22:29 XenophonF OMG how did I miss that
22:30 XenophonF thanks UtahDave, I think that will do what i want
22:30 UtahDave cool!
22:30 XenophonF i think i'm at that stage where i need to re-read the docs from start to finish
22:31 Singularo joined #salt
22:31 UtahDave I have a hard time keeping up myself.
22:34 ze- UtahDave: when an issue is in a "Pending Discussion" state. Does it mean someone from saltstack will someday check into it, or will it just wait there until anyone decide to give a nice suggestion about it and implement it?
22:35 agend joined #salt
22:35 UtahDave It depends. It usually means that the engineer likes the idea in general, but a discussion needs to happen to decide how to proceed.
22:36 UtahDave If nothing has happened for a while, I would recommend commenting on the thread again to kickstart the discussion.
22:37 ze- guess 4 weeks qualify as "a while"?
22:40 ze- i'll look into it tomorrow, and comment some more about it.
22:40 ajolo_ joined #salt
22:40 nitti joined #salt
22:40 UtahDave ze-: cool.
22:41 forrest joined #salt
22:42 hal58th1 joined #salt
22:43 __gotcha joined #salt
22:44 KaaK is there any simple way to order a state such that is globally the first or last state to be run?
22:44 hal58th1 KaaK: yes. now to figure out which page it is on
22:45 ze- KaaK: the "order" option
22:45 druonysuse joined #salt
22:45 druonysuse joined #salt
22:45 hal58th1 Kaak: http://docs.saltstack.com/en/latest/ref/states/ordering.html#the-order-option
22:45 * ze- was about to paste it :)
22:45 hal58th1 wow, he nailed the description even
22:45 ze- hal58th1: actualy one of the features I do use.
22:46 ze- mainly to "fix" salt before running the other states. :)
22:46 KaaK heh
22:46 ze- (fix mainly means placing files with my pathes that are not yet in current version -- but all ready to roll in 2014.7 :)
22:46 hal58th1 I like to use it to restart salt minion after I put a highstate schedule in it's configuration. order: last and sleep 30 && /etc/init.d/salt-minion restart
22:50 ze- isn't there an event at the end of a highstate for such?
22:51 beneggett joined #salt
22:52 murrdoc joined #salt
22:58 hal58th1 ze-: not that I know of.
22:58 XenophonF left #salt
22:59 b1nar1 joined #salt
23:00 ze- hal58th1: well, i haven't done much with reactors but sync_all on minion_start, and then launch a module to fix some "static" state that need the other states to already be loaded :)
23:00 ze- rmm... grains, not states.
23:00 ze- a static grain that need other grains to be loaded.
23:01 MrFuzz joined #salt
23:01 hal58th joined #salt
23:12 beneggett joined #salt
23:14 ze- what's current status of 2014.7 ?
23:14 iggy it's got release notes
23:14 meylor joined #salt
23:14 iggy and has been tagged
23:14 rap424 joined #salt
23:15 quickdry21_ joined #salt
23:16 murrdoc really ?
23:16 murrdoc i saw the .7
23:16 murrdoc i didnt see the tag for it
23:16 murrdoc well well well https://github.com/saltstack/salt/tree/v2014.7
23:19 lz-dylan Relatedly, is there a typical time from release to the release being packaged? I feel like the 2014.1.x release->dpkg turnaround was really quick.
23:19 ze- "lastest stable" is still maked as 2014.1.13
23:19 ze- so, while the doc is not updated... not really sure about status of 2014.7 :(
23:21 ze- well, package seems available in http://debian.saltstack.com/debian/pool/main/s/salt/
23:22 ze- so, I guess it really is released. The doc is not up to date though :)
23:24 ze- anyone worked with reactor here? anyway to define reactions dynamicly, as in without needing to restart the master on changes?
23:25 ze- (for nom, defined as reactor: in the master config)
23:26 pipps joined #salt
23:26 iggy lz-dylan: the release process was wildly different this time around (and will likely be quite different for the next release too)... so there's really no typical
23:27 iggy ze-: the doc is correct... for now
23:27 ze- iggy: correct about? version? means 2014.1.13 is the latest stable ?
23:27 iggy yes
23:28 ze- well, 2014.7.0 is not a rc anymore. shouldn't that means it's supposed to be "stable" ?
23:28 iggy 2014.7 has been tagged, but is waiting on some distro packagers, etc. to do the "official" release
23:28 lz-dylan iggy: gotcha. I'll try to be patient :)
23:28 ze- so, it's the latest stable, just not yet available in all distrib
23:30 iggy or as a tarball
23:30 ze- iggy: is there an "official" way to contact maintainers, so they can build and provide it?
23:30 joehh lz-dylan: typically x.y.1+ is quick, often there are dependency and packaging issues to resolve with an x.y.0 release
23:30 ze- if 2014.7 is supposed to be packaged, i'll bug the NetBSD maintainer tomorrow at work :)
23:32 UtahDave joined #salt
23:32 iggy ze-: I suspect... no(t yet)
23:32 elfixit joined #salt
23:32 ze- oh, you mentionned no .tar.gz, so can't package it. :(
23:35 iggy this channel was like 1/3rd the size it is now at the last release... to say that there are some growing pains is putting it mildly
23:35 murrdoc i remember when i had to walk to deploy salt
23:35 ze- mm... what about using https://github.com/saltstack/salt/archive/v2014.7.0.tar.gz ? :)
23:35 murrdoc uphill both ways
23:35 murrdoc ze-:  you can use salt-bootstrap
23:35 ze- what is salt-bootstrap ?
23:36 joehh ze-: they are in the saltstack debian testing repo, dependencies have not yet been resovled for all releases (mainly python-requests)
23:36 iggy if you know the maintainer of a package, I'd suggest you tell them to file a bug to improve the downstream communication channel
23:36 murrdoc ze-:  curl -L https://bootstrap.saltstack.com -o install_salt.sh
23:36 murrdoc chmod +x install_salt.sh
23:36 murrdoc ./install_salt.sh -Z -X -P git v2014.7
23:36 murrdoc ze-:  https://github.com/saltstack/salt-bootstrap
23:36 ze- murrdoc: not a nice way to create a package. :)
23:36 murrdoc oh to create a package ?
23:36 ze- yeah.
23:37 murrdoc on ?
23:37 ze- NetBSD
23:37 ajolo_ joined #salt
23:37 ze- I think usualy it's mainly changing the tarball location. :)
23:37 murrdoc https://github.com/saltstack/salt/tree/v2014.7/pkg/openbsd
23:37 murrdoc will help
23:38 igorwidl joined #salt
23:38 ze- murrdoc: 2014.1.13 is already packaged. so, most of the work is done.
23:38 ze- i'll talk to him about getting a few files in pkg/netbsd maybe :)
23:39 murrdoc i would unpackage it
23:39 murrdoc see whats needed
23:39 murrdoc and make your own pkg
23:40 ze- murrdoc: he'll do our own package.
23:40 auser joined #salt
23:40 ze- the maintainer is a friend :)
23:41 iggy in any case... there are some examples to look at (including *bsd's, and a number of Linux distros)
23:41 KyleG joined #salt
23:41 KyleG joined #salt
23:41 _JZ_ joined #salt
23:42 ze- anyway... time to get some rest. g'night.
23:45 bhosmer joined #salt
23:50 troyreadyy joined #salt
23:50 baconbeckons i have a file.managed state that hangs the first time it runs in my highstate. if i cancell the highstate and run it again, then it completes. how can i figure out what is causing it to hang? i don’t see anything helpful with `-l debug`
23:52 robawt baconbeckons: running on the machine locally via salt-call or from the master?
23:53 baconbeckons robawt: using salt-call
23:54 __JZ__ joined #salt

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