Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2016-08-03

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

All times shown according to UTC.

Time Nick Message
00:02 mpanetta_ joined #salt
00:02 ninjada joined #salt
00:06 flowstate joined #salt
00:09 pipps joined #salt
00:10 SWA joined #salt
00:10 mage_ joined #salt
00:16 josuebrunel joined #salt
00:20 nicksloan joined #salt
00:24 ageorgop joined #salt
00:25 hasues joined #salt
00:25 hasues left #salt
00:27 hasues joined #salt
00:31 yidhra joined #salt
00:33 ninjada_ joined #salt
00:33 hasues left #salt
00:33 ninjada joined #salt
00:34 ninjada_ joined #salt
00:35 edrocks joined #salt
00:37 yidhra joined #salt
00:37 scsinutz joined #salt
00:45 mapu joined #salt
00:49 Nahual joined #salt
00:50 iggy it depends on your options and distro (and probably other things)
00:53 ninjada joined #salt
00:54 fannet joined #salt
00:56 cyborg-one joined #salt
01:05 flowstate joined #salt
01:17 iceyao joined #salt
01:19 catpiggest joined #salt
01:19 badon_ joined #salt
01:20 ninjada joined #salt
01:22 mpanetta joined #salt
01:23 badon joined #salt
01:46 sagerdearia joined #salt
01:46 amcorreia joined #salt
01:48 ilbot3 joined #salt
01:48 Topic for #salt is now Welcome to #salt! | Latest Versions: 2015.5.10, 2015.8.10, 2016.3.1 | Support: https://www.saltstack.com/support/ | Logs: http://irclog.perlgeek.de/salt/ | Paste: https://gist.github.com/ (please don't multiline paste into channel) | See also: #salt-devel, #salt-offtopic | Ask with patience as we are volunteers and may not have immediate answers
02:03 Brijesh1 joined #salt
02:04 flowstate joined #salt
02:04 mpanetta joined #salt
02:16 Salander27 joined #salt
02:23 coldbrewedbrew joined #salt
02:23 coldbrewedbrew joined #salt
02:23 FreeSpencer joined #salt
02:23 FreeSpencer joined #salt
02:23 alinuxninja joined #salt
02:23 coldbrewedbrew_ joined #salt
02:26 whitenoise joined #salt
02:39 edrocks joined #salt
02:40 bastiandg joined #salt
02:42 ninjada joined #salt
02:44 benjiale joined #salt
02:46 ZachLanich joined #salt
02:55 fannet joined #salt
02:58 citaret joined #salt
03:04 flowstate joined #salt
03:04 pipps joined #salt
03:08 scsinutz joined #salt
03:10 jalbretsen joined #salt
03:12 iceyao_ joined #salt
03:24 sagerdearia joined #salt
03:28 bbradley joined #salt
03:28 citaret left #salt
03:43 stupidnic joined #salt
03:44 ageorgop joined #salt
03:45 bbradley joined #salt
04:05 flowstate joined #salt
04:08 evle joined #salt
04:10 IdoKaplan joined #salt
04:10 IdoKaplan Hi, i'm trying to find a solution to debug states and pillar locally. For example, I'm editing the state "/var/cache/salt/minion/files/dev/foo.sls" and running state.template and it's working. I'm trying to do the same on pillar, i.e, editing the file "/var/cache/salt/minion/pillar/cache.sls", but after I execute state.template or "salt-call pillar.items", the pillar that I changed was rollback to the previous value. Is there a way
04:14 hemebond IdoKaplan: Why are you editing the cache files?
04:15 IdoKaplan yes
04:16 hemebond :-D
04:16 DJ_Spies joined #salt
04:16 DJ_Spies left #salt
04:17 IdoKaplan https://docs.saltstack.com/en/latest/ref/configuration/minion.html#std:conf_minion-minion_pillar_cache
04:18 hemebond Why?
04:18 hemebond And have you disconnected from the master?
04:18 IdoKaplan easy to debug, making changes to states and pillar before git commit
04:19 hemebond Oh, you can only change the config on the master via a git push?
04:19 IdoKaplan this was a feedback from my developers that said that they need to commit git all the time before they checking that all is ok.
04:20 hemebond Makes sense.
04:20 IdoKaplan yes, and I don't want to give access to the developers to the salt master.
04:21 IdoKaplan yes, i agree with the developers so this is why i'm here :)
04:26 cyborg-one joined #salt
04:27 IdoKaplan So i'm trying this issue but I don't understand the syntax. " This allows a temporarily disconnected minion to access previously cached pillar data by invoking salt-call with the --local and --pillar_root=:conf_minion:cachedir/pillar options"
04:31 scsinutz joined #salt
04:34 IdoKaplan hembond: what do you think?
04:39 stupidnic joined #salt
04:41 XenophonF joined #salt
04:41 rdas joined #salt
04:41 edrocks joined #salt
05:04 flowstate joined #salt
05:07 raspy__ joined #salt
05:07 spuder joined #salt
05:15 mntest joined #salt
05:16 scsinutz joined #salt
05:21 mpanetta joined #salt
05:25 irctc892 joined #salt
05:25 Brijesh1 joined #salt
05:26 mntest left #salt
05:27 IdoKaplan joined #salt
05:27 IdoKaplan Hi, i'm trying to find a solution to debug states and pillar locally. For example, I'm editing the state "/var/cache/salt/minion/files/dev/foo.sls" and running state.template and it's working. I'm trying to do the same on pillar, i.e, editing the file "/var/cache/salt/minion/pillar/cache.sls", but after I execute state.template or "salt-call pillar.items", the pillar that I changed was rollback to the previous value. Is there a way
05:32 om joined #salt
05:34 hemebond joined #salt
05:35 ZachLanich hemebond or iggy: I've decided to use Peer Communication and a custom WP CLI command called sync-wpmdb-profile to get these keys synced. The question that I have is this:
05:36 hemebond peer communication?
05:36 ZachLanich How would I have this run on both minions, ensuring that the other minion is definitely fully provisioned and available?
05:36 ZachLanich What is the norm for having salt-call run on a minion on a regular basis? Job? Cron?
05:37 ZachLanich hemebond: It's Salt's ability for minions to run commands on the master, targeting only minions it's allowed to access, and specifying only the commands it's allowed to access.
05:38 hemebond Interesting. Sounds a bit too direct to me.
05:38 ZachLanich So a simple example would be: minion1 would run salt-call 'minion2' cmd.run 'wp wcutils sync-wpmdb-profile ...etc' and vice versa
05:39 hemebond Yeah, I get the idea.
05:39 nethershaw joined #salt
05:39 ZachLanich I might move to something less direct later, but it's easy to implement and I don't see it being a security issue right now
05:41 ZachLanich Another option is to have a minion send a custom event and have the others listening. And another option is to use a job/runner and have it periodically look at all minions, match up the Stage/Prod environments, grab the relevant secret keys and run the commands on the minions from top down. Either of those 2 might be better, but I'm going with PC for now to get it working so I can move onto other things for now.
05:41 ZachLanich So back to my two questions
05:43 harpo joined #salt
05:46 ZachLanich hemebond: Anything?
05:47 hemebond Sorry, I haven't used any of this stuff.
05:47 hemebond Oh, you can use Salt scheduler like cron.
05:48 ZachLanich Ok, so then this: How would I have this run on both minions, ensuring that the other minion is definitely fully provisioned and available?
05:49 kshlm joined #salt
05:49 hemebond orchestration
05:49 lovecraftian joined #salt
05:52 ZachLanich hemebond: Ah yes, I forgot about that
05:53 ninjada joined #salt
05:54 yidhra joined #salt
05:57 sagerdearia joined #salt
05:58 bocaneri joined #salt
06:04 flowstate joined #salt
06:06 ZachLanich I may not use Peer Communication then. I have to figure out the best way to use Orchestration for this.
06:06 yidhra joined #salt
06:11 josuebrunel joined #salt
06:13 iceyao joined #salt
06:21 felskrone joined #salt
06:27 nethershaw joined #salt
06:28 Miouge joined #salt
06:32 blueelvis joined #salt
06:35 POJO joined #salt
06:48 PerilousApricot joined #salt
06:52 ribx joined #salt
06:56 fannet joined #salt
06:58 toanju joined #salt
07:01 infrmnt joined #salt
07:04 flowstate joined #salt
07:04 fannet joined #salt
07:08 fracklen joined #salt
07:09 infrmnt joined #salt
07:28 Sylvain31 joined #salt
07:28 Sylvain31 hi
07:29 SirMikkalot joined #salt
07:30 AirOnSkin joined #salt
07:30 SirMikkalot iggy: I've tried a couple of sleeps at some places, but it doesn't seem to have the result, I'm looking for (a 'flawless' script wrt apt lock-ups)
07:30 SirMikkalot (<- MikkiWeesenaar)
07:32 fredvd joined #salt
07:36 ninjada joined #salt
07:44 ribx joined #salt
07:45 edrocks joined #salt
07:47 Rumbles joined #salt
07:52 josuebrunel joined #salt
07:56 irctc892 what will be the best best practice to store machine specific pillar data ?
07:57 irctc892 if I have 10 machine with 10 different set of machine specific data, how should I go about it ?
08:00 tho joined #salt
08:04 flowstate joined #salt
08:15 CeBe1 joined #salt
08:17 kshlm joined #salt
08:32 s_kunk joined #salt
08:32 s_kunk joined #salt
08:34 Pilbbq joined #salt
08:34 Pilbbq Hi
08:35 Pilbbq I'm looking on installing a salt minion on a RHEL6 ppc64 server, does anyone has ever done it ?
08:37 Pilbbq My problem is that it seem that :
08:37 Pilbbq Requires: python-crypto >= 2.6.1
08:37 Pilbbq Requires: python-tornado >= 4.2.1
08:38 Pilbbq And i can't find the appropriate rpm (for ppc64). I tried installing with pip instead but i can't make it work
08:39 babilen Pilbbq: Are you using packages from http://repo.saltstack.com/#rhel ?
08:39 babilen Ah, PPC .. not sure if they provide packages for that
08:40 babilen (Debian does)
08:40 Pilbbq Yeah I had no problem with my debian machine, but actually we have 2 ppc on rhel6 that i can't link to my salt master because of this
08:41 mage_ any idea why a 'not virtual_subtype:jail': (with a - match: grain) doesn't work anymore in 2016.3 ?
08:41 Pilbbq so I was wondering if anyone did it
08:41 babilen Pilbbq: What problems do you run into if you try the pip route?
08:42 Pilbbq babilen: and yeah i'm using the saltstack repo. I even tried the archive one to install and older version of the minion.
08:42 babilen mage_: What does "grain.get virtual_subtype" give you for that minion?
08:43 mage_ babilen: https://gist.github.com/silenius/11c5868156a561b6971e13afcc1e3a5a
08:43 Pilbbq babilen: the install works pretty well, but when i try to launch the minion i got this : http://pastebin.com/61Pqu78E
08:45 babilen mage_: -C "not G@virtual_subtype:jail" ?
08:45 mage_ babilen: yep it works like that :)
08:45 mage_ thanks
08:45 babilen mage_: I have no idea why what you used worked before as I expected "not" to be specific to compound matchers
08:46 mage_ it worked in 2015.8
08:46 babilen Which might have been a bug
08:46 mage_ I had https://gist.github.com/silenius/7fcfe82b5e15714e890f57631373a091
08:46 Pilbbq_1 joined #salt
08:47 Pilbbq_1 rrrr
08:47 Pilbbq_1 I just wanted to add that "futures" is installed without problem
08:48 babilen mage_: Yeah, I believe you that it might have worked before, but you want compound matchers for that
08:48 babilen Pilbbq_1: So .. you installed "futures" with pip also? (and please use a less horrible pastebin such as one of http://refheap.com, http://paste.debian.net, https://gist.github.com, http://sprunge.us, … )
08:49 Pilbbq_1 babilen: yep, that's right (sorry for the pastebin)
08:50 armin so the bash-completion for salt always completes ALL "foo.bar" commands i could execute on the minion(s), e.g. when doing: "salt '*' <TAB>". those are a hell of a lot of matches i get. shouldn't that only complete to the first level?
08:50 babilen Pilbbq_1: What does "pip show futures" give you?
08:50 Pilbbq_1 I've googled this for a while and i can"t find a way to solve it
08:50 babilen armin: That would be much nicer, yes
08:50 Pilbbq_1 i think maybe there is no "norach" version of my dependencies
08:52 ninjada joined #salt
08:53 Pilbbq joined #salt
08:53 Pilbbq rrrrrrrrrrrr
08:53 Pilbbq https://gist.github.com/anonymous/b8cf0ea26a4807518dd8056fd7bbb65f
08:54 babilen Pilbbq_1: Could it be that salt is running under Python 2.7 ?
08:55 jcalero joined #salt
08:56 Pilbbq well
08:57 BlackBishop https://paste.fedoraproject.org/400435/21461214/ why would one work (state.sls) and the other wouldn't (state.highstate) ?
08:59 GreatSnoopy joined #salt
09:03 ravenx joined #salt
09:03 flowstate joined #salt
09:07 AndreasLutro BlackBishop: state.sls doesn't involve top.sls, highstate does, you have an invalid regex in your top.sls by the look of things
09:07 AndreasLutro '*' is not a valid regex after all
09:09 BlackBishop true .. true ..
09:09 BlackBishop heh, just figured it out
09:10 BlackBishop I was reading https://github.com/saltstack/salt/issues/34379 and comparing ..
09:10 saltstackbot [#34379][MERGED] variable referenced before assignment | Description of Issue/Question...
09:10 BlackBishop then it hit me
09:10 BlackBishop so removed - match: pcre
09:17 fracklen_ joined #salt
09:22 kshlm joined #salt
09:24 jhauser joined #salt
09:26 jarvis what will be the best best practice to store machine specific pillar data ?
09:27 jarvis if I have 10 machine with 10 different set of machine specific pillar data, how should I go about it ?
09:32 ravenx from using local.get_cli_returns from here:  https://docs.saltstack.com/en/2015.8/ref/clients/index.html#salt.client.LocalClient.get_cli_returns
09:32 ravenx any i returns to me a <generator object get_cli_returns at 0x7ff8d1a0a280>
09:32 ravenx and i have no idea how to print it's contents
09:32 ravenx i've tried looping and yielding
09:32 ravenx and using .next(), but it keeps throwing the "StopIteration" error.
09:33 ninjada joined #salt
09:34 cztanu joined #salt
09:36 Rumbles joined #salt
09:38 N-Mi joined #salt
09:38 majuscule joined #salt
09:39 ravenx yyy
09:39 ravenx y
09:42 ravenx joined #salt
09:42 copelco joined #salt
09:43 philiaagape joined #salt
09:45 aljosa joined #salt
09:45 Elsmorian joined #salt
09:47 simonmcc joined #salt
09:47 czchen joined #salt
09:48 ravenx also, i am runner salt-master as a non root user and i cannot use salt-run
09:48 ravenx it says something about dmidecode being found in the path but ic annot use it.
09:48 ravenx :/
09:48 ravenx any help?
09:48 edrocks joined #salt
09:48 POJO joined #salt
09:49 phtes joined #salt
09:51 armin babilen: i came up with: salt '*' --timeout 2 --out=txt -- sys.list_functions | sed 's/^.*\[//' | tr -d ",']" | tr ' ' '\n' | cut -d"." -f 1 | sort | uniq
09:51 babilen ravenx: That's not a related error
09:51 ravenx babilen: what do you mean?
09:51 ravenx i think it is what's blocking me from using salt-run
09:51 armin babilen: but not sure how hard it would be to integrate that into the proper bash_completion.d/[...] file there.
09:51 babilen ravenx: The dmidecode error is unrelated to "i cannot use salt-run"
09:51 ravenx really now....
09:52 ravenx then what could it be then, as salt-run never does anything for me.
09:52 babilen What happens if you try?
09:52 ravenx let me paste it
09:52 ravenx babilen: https://paste.debian.net/786733/
09:52 babilen Also include debug logs from the master (and the salt-run invocation)
09:53 babilen ravenx: I get the same thing. Why do you think that you should get different output?
09:53 badon joined #salt
09:53 babilen ravenx: What does "salt-run fileserver.update" give you?
09:54 ravenx hang tight, i added the -ldebug flag, i got a bigger output
09:54 ravenx let me paste that to you
09:54 ravenx https://paste.debian.net/786734/
09:54 babilen That looks perfectly fine
09:54 ravenx for salt-run fileserver.update:
09:54 ravenx [WARNING ] Although 'dmidecode' was found in path, the current user cannot execute it. Grains output might not be accurate.
09:54 ravenx True
09:55 ravenx i got a true at the end.
09:55 babilen So, everything is working as expected
09:55 copelco joined #salt
09:56 ravenx o_O really now?
09:56 ravenx i dont know if i'm convinced though, cuz if i run jobs.exit_success <jid>
09:56 ravenx i have the same dmidecode error, and then nothing.  i would imagine that that would give me either a fail or a success message
09:57 babilen Why do you expect that?
09:57 ravenx since that checks for a JID's success
09:57 ravenx it should return a bool no?
09:57 ravenx a True or a False?
09:58 ravenx or does this function not do waht i think it does?
09:58 babilen I've never used it
09:58 ravenx basically i have a jid and i want to see if it failed or succeeded
09:59 babilen What are you trying to do?
09:59 babilen Okay
10:01 babilen And that runner doesn't do that?
10:01 ravenx nope, it returns nothing, aside from the dmidecode stuff.
10:01 babilen It doesn't seem to be available on my 2015.8.10 master
10:02 ravenx https://docs.saltstack.com/en/2015.8/ref/runners/all/salt.runners.jobs.html#salt.runners.jobs.exit_success
10:02 ravenx this function, no?
10:03 ninjada joined #salt
10:03 babilen What does "salt-run jobs.exit_success $SOME_JID" and "salt-run jobs.lookup_jid $SOME_JID" give you?
10:03 babilen (obviously use a real JID)
10:03 ravenx okay, so jobs.lookup_jid gives me the results of the highstate
10:03 ravenx (yup, using a real one)_
10:04 ravenx it's changes, comments, result, start_time, etc.
10:04 ravenx with exit_success, it prints the dmidecode stuff three times, with nothing else, and then does nothing.
10:04 babilen Does it contain retcode?
10:05 babilen I take it that you don't want to paste the exact output .. makes it harder to debug
10:07 ravenx the exact output of exit_success?
10:07 ravenx well it is only dmidecode's song and dance
10:07 babilen Of the two commands I mentioned
10:07 babilen That was the idea
10:08 ravenx nah, no retcode for that.
10:08 ravenx the two commands, yeah i can give you the output
10:08 babilen That would explain why exit_success is empty
10:08 ravenx but it just looks like a healthy highstate...
10:08 ravenx hm...so if i give a failed jid....
10:08 ravenx let me see
10:08 babilen I wanted to check very specific things
10:08 catpig joined #salt
10:08 ravenx babilen: sure give me a sec
10:09 babilen It just makes it harder to debug the problem. I can understand if you don't want to paste your entire highstate, but you could pick a different, less problematic, job
10:09 babilen Well, you already confirmed that it doesn't contain "retcode", which explains why exit_success comes back empty
10:09 babilen Took a bit longer to arrive there, but okay
10:13 samkottler joined #salt
10:14 babilen https://github.com/saltstack/salt/blob/2016.3/salt/runners/jobs.py#L516
10:14 babilen ravenx: See ^
10:14 babilen No retcode no content
10:14 SirMikkalot joined #salt
10:15 ravenx babilen: here is my ugly output of lookup_jid
10:15 ravenx http://paste.debian.net/786740/
10:15 ravenx pardon the ^]]35mm stuff
10:15 ravenx it took the coloring literally.
10:15 ravenx babilen: whaaaat no content....so does that mean i have to do echo $? on my shell?
10:15 babilen That would be true (as the salt command itself worked)
10:15 ravenx crap.
10:15 SirMikkalot iggy: It seems that there's something fishy with our 16.04 image. Might there be an incompatibility with 16.04 and the "2015.11.09"-bootstrap script?
10:15 ravenx -_-
10:15 ravenx then i dont understand why we have a exit_success
10:16 babilen ravenx: I do see 'retcode' in your paste, but with all those colours I can't tell what the actual output is
10:16 babilen Why does it look so shitty?
10:17 hexa- joined #salt
10:17 ravenx it's cuz i ran the command of jobs.lookup_id > output.txt
10:17 babilen ravenx: My impression that that exit_success should check for "result"
10:17 ravenx the coloring of highstates got translated it.
10:17 ravenx right i believe it does, but it does not report back to me.
10:17 ravenx meaning, it doesn't print or give anything i can work with.
10:18 p3rror joined #salt
10:18 sknebel joined #salt
10:18 Ouzo_12 joined #salt
10:18 Armadillo joined #salt
10:18 Jarus joined #salt
10:18 babilen No, it checks for 'retcode' and not 'result'
10:19 mschiff joined #salt
10:19 ravenx the retcode of the highstate?
10:19 mschiff joined #salt
10:19 babilen Take a look at the code I linked above .. Without having analysed that further it appears that the code should check 'result' rather than 'retcode' in the data returned from lookup_jid
10:21 mrud joined #salt
10:21 mrud joined #salt
10:21 copelco joined #salt
10:21 ravenx i see...
10:23 babilen Does that work?
10:24 ravenx not quite, cuz i didn't understand those lines lol
10:24 ravenx is the retcode something in the highstate?
10:25 babilen It's something that is returned by, for example, cmd.run ..
10:25 ravenx ah, so like  cmd.run 'some script'
10:25 babilen States typically contain "result" -- https://docs.saltstack.com/en/latest/ref/states/writing.html#return-data
10:26 babilen Another bug bites the dust
10:26 babilen ...
10:26 ravenx you found a bug?
10:26 ravenx right, that part i get, states containing results.
10:27 babilen Don't you consider the behaviour we see to be buggy?
10:27 ravenx yes we do
10:27 ravenx yes i do*
10:27 ravenx quite buggy.
10:29 babilen https://github.com/saltstack/salt/issues/35165
10:29 saltstackbot [#35165][OPEN] jobs.exit_success should check 'result' rather than 'retcode' | Description of Issue/Question...
10:29 babilen You are welcoime
10:30 ravenx wooo!
10:31 ravenx thanks babilen.
10:35 ninjada joined #salt
10:47 JohnnyRun joined #salt
11:09 amcorreia joined #salt
11:14 jkbbwr left #salt
11:16 evle joined #salt
11:30 kus joined #salt
11:34 jbax joined #salt
11:34 infrmnt joined #salt
11:45 lero joined #salt
11:45 ribx joined #salt
11:49 catpig joined #salt
11:51 edrocks joined #salt
11:53 Brijesh1 joined #salt
11:58 oida joined #salt
12:02 nicksloan joined #salt
12:04 Mate love to find the change in the diff of a merge commit released in a minor version
12:04 Mate that made our salt infra unusable
12:04 Mate https://github.com/saltstack/salt/commit/ae8ad9329ced2133145331afc18d1c2623445532#diff-2c20356d759feadcae8c50c2a46596c6 this one
12:05 Mate __opts__ doesn't even exist in the context we are using it
12:05 AndreasLutro what context is that?
12:06 Mate imported in a custom ext_pillar
12:06 Mate but 4 lines earlier the code handles this case
12:06 Mate but not in the unconditional return
12:11 AndreasLutro importing salt modules is such a pain, there's no clear distinction between modules that expect __opts__ etc to be defined and those that work standalone
12:11 AndreasLutro https://bpaste.net/show/aee2931dfec1 so annoying
12:12 Mate yes
12:12 Mate my other problem was that the pillar module catches the exception coming from 4 files away
12:12 Mate and prints the error message only
12:13 AndreasLutro lovely!
12:16 toanju joined #salt
12:21 irctc701 joined #salt
12:21 flower hey guys
12:22 flower i wanted to know is there any difference between `pillar.get('nginx', {})` and `salt['pillar.get']('nginx', {})` ?
12:24 hemebond flower: The latter is preferred.
12:24 babilen flower: There is .. the former uses the normal Python .get dictionary method and doesn't allow nested lookup, while the latter uses salt's "pillar.get" execution module function that allows nested lookups of "foo:bar:baz"
12:24 hemebond The former treats pillars like regular dicts, the latter has special abilities.
12:26 flower Thank you guys
12:27 edrocks joined #salt
12:28 mapu joined #salt
12:31 babilen It's a shame that Python doesn't have a method for nested lookups or setting values
12:35 armin joined #salt
12:36 nicola_pav joined #salt
12:36 armin joined #salt
12:37 nicola_pav hi. I am using salt-cloud to provision instances. I would like to run a custom script immediately after the salt-cloud can ssh to the instance before installing the salt minion
12:37 nicola_pav is there a way to do that?
12:38 nicola_pav I want to point my instance to a local repo, I want to add an entry in the /etc/hosts
12:38 syndikate joined #salt
12:41 west575 joined #salt
12:41 iceyao joined #salt
12:42 syndikate joined #salt
12:43 numkem joined #salt
12:43 gh34 joined #salt
12:45 syndikate joined #salt
12:51 numkem joined #salt
12:51 ninjada joined #salt
12:52 west575_ joined #salt
12:57 west575 joined #salt
12:59 syndikate joined #salt
13:02 syndikate joined #salt
13:02 west575_ joined #salt
13:06 traph joined #salt
13:06 traph joined #salt
13:10 subsignal joined #salt
13:11 lovecraftian joined #salt
13:13 Tyrm joined #salt
13:17 hemebond joined #salt
13:18 mapu joined #salt
13:22 jhauser joined #salt
13:24 west575 joined #salt
13:29 Brijesh2 joined #salt
13:29 Kruge joined #salt
13:29 Kruge hello
13:29 perfectsine joined #salt
13:30 slt joined #salt
13:31 Kruge I'm running a number of salt-minions under a master, both sides are at 2016.3.1, but the "partition.list /dev/sda" command I'm issuing reports that "partition.list is not available".  Anyone got any pointers as to what I'm doing wrong, please?
13:32 Ahlee typically that means a python module required isn't present
13:33 Brijesh1 joined #salt
13:33 Kruge hrm.  Would you expect all necessary modules to be pulled in by the minions?
13:33 Ahlee Entirely depends on how the minion was packaged/installed
13:34 PerilousApricot joined #salt
13:34 Kruge For what it's worth, I upgraded these from 2015.8.8 or so, pulled from the Ubuntu repos, and then added a source pointing to the salt repo to upgrade to 2016.3.1
13:35 Ahlee and partition.list worked in 2015?
13:35 Kruge I don't know, I only had the need to run it today, after upgrading
13:36 Kruge Oh wait, I'm lying.  I tried it on a 2015 and it didn't work
13:36 Ahlee reviewing https://github.com/saltstack/salt/blob/v2016.3.1/salt/modules/parted.py now
13:37 Kruge Well now.  I had a rogue 2015 laying around and just tried it, and magically it works
13:37 Brijesh1 joined #salt
13:37 Kruge and on a 2016 I installed straight from saltstack repos.
13:38 Kruge Not on the ones provisioned via the ubuntu repos and then upgraded though
13:38 mapu_ joined #salt
13:39 slt Hi! I have a masterless salt version 2015 5.10 running on Centos7.
13:39 slt salt and salt-minion packages were pulled from repo.saltstack.com
13:39 slt For some reason salt kept complaining that service module was not available.
13:40 slt One community member suggested me to edit minion configuration to add "providers: service: rh_service".
13:40 feld left #salt
13:40 slt With that, salt is able to find service module.
13:40 slt Why would the default minion configuration not able to locate service module?
13:40 babilen 2015.5.10 is a version I haven't seen in a long time
13:41 slt https://repo.saltstack.com/yum/redhat/7/x86_64/archive/2015.5.10/
13:41 babilen Yeah, 2016.3.1 is the current one
13:41 Sketch 2015.5.10 is the latest in epel for rhel6
13:42 Kruge Ahlee: Amusingly, that link defines some depends, the first two of which are not present on one of the systems partion.list isn't working on
13:42 Sketch (possibly also for el7)
13:43 slt This is on aws, we are building amis via salt, initially masterless config
13:43 Ahlee Rumbles: ah, the underlying applicattions it's calling out to
13:43 Kruge Ahlee: I installed the packages and it works now.  Cheers for prompting me.
13:43 Ahlee Kruge: hoorays
13:43 Sketch yep, it's also the latest for el7.
13:43 Kruge Any mileage in my opening a bug report for unsatisfied dependencies?
13:44 babilen slt: That bug might have been fixed in later versions
13:44 slt Do you all aware of any known issues with running 5.10 on EL 7 systems?
13:44 slt oh , ok
13:44 Ahlee Kruge: i don't recall reading anything about it previously, though i believe it's been discussed
13:45 Ahlee it's a grey area between packaging requirements
13:45 Ahlee since those packages are only required for partition, and i may not want/care/need
13:45 Ahlee *shrug*
13:45 Ahlee maybe better logging as to why the command didn't return
13:48 protoz joined #salt
13:51 babilen slt: https://github.com/saltstack/salt/pull/13766/files maybe
13:51 saltstackbot [#13766][MERGED] Fixes the problem where service module is unavailable on RedHat, CentOs  | Fixes the problem where service module is unavailable on RedHat, CentOs and Scientific Linux...
13:52 Kruge Thanks for the help Ahlee
13:52 slt OK, thank you guys, I just kicked off a new build using 2016 3.1,
13:53 toastedpenguin joined #salt
13:53 west575_ joined #salt
13:54 subsignal joined #salt
13:55 babilen slt: Ah, no .. that's in 2015.5
13:56 hemebond joined #salt
13:58 tpaul joined #salt
14:00 PerilousApricot joined #salt
14:00 Kruge Hmm.  Still not working.
14:01 mapu_ joined #salt
14:01 Kruge nm, me being silly.
14:03 DammitJim joined #salt
14:04 DammitJim is there a way to have salt run a mysql script?
14:04 flowstate joined #salt
14:05 DammitJim or do I just do a cmd.run ?
14:05 Tanta joined #salt
14:07 babilen https://docs.saltstack.com/en/latest/ref/states/all/salt.states.mysql_query.html ?
14:07 felskrone joined #salt
14:08 babilen But cmd.run should work fine
14:08 DammitJim thanks babilen mysql_query is to run a query directly?
14:08 DammitJim I have a sql file with a bunch of sql statements
14:08 babilen Yeah, a single query
14:08 DammitJim for cmd.run
14:09 DammitJim how do I make sure the thing doesn't get run again?
14:09 DammitJim meaning, I'm going to run this script to create a bunch of tables
14:16 tapoxi joined #salt
14:16 PerilousApricot joined #salt
14:17 POJO joined #salt
14:17 tapoxi so my salt-master is pegging a cpu core after going from 2016.3.1 to 2016.3.2, anyone see this before?
14:21 ribx joined #salt
14:22 emaninpa joined #salt
14:23 Sylvain31 hi, some formula to detect disk, add partion and add mount point in fstab?
14:26 rickflare_ joined #salt
14:31 babilen DammitJim: You could target it in a state that's part of a "bootstrap" process or only gets executed if a certain grain isn't set or ....
14:31 DammitJim oh, that's right! I can set a grain on the minion from my master, right?
14:31 DammitJim I've actually never done that
14:31 DammitJim yeah, tell me about bootstrapping a process
14:31 DammitJim like right now, I have a state that will copy the script over
14:32 DammitJim and run it
14:32 DammitJim how do I keep this together as a transaction and then set the grain
14:32 DammitJim next time this needs to run, it'll check the grain first
14:33 Sylvain31 why is module partition.mkfs limited in type? no ext4 for example
14:34 DammitJim is that what we call them? bootstraps? when one wants a "transaction?"
14:36 babilen DammitJim: I was thinking of states that you fire off when a minion comes online for the first time .. this could be done with the reactor, startup_states or orchestrate (and combinations thereoff). Also targeting based on grains and settings grains during states ...
14:37 DammitJim oh gosh... I have soooo much to learn
14:40 babilen DammitJim: My feeling is that just setting a grain and testing for it or targeting the state based on its absence is the easiest approach here. Something like "if salt['grains.get']('db:executed_setup', False)"
14:41 DammitJim when do I set it?
14:41 babilen Once you successfully ran the mysql command
14:41 hasues joined #salt
14:41 DammitJim to keep it as 1 transaction.. meaning, the mysql script needs to be successful before I set the grain
14:41 hasues left #salt
14:41 babilen Absolutely
14:42 DammitJim do I do in my state something like... set grain if cmd.run to run script?
14:42 babilen cmd.script might come in handy also
14:42 babilen No, you use requisites -- https://docs.saltstack.com/en/latest/ref/states/requisites.html
14:42 DammitJim oh ok, so cmd.script being the requisite to set the grain
14:42 DammitJim got it!
14:45 peters-tx Weird; my salt update state isn't updating 2016.3.1 to 2016.3.2 .. hmm
14:45 babilen You might need dist_upgrade=True
14:45 * peters-tx puts on the Sherlock hat and grabs a pipe
14:46 Tyrm joined #salt
14:48 Sylvain31 what would be the state arrangement to make a partion only if it doesn't exsist yet, or once.
14:48 Sylvain31 ?
14:48 _JZ_ joined #salt
14:50 spuder joined #salt
14:51 Sylvain31 I guess I sould use module.wait states with requisites, + parted.exists
14:51 stotch joined #salt
14:55 krymzon joined #salt
14:58 ZachLanich joined #salt
14:58 numkem joined #salt
15:00 jcalero Is anyone here setting up their salt-master using salt? I'd like to have something where I can target a machine and say, "make this my salt-master" using some defined salt state/pillar, and I'm curious to hear if it's sensible to do and how ppl do this..
15:01 ravenx is there anyway i can access old saltsatck documenmtation
15:01 jcalero at the moment I'm trying with salt-ssh using the salt-formula, and it works ok, but not too happy with it
15:01 ravenx instead of the stable, latest and develop branch?
15:01 JohnnyRun joined #salt
15:01 gtmanfred ravenx: on github, just go to the branch for your release, and clone it, then make the docs
15:02 gtmanfred jcalero: https://github.com/saltstack-formulas/salt-formula
15:02 gtmanfred ahh,nevermind
15:02 gtmanfred that is the way I would do it
15:02 Tanta_G joined #salt
15:03 jcalero and using salt-ssh?
15:03 ravenx how do you make the documentation?
15:03 west575 joined #salt
15:03 gtmanfred jcalero: that is how I would do it
15:04 gtmanfred ravenx: https://docs.saltstack.com/en/latest/topics/development/conventions/documentation.html#building-the-documentation
15:04 ravenx ty
15:05 flowstate joined #salt
15:05 jcalero fair enough, thanks gtmanfred, at least I'm on the right track then
15:08 jhauser joined #salt
15:08 ravenx gah, i can't seem to find this pacakge:  ailed to import 'salt.proxy.junos': no module named salt.proxy.junos
15:08 ravenx the heck is a proxy junos
15:08 gtmanfred it is a proxy module in salt/proxy/junos.py
15:09 ravenx hm, okay i do see it.
15:09 Brijesh1 joined #salt
15:10 west575_ joined #salt
15:12 salterman joined #salt
15:13 salterman left #salt
15:15 slt Hi, I asked a question about service module on Centos7 earlier, I tried 2016.3.1, and failed, now I am trying with 2015.8.11
15:15 johnkeates joined #salt
15:15 slt I had to edit minion configuration for providers: service: rh_service,
15:15 slt I guess that one is for state module, now I have a new error:
15:15 slt Reason: 'service' __virtual__ returned False: No service execution module loaded: check support for service management on CentOS Linux-7
15:16 slt is there another provider that I can specify for service execution provider in minion configuration?
15:16 gtmanfred that should be the correct one, you shouldn't need to specify it either, it should autodiscover and use the correct one
15:17 gtmanfred actually
15:17 gtmanfred it should be systemd
15:17 gtmanfred set service='systemd
15:17 gtmanfred or service: systemd
15:17 slt in where?
15:17 slt minion conf?
15:17 gtmanfred you shouldn't need to set it... you said you had set it somewhere?
15:18 slt yes I did in the /etc/salt/minion
15:18 gtmanfred hrm
15:19 gtmanfred yeah, you shouldn't need to do anything, it should recognize that it is systemd and use it
15:19 gtmanfred does /run/systemd/system directory exist?
15:19 slt no
15:19 corichar joined #salt
15:20 gtmanfred that is the problem, sounds like your generator might not have run at the bootup
15:20 slt I have other directories in there but no system
15:20 gtmanfred can you do `cat /proc/1/cmdline`
15:21 slt sbin  init
15:21 slt `/sbin/init`
15:21 gtmanfred and `ls -l /sbin/init`
15:22 Brew joined #salt
15:22 slt `/sbin/init -> ../lib/systemd/systemd`
15:22 debian112 joined #salt
15:22 Salander27 joined #salt
15:23 gtmanfred find /etc/systemd/system -name \*.service
15:23 gtmanfred find /etc/systemd/system -name \*.service | curl -F 'f:1=<-' ix.io
15:23 gtmanfred and gimme the link
15:23 bowhunter joined #salt
15:24 slt http://ix.io/1aqb
15:24 gtmanfred so, it should be running something that makes /run/systemd/system, which is what systemd.is_booted checks for
15:25 gtmanfred so... mkdir /run/systemd/system and then it should load the systemd module
15:25 gtmanfred i don't know why systemd on your system is not making it
15:25 gtmanfred https://github.com/saltstack/salt/blob/develop/salt/utils/systemd.py#L18-L33
15:26 slt This is a funky build, it is actually built in chroot'd environment off of another linux system, devs are created, then yum install @base in the chroot
15:26 gtmanfred that is the function that is used to determine if you booted with systemd, and it matches the sd_booted functino that they use
15:26 gtmanfred that shouldn't matter, cause /run should be a tmpfs mount, and remade on each boot
15:28 slt I will try the build with mkdir /run/systemd/system again,
15:29 slt I am not all that familiar with how the build actually works but off of a running linux instance running say amazon ami, they create a chrooted environment, group install base packages for centos7
15:31 gtmanfred are you running this as a container? with chroot?
15:31 slt so this system is not bootup in conventional sense, may be thats the reason, I don't know
15:31 gtmanfred is there a reason not to use lxc or systemd-nspawn?
15:31 evle joined #salt
15:32 slt no, containers, just a aws linux instance spun up, then install centos 7 on a chroot environment off of that instance, then they run salt, finally create a snapshot of that centos7 and save as new aws ami
15:33 gtmanfred so the chroot runs salt?
15:34 slt yes salt-call is ran inside the chroot centos7
15:34 slt salt is ran to prepare    configurenew centos ami
15:34 gtmanfred i would say that is probably the reason, better to use lxc or systemd-nspawn and make it into a container
15:35 gtmanfred otherwise you probably want to mount -o rbind /dev and /sys and /proc into the chroot
15:35 flowstate joined #salt
15:35 slt do you all use that method to create say ami s?
15:35 gtmanfred (nspawn and lxc provide sys dev and proc to the container, but seperate them from the master unlike the chroot)
15:35 gtmanfred i just use the centos7 ami, and image off of that
15:37 slt yeah, I don't know why they use this method but, it is fairly complicated setup, just trying to get it work w/o understanding it first :)
15:37 slt Thank you
15:38 jxm_ joined #salt
15:38 gtmanfred no problem
15:43 new_salty joined #salt
15:46 peters-tx I have an issue with the Announcement "Deprecated paths on repo.saltstack.com will be removed in Carbon" at https://groups.google.com/d/msg/salt-announce/y31sz9_AX-g/ReOW2wI6BAAJ ; who should I contact?
15:47 peters-tx gtmanfred, Actually I think you gave this to me yesterday :)
15:47 scsinutz joined #salt
15:47 new_salty Hi, I recently discovered salt and making my first steps now. I just need a short hint: I want to execute a spcific command if a pkg.installed really installed the package and a different command if it was only updated. (no command if there was now change). Can someone help me on that?
15:47 gtmanfred carbon is not out yet
15:47 gtmanfred they should still be there for the older versions
15:48 peters-tx gtmanfred, Actually I need to notify the poster that there is a catch when using RHEL5 and a proxied environment
15:48 scsinutz joined #salt
15:48 gtmanfred peters-tx: make it on github.com/saltstack/salt-pack
15:48 gtmanfred an issue*
15:48 peters-tx gtmanfred, Ok, perfect; thanks
15:48 gtmanfred new_salty: i do not believe you can do that exactly, because it treats updating and installing as the same thing
15:49 gtmanfred new_salty: actually
15:49 gtmanfred new_salty: pkg.installed will only install it once, it won't update, pkg.latest will continuelly update
15:49 gtmanfred so you could have two states, one that makes sure it is installed, and do your first step on_changes for that, and then make another state the is pkg.latests that comes after pkg.installed so on the first install it does nothing, but have an onchanges on that that does the second thing
15:51 gtmanfred new_salty: http://ix.io/1aqC then you could have two different onchanges states, but since installed was first, it will install the first time before the latest, so only that onchanges will take effect
15:51 new_salty gtmanfred: thank you for the quick response! I will try this setup, as it sounds exacly like what I want.
15:52 dfinn joined #salt
15:52 new_salty where would I put the cmd.run then?
15:52 scsinutz joined #salt
15:53 gtmanfred you would have another stateid in ther ethat was the cmd.run, and you would reference it in the onchanges
15:53 gtmanfred instead of the file:thing or file:thing2
15:54 new_salty thank you
15:58 my10c left #salt
15:58 my10c joined #salt
16:03 dyasny_ joined #salt
16:03 flowstate joined #salt
16:04 Edgan joined #salt
16:07 writtenoff joined #salt
16:14 antpa joined #salt
16:19 Edgan jfindlay: 2016.3.2 is out, topic?
16:20 UForgotten so I have a server that died - when it died I did a salt-key -d on the master - I dont see anything for it in the /etc/pki on the master.  I rebuilt the machine, and now the master rejects the minion's key. What am I missing?
16:20 UForgotten both have been restarted.
16:20 UForgotten it is a new minion key, not copied from anywhere.
16:21 Edgan UForgotten: Is it set to auto accept, or you manually accept?
16:21 dyasny_ joined #salt
16:22 UForgotten Edgan: I should have to manually accept. but its not in the list
16:22 Edgan UForgotten: what does the /var/log/salt/minion log say on the minion?
16:23 Topic for #salt is now Welcome to #salt! | Latest Versions: 2015.5.11, 2015.8.11, 2016.3.2 | Support: https://www.saltstack.com/support/ | Logs: http://irclog.perlgeek.de/salt/ | Paste: https://gist.github.com/ (please don't multiline paste into channel) | See also: #salt-devel, #salt-offtopic | Ask with patience as we are volunteers and may not have immediate answers
16:26 Pulp joined #salt
16:26 Edgan jfindlay: thanks
16:28 smcquay joined #salt
16:29 UForgotten Edgan: "The Salt Master has rejected this minion's public key!"
16:29 smcquay joined #salt
16:31 onlyanegg joined #salt
16:32 babilen UForgotten: Did you remove the key?
16:33 babilen (the old key that is)
16:33 UForgotten yes - as per my original message :)
16:33 babilen How did you do that?
16:34 babilen But if it is gone from /etc/pki then it should be gone from the master. Maybe it still lingers in some datastructures .. restarting the master might help or might not change anything
16:34 UForgotten I salt-key -d a long time ago
16:34 krymzon joined #salt
16:35 UForgotten and restarted the master again recently
16:35 UForgotten did not help. something has the key cached and I dont see where it is.
16:36 Edgan UForgotten: You can't just salt-key -A ?
16:36 UForgotten no because its not in the list
16:37 UForgotten its rejecting the key in the first place
16:37 Edgan UForgotten: You sure it is actually talking to the right salt master?
16:37 Edgan UForgotten: Is the hostname defined in /etc/salt/minion, or are you relying on the default of salt?
16:41 UForgotten I set master in /etc/salt/minion
16:41 ageorgop joined #salt
16:41 jenastar joined #salt
16:41 spuder joined #salt
16:41 edrocks joined #salt
16:42 subsignal joined #salt
16:42 Edgan UForgotten: Do a dns lookup on the minion of that hostname, and make sure it matches the ip address of the master you are checking
16:43 ninjada joined #salt
16:45 UForgotten ah. I think its the minion sending an old master key.  I'll try killing minion's pki
16:45 cyborg-one joined #salt
16:46 UForgotten nope. sigh.  it "should" be going to the right master. master: salt01 and host salt01 match
16:46 UForgotten nope. sigh.  it "should" be going to the right master. master: salt01 and host salt01 match the right master server
16:46 Edgan UForgotten: try the reset idea
16:51 jxm_ joined #salt
16:52 ZiLi0n joined #salt
16:53 UForgotten I did kill the pki it iddint work
16:54 UForgotten only on the minion tho. I am not killing pki on the master, too many machines to rekey
16:55 Edgan UForgotten: /etc/salt/pki/master/minions_denied?
16:56 antpa joined #salt
16:56 ZiLi0n Hello everyone, I am trying to listen for an event up in the master, then react based on it, and do something from the master. To listen for events I am using the reactor, to react I have a sls file mapped to the corresponding event. Now, what I would like is to run a salt module in the master, not in the minions. I have seen that I could call a Runner from the reactor sls file, but can the runner call salt modules?, like __salt__('cmd.run')? Other
16:56 ZiLi0n option is to skip the reactor altogether and listen to events from an external python script, but are the salt modules available there? Not sure which option is the best, but having access to salt modules is very important
17:01 babilen Edgan: He said that there is no sign of the key in /etc/salt/pki/*
17:01 babilen (we could verify that, but I am believing that so far)
17:02 flowstate joined #salt
17:06 Fiber^ joined #salt
17:07 lero joined #salt
17:07 cprior joined #salt
17:14 Edgan babilen: he said salt-key didn't show it
17:15 Edgan babilen: But we have no reason for the server to not show it but the minion saying it is rejected
17:15 armyriad joined #salt
17:17 armyriad joined #salt
17:19 pipps joined #salt
17:26 Miouge joined #salt
17:28 UForgotten Edgan: I did a find on /etc/salt on the master and looked for the hostname, its not there.
17:29 UForgotten The next step may be to bump up the logging on both.  It could easily be something dumb but I thought I was being proactive by removing the key before I rebuild the server :)
17:30 Edgan UForgotten: I would start with trace on the minion
17:31 babilen Edgan: I totally agree .. which makes this mysterious
17:32 andrei89 joined #salt
17:32 fredrick joined #salt
17:47 t0m0 joined #salt
17:49 UForgotten ah. got it
17:49 UForgotten minion_id was wrong
17:49 UForgotten working now :derp:
17:49 pipps joined #salt
17:50 krymzon joined #salt
17:51 dyasny joined #salt
17:55 Edgan UForgotten: That had crossed my mind, but seems like that would be noticed
17:56 badon joined #salt
17:57 FreeSpencer joined #salt
17:57 FreeSpencer joined #salt
17:57 coldbrewedbrew joined #salt
17:57 coldbrewedbrew joined #salt
17:57 coldbrewedbrew_ joined #salt
18:01 sagerdearia joined #salt
18:03 heaje joined #salt
18:03 flowstate joined #salt
18:07 amcorreia joined #salt
18:13 alinuxninja joined #salt
18:13 coldbrewedbrew_ joined #salt
18:13 honestly
18:15 west575_ joined #salt
18:18 MohShami joined #salt
18:19 MohShami hey guys, I upgraded to 2016.3.1 and now one of my orchestrators is not working properly. at one of the stages it does a git.latest, while on 2015.8 the orchestrator would wait for git.latest to wait before finishing the other steps, now it just keeps it running in the background and finishes the other steps which causes the whole operation to fail. Is there something I should change or at least some documentation I can look at. Been working on this for da
18:19 MohShami ys with no luck
18:20 west575 joined #salt
18:24 Edgan MohShami: One thought, make the git.latest a requirement of the things after it that depend on it
18:24 MohShami @Edgan, here is my state
18:24 MohShami http://pastebin.ca/3672890
18:25 MohShami I tried both watch and require under "{{ website }}_setPermissions"
18:25 edrocks joined #salt
18:25 UForgotten Edgan: yeah, I would have noticed too but it didnt log the hostname in info, and I 'assumed' it was correct. silly me hehe
18:25 west575_ joined #salt
18:26 Edgan UForgotten: yeah, sadly even debug doesn't help sometimes. I regularly have to use trace.
18:27 Edgan MohShami: need to see the deploy.git state
18:28 johnkeates left #salt
18:28 Edgan MohShami: This sounds like your problem, https://github.com/saltstack/salt/issues/18564
18:28 saltstackbot [#18564][OPEN] salt-run state.orchestrate fails because it tries to run a second task while a first is ongoing | To start off with, this problem seems somehow related to disk speed. We can reliably reproduce the problem on sata backed virtual machines, but not on ssd backed virtual machines. (Two different openstack flavors on for the rest the same hardware.)...
18:28 MohShami Edgan: sure, here you go http://pastebin.ca/3672892
18:29 MohShami Edgan: This was working perfect on both 2015.5 and 2015.8
18:29 MohShami the problem surfaced on 2016
18:30 Edgan MohShami: could be a race condition
18:31 Edgan MohShami: he says he sees differences between non-SSD and SSD systems
18:31 MohShami all git.latest operations are done over the network
18:31 MohShami either on a LAN or over the internet
18:31 Edgan MohShami: I think I see the issue
18:31 IdoKaplan joined #salt
18:31 Edgan MohShami: from reading the bug
18:32 IdoKaplan Hi, i'm trying to find a solution to debug states and pillar locally. For example, I'm editing the state "/var/cache/salt/minion/files/dev/foo.sls" and running state.template and it's working. I'm trying to do the same on pillar, i.e, editing the file "/var/cache/salt/minion/pillar/cache.sls", but after I execute state.template or "salt-call pillar.items", the pillar that I changed was rollback to the previous value. Is there a way
18:32 Edgan MohShami: Each salt command has a timeout
18:32 Edgan MohShami: So git runs, but takes longer than the timeout, and keeps running
18:32 Edgan MohShami: but salt continues to the next step
18:32 Edgan MohShami: So you get what seems to be concurrent execution
18:33 Edgan MohShami: The workaround is to increase the timeout
18:33 Edgan MohShami: maybe the timeout default changed in 2016
18:34 MohShami Edgan, that worked for other states. but git.latest fails when I add a timeout
18:34 Edgan IdoKaplan: Stop screwing with the cache :P Solutions that come to mind for local development are salt-call in a vagrant VM, salt-ssh against a vagrant VM, or salt-master running in a vagrant VM
18:35 MohShami Edgan:  "The following keyword arguments are not valid: timeout=600"
18:36 Edgan MohShami: It is a salt master setting
18:36 MohShami I tried adding it to deploy.init
18:37 Edgan IdoKaplan: Also https://github.com/simonmcc/kitchen-salt
18:37 MohShami that seems to have done the trick
18:38 MohShami edgan: is the global option "gather_job_timeout"
18:38 Edgan MohShami: try setting timeout to 300 in /etc/salt/master, timeout: 300
18:39 Edgan MohShami: From reading the docs and the issue I mentioned above
18:39 Edgan MohShami: The author of the issue is unclear which settings, but it sounds like just timeout
18:39 MohShami edgan: checking, I reset all timeouts from my states and just added timeout: 600 in master
18:40 Edgan "While the schedule is enabled, we see this issue regularly...especially on longer orchestration states. if we disable the schedule using salt \* schedule.disable then run the orchestration state, it runs without failure."
18:40 Edgan IdoKaplan: https://github.com/simonmcc/kitchen-salt is another solution
18:40 Edgan MohShami: So this is another potential workaround
18:41 MohShami Edgan, thanks a million mate :)
18:41 alinuxninja joined #salt
18:41 MohShami but wouldn't increasing the timeout variable make everything take longer
18:42 MohShami like for example, salt '*' test.ping with unconnected minions
18:42 MohShami that would take ages now, right?
18:42 Edgan MohShami: it is just the max it will wait for one job to complete
18:42 Edgan MohShami: Shouldn't actually break anything. Since I would expect the run to fail on the timeout of anything
18:43 Edgan but instead it continues
18:43 MohShami I assume as much, but instead of salt returning with an error when a minion is not connected in 5 seconds, it will take 10 minutes (since my timeout value is 600, not 300)
18:44 tapoxi joined #salt
18:44 Edgan MohShami: the schedule solution might be better
18:44 tapoxi what syntax is preferred for states? name passed as - name or name being the id?
18:45 MohShami Edgan, adding a timeout for individual states works as well
18:45 Edgan tapoxi: I prefer - name, because name by id can end up with duplicates
18:45 MohShami Edgan: I think I'll stick with that till I get more testing, I'm not familiar with schedule to judge
18:46 tapoxi Edgan if one sls includes another, do they share a namespace?
18:47 Edgan tapoxi: global name space for ids
18:48 tapoxi Edgan great thanks, guess I'll be careful with naming ids
18:49 MohShami Edgan, thanks a million mate :)
18:49 Edgan MohShami: you are welcome
18:58 edrocks joined #salt
19:01 pipps joined #salt
19:01 ajw0100 joined #salt
19:02 fracklen joined #salt
19:03 flowstate joined #salt
19:03 andrei89 joined #salt
19:07 dyasny joined #salt
19:08 timoguin joined #salt
19:11 jenastar joined #salt
19:12 ZiLi0n Hello everyone, how can I call a module from a runner?
19:14 evle joined #salt
19:15 ZiLi0n I am trying with __salt__['salt.<module_name>.<modfule_function>'](args...)
19:15 whytewolf ZiLi0n: a runner runs on the master and exacution modules run on minions. so you might need to look at using something like this. https://docs.saltstack.com/en/2015.8/ref/clients/index.html#localclient
19:15 iggy ZiLi0n: you would call a module on a minion, so use the local client functions
19:15 ZiLi0n but I get always KeyError
19:15 ZiLi0n is there a way to execute the module at the master/
19:15 ZiLi0n ?
19:16 iggy even if you were in minion context, it would be just '<mod>.<func>' (no salt.)
19:16 whytewolf ZiLi0n: have a minion on the master and target it
19:16 ZiLi0n I am looking at this: https://docs.saltstack.com/en/develop/ref/runners/all/salt.runners.salt.html#salt-salt-runner
19:17 ZiLi0n whytewolf that sounds good, but is there a way to kind of set that minion so that it is only targeted for this runner, and not targeted when doing salt *. I am worried that someone tries salt * and then targets the master by mistake
19:19 ZiLi0n iggy whytewolf reading that webpage I believe it means that it shoiuld be possible to run execution modules at the master
19:19 whytewolf ZiLi0n: exacution modules are not in the same context as runners
19:20 ZiLi0n :(
19:20 ZiLi0n what if I had an external script listening to events, could I run execution modules?
19:22 Elsmorian joined #salt
19:23 whytewolf oh wow, that is an approch.... apperentl that salt runner actually loads the minion_mods loader
19:24 whytewolf https://github.com/saltstack/salt/blob/develop/salt/runners/salt.py
19:24 pipps joined #salt
19:24 om joined #salt
19:30 tho joined #salt
19:32 pipps joined #salt
19:33 scsinutz joined #salt
19:33 iggy the problem isn't if you can... it's should you
19:33 iggy I mean it's python, you can run whatever you want to run in various forms of ugliness
19:33 iggy but _should_ you
19:35 om joined #salt
19:37 ZiLi0n iggy only I want is the master run one execution module for few events
19:37 andrei89 joined #salt
19:37 ZiLi0n so If I get develop code, that is suppose to be there right? (it says new in Carbon release)
19:38 iggy I guess I'm failing to see why you would need to do it that way
19:38 iggy just use local client and target the module.func at the minion that runs on the master
19:39 ZiLi0n but the minion is down in my case, how can I still use some module?
19:40 felskrone joined #salt
19:41 whytewolf honestly I'm still trying to think of what business logic is involoved in running a exacution module on the master to begin with.
19:41 iggy ditto
19:42 ZiLi0n so imagine you want to send an email when one minion goes down, there are nice execution modules already done for that, it would be great if the master can do it, because as the minion is down, there is no minion to do it
19:42 ZiLi0n is that achievable in some other fashion?
19:42 iggy just use python
19:43 whytewolf ^^
19:43 iggy at that point it sounds like you're worried about the state of anything salt anyways
19:43 iggy better to just go lower level to python
19:43 amcorreia joined #salt
19:44 ZiLi0n ok, I see, so should I do all custom python at the runner module?
19:44 whytewolf besides. here is a question. how is your runner going to know the minion is down?
19:44 whytewolf it isn't like there is a constent ping
19:45 PryMar56 joined #salt
19:45 ZiLi0n whytewolf yes, you can enable presence_events for that
19:45 iggy yeah, this sounds like a better job for a monitoring system
19:45 whytewolf thats what i was thinking iggy use the right tool for the job instead of trying to reinvent the wheel in another tool
19:46 lorengordon do you _need_ to use a runner? you could install a minion on the master to use the execution module
19:46 barmaley joined #salt
19:46 whytewolf lorengordon: we went over that also. he is scared of someone running a salt command that hits * and does something on the master
19:47 lorengordon ahh, my eyes glazed over that
19:47 ZiLi0n lorengordon that is true, but I would like to only target this minion at the master for monitoring events only. I am worried that someone could do salt '*' state.sls custom_upgrade_states which would upgrade also the master, it would be a risk I think
19:47 lorengordon umm, yeah, maybe investigate restricting user privs as well :D
19:48 ZiLi0n hehe :) that is true too
19:49 whytewolf what you mean everyone shouldn't be able to salt '*' cmd.run 'dd if=/dev/zero of=/dev/sda'
19:49 whytewolf :P
19:49 ZiLi0n haha
19:49 lorengordon i remember seeing movement on whitelist/blacklist features you could use to restrict what users can do, not sure what release that's in
19:49 ZiLi0n Boron
19:50 scsinutz1 joined #salt
19:50 whytewolf iirc it is tied to this https://docs.saltstack.com/en/2015.8/topics/eauth/index.html
19:50 lorengordon cool. can you blacklist * from matching the master?
19:51 whytewolf it is based on function not on state or minion :/
19:51 lorengordon blech
19:51 scsinutz joined #salt
19:51 lorengordon well, you could just use the master minion in local mode
19:51 scsinutz joined #salt
19:51 lorengordon don't accept a key to the master minion on the master
19:51 whytewolf or, I don't know. use a monitoring ssytem
19:52 lorengordon lol
19:52 om joined #salt
19:53 whytewolf least that way if you lost your salt master you could still have info into what is going on
19:53 ZiLi0n thanks a lot, this is all great feedback!
19:54 armyriad joined #salt
19:55 whytewolf hum, they did are an arg function to the acl system. so you could limit say state.sls burn-the-world to only dr_evil
19:55 whytewolf but nothing about targetting :/
19:55 ZiLi0n :(
19:56 ZiLi0n well, ok, I think I am going to develop custom python within the runner
19:56 ZiLi0n will give that a try
19:57 pipps joined #salt
19:59 whytewolf yay the salt.rabbitmq_user issue with rabbit newer then 3.5 is finally fixed
20:02 flowstate joined #salt
20:02 babilen One bug down .. twenty new have been implemented ;)
20:03 lorengordon bug implementation, i like it
20:03 permalac joined #salt
20:04 krymzon joined #salt
20:05 cprior When I found a bug fixed in a PR the joy set in when I realized how trivial salt can fix its own files! :)
20:06 subsignal joined #salt
20:07 ajw0100 joined #salt
20:12 armyriad joined #salt
20:12 mapu_ joined #salt
20:13 pipps joined #salt
20:20 GreatSnoopy joined #salt
20:21 toastedpenguin joined #salt
20:29 Brew joined #salt
20:31 codehotter joined #salt
20:31 ]V[ joined #salt
20:35 cyrus_mc left #salt
20:36 ribx joined #salt
20:39 pipps joined #salt
20:45 ninjada joined #salt
20:46 rovar joined #salt
20:46 timoguin_ joined #salt
20:46 rovar hey all.. I'm having an issue passing a simple variable in my salt state that I want to define as "*"
20:46 rovar Rendering SLS 'base:role.web' failed: expected alphabetic or numeric character, but found '\n'; line 544
20:47 rovar welcome_email_service_domains: *    <======================
20:47 rovar I'm enclosing it in double quotes, but they seem to be getting stripped..
20:47 whytewolf lets see the state
20:49 rovar hmmm..
20:49 rovar it looks like   setting   welcome_email_service_domains: "'*'"  produced the correct result.
20:49 rovar the state just renders it to another yaml file.
20:50 rovar that is the config for my app
20:51 rovar {% set app_yml = pillar['coldfusion_app_yml'] %}    -- then   {% for k in app_yml %}   {{ k }}: {{ app_yml[k] }}
20:52 juanito joined #salt
20:56 hoonetorg hi
20:56 hoonetorg on saltconf16 somebody showed new strategy
20:57 hoonetorg to merge pillars (pillar merge util function)
20:57 hoonetorg i forgot the exact name
20:57 hoonetorg u no wt i mean :)
21:03 sfxandy joined #salt
21:04 sfxandy hi everyone
21:04 flowstate joined #salt
21:05 om joined #salt
21:06 sfxandy I have a question about a call to Salt mine from within a state.  is it possible to make the call dynamic i.e. based upon a Jinja variable for Pillar or grain matching?
21:06 hoonetorg seth house and gary richmond talked about this new function/whatever in saltstack configuration management best practices on saltconf16
21:07 hoonetorg i made a bookmark - but it's gone :(
21:07 hoonetorg can someone here remember on a new salt function to merge pillars for map.jinja files in formulas or so ???
21:08 hoonetorg it was on the last day 3:45pm -
21:10 hemebond hoonetorg: 3:45pm in which timezone?
21:12 hemebond Oh, nevermind, I haven't been logging the channel.
21:13 IdoKaplan Hi, i'm using file.managed and I have an issue with jinja. I would like to print "-i bond0", but the print is "{{ ethernet0 }}" . http://pastebin.com/n9gAdVVg    Can you please help?
21:13 mapu joined #salt
21:13 hemebond IdoKaplan: You are inside Jinja. {{ }} is not used within Jinja.
21:14 hemebond Just concatenate the string with ~
21:14 sybix joined #salt
21:15 hoonetorg hemebond: SLC last day of saltconf16 3:45pm (what time zone ? - mountain time ?0
21:15 hoonetorg found it https://github.com/saltstack/salt/blob/develop/salt/modules/slsutil.py#L37
21:15 hoonetorg slsutil.merge
21:16 hemebond Interesting.
21:16 hoonetorg hemebond not in irc
21:16 hoonetorg was on a saltconf session :)
21:19 hoonetorg hemebond and here an example https://github.com/saltstack/salt/issues/3991
21:19 saltstackbot [#3991][OPEN] Feature request: `extend` functionality in pillar .sls | Currently defining defining pillar key the second time will overwrite the contents of the first definition, i.e.:...
21:20 hoonetorg near the end example from danlsgiga
21:20 CampusD joined #salt
21:20 hoonetorg that's what i wanted to find
21:20 hemebond ah
21:20 hoonetorg so multiple pillars and maps can be merged together deep now
21:20 hoonetorg yeah
21:21 hoonetorg not always repeating the whole pillar if only one opt changes :+1:
21:26 Elsmorian joined #salt
21:29 cyborg-one joined #salt
21:32 Edgan joined #salt
21:32 IdoKaplan hembond: thank  you. this is working - '-A INPUT -i ' ~ ethernet0     But how can I add more words after "ethernet0" in the same line?
21:33 hemebond IdoKaplan: http://jinja.pocoo.org/docs/dev/templates/#other-operators
21:34 fredrick joined #salt
21:35 fredrick When someone runs pillar.items how can I hide keys in pillar.items?
21:35 hemebond fredrick: You can't.
21:35 fredrick Not even with gpg?
21:36 IdoKaplan 10x . thank you again!
21:36 hemebond It would still be decrypted, no?
21:36 hemebond I'm not sure where the GPG elements get decrypted.
21:36 hemebond But Pillar is for providing data to minions.
21:37 fredrick Understood, just have devs get sudo once in a while and would be nice to be able to hide.
21:38 mavhq joined #salt
21:38 hemebond Yeah, if they have access to your master they have access to everything connected to it :-)
21:38 hemebond Might be some minor exceptions or ways to restrict them but, as a general principal it works.
21:38 fredrick No they have access to salt-call
21:39 hemebond Oh on local machines.
21:39 hemebond Well, this is one of the reasons using Grains to control access to Pillar data is insecure; if they change the Grains they change the Pillar data available to the minion.
21:40 hemebond If they have sudo surely they can just look into config files.
21:40 fredrick No so say they are working on hooli app and the server it is on  is needed for debug.
21:40 fredrick they run salt-call pillar.items they can see ssh keys
21:41 fredrick actually i gpg those files.
21:41 fredrick so they would have to have the master to see.  But good point.  if they want they would still get.
21:41 hemebond Where does the decrypting happen?
21:42 hemebond You say you GPG the files... how do they get decrypted for actual use?
21:42 fredrick No you are correct they would have access to them as sudo anyways.
21:44 scsinutz joined #salt
21:44 Edgan whytewolf: which rabbitmq user issue?
21:44 Edgan whytewolf: 33588?
21:45 perfectsine joined #salt
21:45 whytewolf Edgan: yeap.
21:46 Edgan whytewolf: I still have 35003.
21:46 whytewolf the fix wasn't in 2016.3.1 but it made it into 2016.3.2
21:46 Edgan whytewolf: I also seem to have a new regression with 2016.3.2 that I haven't tracked down yet.
21:50 whytewolf well one bug fixed, introduce 30 more
21:51 west575 joined #salt
21:53 upb joined #salt
21:53 Edgan whytewolf: cloud-init writes minion.pem and minion.pub to /etc/salt/pki, but it is supposed to be in /etc/salt/pki/minion
21:53 Edgan whytewolf: Via some mysterious force it used to happen, but doesn't anymore
21:56 whytewolf that is truely strange
21:57 Edgan whytewolf: yeah, not seeing the difference in 2016.3.2 :\
22:01 mapu joined #salt
22:03 pipps joined #salt
22:03 flowstate joined #salt
22:06 ajw0100 joined #salt
22:06 krymzon joined #salt
22:10 whytewolf Edgan: I see nothing in the diff between 2016.3.1 and 2016.3.2 that would cause that. maybe something in the bootstrap script?
22:12 Tyrm_ joined #salt
22:19 Edgan whytewolf: not using bootstrap, baked in package to the AMI
22:19 whytewolf weird
22:22 Edgan whytewolf: just double checked and the only difference between cloud-init salt module from trusty and xenial is one character in the umask
22:23 ninjada joined #salt
22:23 Edgan whytewolf: I could probably fix it with a patched cloud_init salt module, but would be nice to know why it used to work
22:24 Jimlad joined #salt
22:25 mapu_ joined #salt
22:28 pipps joined #salt
22:31 PryMar56 left #salt
22:48 Sammichmaker joined #salt
22:49 stooj joined #salt
23:01 ninjada joined #salt
23:02 flowstate joined #salt
23:02 badon_ joined #salt
23:10 badon_ joined #salt
23:10 pmcg joined #salt
23:15 stanchan joined #salt
23:18 tiwula joined #salt
23:20 ninjada joined #salt
23:25 pipps joined #salt
23:27 DaveQB joined #salt
23:30 stooj joined #salt
23:38 saltme joined #salt
23:43 hoonetorg joined #salt
23:57 pipps99 joined #salt

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