Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-05-12

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

All times shown according to UTC.

Time Nick Message
00:01 forrest nah, iggy only rejects his own code
00:01 forrest duh
00:02 forrest iggy: regarding the copyright thing, I believe that was just prep at some point that Nitin did.
00:02 forrest so we didn't have to keep up with it
00:02 forrest It's free work man, I don't know what you want here ;)
00:04 VR-Jack quality free work. :)
00:04 VR-Jack shouldn't be any quality to it. quality fre.e
00:07 iggy I appreciate what everybody does... I just think we need to all agree on what is and isn't suitable
00:08 iggy if you are merging PRs when I've clearly asked the original a question, you are either not checking anything or you don't care about my input
00:09 iggy especially when the original author comes back a week later and says "nope, untested, probably only works on X" (paraphrasing)
00:15 noway__ joined #salt
00:16 bhosmer__ joined #salt
00:16 looprock joined #salt
00:16 baweaver joined #salt
00:16 mpanetta joined #salt
00:18 mpanetta joined #salt
00:21 devramen joined #salt
00:23 murrdoc joined #salt
00:28 baweaver joined #salt
00:33 cheus joined #salt
00:35 CeBe1 joined #salt
00:41 kitplummer joined #salt
00:43 baweaver joined #salt
00:44 otter768 joined #salt
01:00 ITChap joined #salt
01:01 dendazen joined #salt
01:01 Setsuna666 joined #salt
01:04 b18 joined #salt
01:05 b18 Hey everyone - Just noticed on docs.saltstack.com that 2015.5.0 was the 'latest release'. How long before that makes its way to the SaltStack Ubuntu repo? Just tried updating from 2014.7.5 and I got 'already latest version'. Thanks!
01:07 iggy b18: the guy that does the packages for debian/ubuntu said he was working on them last night... so... soon?
01:08 b18 Great! Just curious. Thanks for the reply.
01:14 hasues joined #salt
01:14 hasues left #salt
01:17 VR-Jack Wonder if epel can do it for centos. I noticed dev required some pretty new support versioning.
01:19 subsignal joined #salt
01:24 MorbusIff joined #salt
01:25 mage__ joined #salt
01:25 dabb_ joined #salt
01:27 bretep` joined #salt
01:27 pviktori joined #salt
01:28 otter768 joined #salt
01:28 dstokes joined #salt
01:31 julez joined #salt
01:35 kusams joined #salt
01:37 bhosmer joined #salt
01:38 noway__ joined #salt
01:41 VSpike joined #salt
01:45 cmcmacken joined #salt
01:48 dalexander joined #salt
01:55 primechuck joined #salt
02:06 forrest joined #salt
02:11 kitplummer joined #salt
02:13 devramen joined #salt
02:17 spookah joined #salt
02:21 factor left #salt
02:24 kusams joined #salt
02:31 jalaziz joined #salt
02:32 bhosmer joined #salt
02:37 Singularo joined #salt
02:41 CeBe1 joined #salt
02:45 evle joined #salt
02:45 kitplummer joined #salt
02:50 jab416171 joined #salt
02:51 looprock joined #salt
02:53 michelangelo joined #salt
02:58 lictor36 joined #salt
02:59 favadi joined #salt
03:01 ajw0100 joined #salt
03:04 yexingok joined #salt
03:09 jab416171 joined #salt
03:17 dabb joined #salt
03:17 davisj joined #salt
03:18 Antiarc joined #salt
03:19 SaveTheRbtz joined #salt
03:19 grep_away joined #salt
03:19 keekz joined #salt
03:21 kaictl joined #salt
03:22 looprock left #salt
03:22 jhujhiti joined #salt
03:36 evle joined #salt
03:38 TyrfingMjolnir joined #salt
03:42 mosen joined #salt
03:51 andrej So, I've been fighting with file.recurse for two days now ... I have a load of minicom port config files & symlinks sitting in /srv/salt/minicom/minicom ... pushing this out via the state creates all files, no symlinks.  Why?
03:52 andrej http://pastebin.com/rghSJ54b
03:52 andrej http://pastebin.com/3pAS40hw
03:53 adfafqwdefqae joined #salt
03:53 andrej The first paste is the init.sls, the 2nd is the directory on the master
03:53 Not_ joined #salt
03:54 andrej this is the result on the minion http://pastebin.com/Cptsk6PT
04:09 rojem joined #salt
04:13 joeto joined #salt
04:26 iggy andrej: protip: gist.github.com allows multiple files per paste
04:28 linjan joined #salt
04:29 iggy the indentation looks messed up to
04:30 rideh joined #salt
04:31 rideh joined #salt
04:34 pdayton joined #salt
04:34 dfinn joined #salt
04:37 rdas joined #salt
04:42 VR-Jack andrej: umm, what's the problem again?
04:43 VR-Jack n/m
04:48 ramteid joined #salt
04:53 VR-Jack andrej: works on centos6.5 master and minion w/ salt 2014.7.5 using salt '*' state.sls from master, ZMQ transport.
04:53 VR-Jack I didn't have the jinja in mine. no reason for it in testing
04:59 bhosmer_ joined #salt
05:04 subsignal joined #salt
05:08 julez joined #salt
05:09 Nazca__ joined #salt
05:17 TOoSmOotH joined #salt
05:20 factor joined #salt
05:33 Nazca joined #salt
05:42 jab416171 joined #salt
05:42 Nazca__ joined #salt
05:43 favadi left #salt
05:45 otter768 joined #salt
05:45 linjan joined #salt
05:54 Nazca joined #salt
05:56 TOoSmOotH joined #salt
05:59 Nazca__ joined #salt
06:00 colttt joined #salt
06:05 subsignal joined #salt
06:06 Nazca joined #salt
06:07 dabb_ joined #salt
06:08 fbettag joined #salt
06:10 favadi joined #salt
06:11 lesterc joined #salt
06:12 jhujhiti joined #salt
06:12 AndreasLutro joined #salt
06:12 lesterc Can someone tell me whether the apache.configfile state works with "salt-call 2014.7.5 (Helium)"?
06:12 * lesterc couldn't get it to work :(
06:18 jab416171_ joined #salt
06:21 jab416171 joined #salt
06:23 rojem joined #salt
06:24 AndreasLutro lesterc: can you be more specific about how it doesn't work?
06:25 mosen I couldnt get the SSL directives to work, the jinja template doesnt seem to care if the vars are set or not
06:26 joeto joined #salt
06:26 mosen also the pillar example for SSL contains invalid syntax, using = for yaml instead of :
06:26 lesterc AndreasLutro: I am following the instructions from http://docs.saltstack.com/en/latest/ref/states/all/salt.states.apache.html, called "salt-call state.highstate" which shows the state got run but I don't see the file created.
06:26 mosen oh sorry, i was thinking about the formula
06:27 lesterc I removed the state, run highstates and re-enabled that and the file appears. :-/
06:28 lesterc hang on - it was from file.managed :)
06:28 iggy lesterc: docs say it should work in 2014.7.0 and up
06:29 lesterc iggy: yeah I noticed.
06:30 AndreasLutro lesterc: you need to check the comment of the state. does it say "Failed to create apache configuration." ?
06:31 iggy 2015.5 is out
06:31 AndreasLutro indeed
06:31 lesterc it said "Successfully created configuration." but the new value is nothing.
06:31 AndreasLutro lesterc: "the new value is nothing"?
06:32 lesterc yeah - I must have missed something
06:32 AndreasLutro what does that mean
06:32 AndreasLutro the file is empty?
06:33 lesterc yeah
06:33 AndreasLutro can we see your state? put it on gist/some pastebin
06:34 iggy I'd just use file.managed with a template
06:37 lesterc http://pastebin.com/Nc8evVE5
06:37 lesterc I need to go - will return to this in an hour. ;-)
06:37 stanchan joined #salt
06:38 AndreasLutro lesterc: try indenting the items under "VirtualHost:" another 2 spaces
06:38 soren_ joined #salt
06:39 flyboy joined #salt
06:48 JayFK joined #salt
06:49 illern joined #salt
06:54 viq joined #salt
06:57 julez joined #salt
06:57 lesterc joined #salt
06:59 lesterc AndreasLutro: spotted anything? :)
07:00 bhosmer_ joined #salt
07:03 tmclaugh[work] joined #salt
07:03 KermitTheFragger joined #salt
07:05 AndreasLutro lesterc: try indenting the items under "VirtualHost:" another 2 spaces
07:07 yuhl_work___ joined #salt
07:07 lb1a joined #salt
07:15 r3tic3nc3 joined #salt
07:15 jvblasco joined #salt
07:20 hebz0rl joined #salt
07:20 dariusjs joined #salt
07:24 yggdrasi1 joined #salt
07:26 c10b10 joined #salt
07:27 julez joined #salt
07:34 bluenemo joined #salt
07:35 dimeshake joined #salt
07:38 fredvd joined #salt
07:45 keimlink joined #salt
07:45 otter768 joined #salt
07:54 lesterc You are the man AndreasLutro. ;-)
07:54 malinoff joined #salt
07:55 julez_ joined #salt
07:55 markm__ joined #salt
07:58 fredvd joined #salt
08:01 julez joined #salt
08:02 fbergroth joined #salt
08:02 linjan joined #salt
08:06 julez_ joined #salt
08:10 ndrei joined #salt
08:14 supersheep joined #salt
08:14 Xevian joined #salt
08:19 al joined #salt
08:22 N-Mi joined #salt
08:22 N-Mi joined #salt
08:23 losh joined #salt
08:28 markm_ joined #salt
08:28 chiui joined #salt
08:29 favadi joined #salt
08:32 denys joined #salt
08:42 lionel joined #salt
08:44 kawa2014 joined #salt
08:47 N-Mi joined #salt
08:52 ITChap joined #salt
08:57 illern joined #salt
09:01 bhosmer joined #salt
09:07 bluenemo joined #salt
09:07 subsignal joined #salt
09:12 SpX joined #salt
09:18 julez joined #salt
09:18 lothiraldan joined #salt
09:22 dkrae joined #salt
09:25 factor Has anyone had trouble opeing the Salt port.
09:25 factor I had set the eth device in the /etc/salt/ conf
09:27 Garo_ Has anybody worked with multiple syndic servers where a minion connects to each of them (for high availability)? I have an issue where my minion gets commands sent from the master-of-master server from each of the syndic servers
09:30 monkey66 joined #salt
09:39 reveredge joined #salt
09:39 otter768 joined #salt
09:42 lothiraldan joined #salt
09:43 peters-tx joined #salt
09:46 dyasny joined #salt
09:47 supersheep joined #salt
09:52 |borat| joined #salt
09:54 teogop joined #salt
09:55 kawa2014 joined #salt
09:56 Kelsar joined #salt
09:58 codehotter Is it smart to replace cronjobs on each individual server with jobs that the salt master server orchestrates?
09:59 codehotter Why would I want to / not want to do that?
10:03 ThomasJ codehotter: If salt-minion dies for whatever reason, so does your cronjobs
10:03 phx there are distributed cronjob systems, like autosys
10:03 ThomasJ The cron daemon is more reliable, and you can control the configurations for the cron daemon using salt as well
10:03 phx those can ensure that a given job is run on whatever machine is available
10:07 reveredge it this group related to cryptographic salts?
10:08 subsignal joined #salt
10:08 yonix joined #salt
10:09 markm__ joined #salt
10:12 bezaban reveredge: nope, it is saltstack, a system for configuration management
10:13 bezaban reveredge: ##crypto is probably a good bet
10:14 wnkz joined #salt
10:15 markm_ joined #salt
10:17 reveredge ok bezuban
10:20 wnkz_ joined #salt
10:21 monkey66 left #salt
10:21 CryptoMer joined #salt
10:25 WildPikachu is there any recommended git backend to use Dulwitch or GitPython?
10:30 kawa2014 joined #salt
10:33 monkey66 joined #salt
10:34 Kelsar joined #salt
10:36 julez joined #salt
10:41 bhosmer joined #salt
10:43 soren_ joined #salt
10:51 giantlock joined #salt
10:52 CryptoMer joined #salt
10:52 favadi joined #salt
10:52 evle joined #salt
10:56 TyrfingMjolnir joined #salt
10:57 dopesong joined #salt
11:00 ndrei joined #salt
11:01 bhosmer joined #salt
11:02 nyx_ joined #salt
11:03 markm__ joined #salt
11:06 ndrei joined #salt
11:07 bhosmer joined #salt
11:11 ferbla joined #salt
11:16 linjan joined #salt
11:22 markm_ joined #salt
11:26 markm__ joined #salt
11:29 CeBe joined #salt
11:36 dabb joined #salt
11:38 bhosmer joined #salt
11:58 froztbyte offhand, what's the behaviour if I import a state more than once?
11:58 froztbyte I know with pillar it's merges (with I think last-write-wins?)
11:58 favadi left #salt
11:59 AndreasLutro froztbyte: you mean with include?
11:59 julez joined #salt
11:59 froztbyte yes
12:00 AndreasLutro it'll only get included once if multiple files include the same sls
12:00 froztbyte if I have, say, a backports state, and I import it again in a substate
12:00 froztbyte mm, okay
12:00 jonatas_oliveira joined #salt
12:02 julez joined #salt
12:08 supersheep joined #salt
12:10 subsignal joined #salt
12:14 cheus joined #salt
12:14 lothiraldan joined #salt
12:14 keimlink joined #salt
12:15 giantlock joined #salt
12:15 otter768 joined #salt
12:22 mirko i think i'm having an issue with "file.recurse" - the directory to copy over contains an empty one which is skippsed. although "include_empty: True" is specified.
12:23 robsavino joined #salt
12:28 zer0def dumb question: assuming minion_id is set, is there any way to change a minion's id from master, other than overwriting the file and restarting the minion?
12:29 ageorgop joined #salt
12:33 amcorreia joined #salt
12:37 babilen zer0def: That's exactly how you'd do it
12:37 babilen (modulo key removal/acceptance)
12:38 ndrei joined #salt
12:40 tempspace Good morning all
12:43 subsignal joined #salt
12:43 zer0def babilen: was hoping someone might've figured perhaps a slicker (?!) way, but that's close enough(tm)
12:44 babilen zer0def: You could manage your minion's conf with the salt formula and ensure that /etc/salt/minion_id is absent.
12:44 babilen Then you only have to implement some way of removing/accepting the new key and you are golden.
12:44 rdas joined #salt
12:46 emaninpa joined #salt
12:49 julez joined #salt
12:49 zer0def babilen: there's a formula for this use case? ordinarily i'm implementing stuff on my now, still kinda on the learning curve
12:49 zer0def s/now,/own,/
12:50 babilen https://github.com/saltstack-formulas/salt-formula is what I was thinking of, lets see if that allows you to manage the id easily
12:50 babilen https://github.com/saltstack-formulas/salt-formula/blob/master/salt/files/minion.d/f_defaults.conf#L69
12:50 babilen Just set minion: id: foo in the pillar (as I had expected it to be)
12:52 ndrei joined #salt
12:53 catpig joined #salt
12:56 JayFK joined #salt
12:58 bhosmer joined #salt
12:58 subsignal joined #salt
12:59 denys joined #salt
13:05 JDiPierro joined #salt
13:05 racooper joined #salt
13:05 JDiPierro joined #salt
13:06 johnkeates joined #salt
13:09 froztbyte huh, what
13:09 johnkeates yeah, what?
13:09 froztbyte salt.states.archive appears to know about zip/rar/tar, whereas salt.modules.archive knows about gzip/gunzip too
13:10 froztbyte and source confirms: https://github.com/saltstack/salt/blob/develop/salt/states/archive.py#L209
13:10 johnkeates i guess the state doesn't implement all of the module options
13:10 froztbyte yeah, seems it
13:10 johnkeates but isn't zip handing gunzip/gzip fine?
13:10 froztbyte not sure, I barely ever touch zip
13:11 froztbyte like, at all
13:11 johnkeates i touch my zipper only when i need to pee
13:11 johnkeates for everything else, there is gzip
13:11 primechuck joined #salt
13:11 johnkeates so i know how you feel :p
13:11 * froztbyte pushes the state to give it a test
13:11 * johnkeates touches his zipper
13:13 multani is tehre anybody using salt-cloud with Google Cloud?
13:14 multani I'm only trying to spin up a single instance, and I encounter many problems
13:14 multani even after upgrading to latest Salt version and libcloud master (which solved a few problems already)
13:15 multani it now fails after creating the instance and trying to bootstrap the Salt minion the new instance
13:16 julez joined #salt
13:20 nyx_ joined #salt
13:25 jdesilet joined #salt
13:26 cheus joined #salt
13:27 dendazen joined #salt
13:29 mpanetta joined #salt
13:32 Tyrm joined #salt
13:33 iggy multani: I tried a while back and it worked fine (on 2015.2/5/whatever)
13:37 mapu joined #salt
13:38 fbettag joined #salt
13:39 bhosmer_ joined #salt
13:40 is_null joined #salt
13:40 is_null hi all, how to join saltstack-formulas ? i'd like to create rsync-formula
13:40 is_null s/rsync/rsyncd
13:41 subsigna_ joined #salt
13:43 drawsmcgraw joined #salt
13:43 babilen is_null: Just create it, put it on GH and write to the mailing list. It will happily be forked into saltstack-formulas
13:44 multani iggy: did you use the bootstrap script thing, to automatically add the new instance as a minion to your master?
13:44 debian112 joined #salt
13:48 dendazen joined #salt
13:52 hasues joined #salt
13:54 _JZ_ joined #salt
13:54 edrocks joined #salt
13:55 pdayton joined #salt
14:00 froztbyte nah, gzip doesn't play nice under the zip type
14:00 froztbyte that's annoying
14:01 timoguin joined #salt
14:02 dimeshake joined #salt
14:03 e-gineer joined #salt
14:03 iggy multani: yes
14:03 andrew_v joined #salt
14:05 kusams joined #salt
14:05 cmcmacken joined #salt
14:07 hasues left #salt
14:11 cpowell joined #salt
14:11 kusams_ joined #salt
14:14 fyb3r joined #salt
14:16 otter768 joined #salt
14:16 markm_ joined #salt
14:19 ndrei joined #salt
14:21 rideh joined #salt
14:22 numkem I'm using pillar.get in my mine functions and I have to restart the minion every time the pillar data changes so that it gets put in mine. Is there another way except restarting the minion?
14:22 is_null babilen: there you go: https://github.com/jpic/rsyncd-formula
14:23 Deevolution numkem:  I have the same issue.  See: https://github.com/saltstack/salt/issues/23391
14:23 is_null oops my bad you said the mailing list
14:24 numkem Deevolution: nice you you got feedback this quick
14:24 is_null babilen: are you sure it is required to contact the mailing list ? docs claim that irc is good enough: http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#writing-formulas
14:25 johnkeates IRC is good enough if someone with access sees you here
14:25 johnkeates if they aren't here they can't read what you type :p
14:25 Deevolution numkem:  I'm still trying to dig into it.  But it does appear to be related to multi-master setup (i.e. that master: stanza in the minion config)./
14:25 is_null hehehe thanks for the heads up johnkeates
14:25 numkem Deevolution: so your problem is that pillar data while using pillar.get doesn't get updated? That might explain my problem with mine
14:26 numkem Deevolution: mine as the salt mine system
14:26 mirko when setting grains with salt they seem to be only stored in /tmp/ and are therewith non-persistent - is that intended?
14:26 mirko using salt-ssh
14:26 Deevolution numkem:  Pillar.item works always.  Pillar.get doesn't appear to be refreshed even when a saltutil.refresh_pillar is run.  If you're using a pillar.get in the mine function, I'd guess that's where it's failing.
14:27 mirko is there any way to make them permanent?
14:27 pf_moore joined #salt
14:28 numkem Deevolution: I'm on 2014.7.5 so it seems to be affecting more than just the latest
14:29 Deevolution numkem: I've been testing this on 2015.2.0rc2 (following seeing it in 2014.7.0/4).
14:30 edrocks joined #salt
14:30 numkem Deevolution: did you send the patch you were talking about?
14:31 numkem Deevolution: I'm not using a list for master in the minion's config, standard key-value
14:31 Brew joined #salt
14:31 Deevolution numkem:  I didn't create the patch, since they indicated that would be incorrect behavior further down the issue.  Are you still specifying a specific 'named' master?
14:32 numkem named as a hostname?
14:32 jalbretsen joined #salt
14:32 sevalind joined #salt
14:32 Deevolution As in something like "master: serverX"
14:32 numkem indeed
14:33 Deevolution When I removed that stanza and just let it resolve to 'salt' it didn't have the issue.
14:33 numkem I didn't even know this was possible, how does it figure out who is the master?
14:33 Deevolution I'm fairly certain the core of the issue is in the multi-master code (if there are named masters, it assumes that it is multi master).
14:33 Deevolution It defaults to a hostname of 'salt'.
14:33 Deevolution So if you have DNS resolving salt to your master you don't need that stanza.
14:34 giantlock joined #salt
14:34 thedodd joined #salt
14:34 numkem interesting, will have to add this... What if the salt dns name resolved to multiple A records pointing to many masters?
14:35 Deevolution I don't think that would work well.
14:35 Deevolution I think it's likely that you would end up with different minions on each master.
14:36 numkem I've never used the multi master part of salt. I assume the minion will try another master for the list if the first one isn't responding?
14:36 sevalind Hello! I'm getting an error when trying to include a separate state file. Here's some info: https://gist.github.com/anonymous/8f0b46b5c679c4962cbe
14:37 Deevolution numkem: Multi master has every minion connecting to every master.
14:37 numkem Deevolution: Thats even better, will have to read into it
14:38 numkem sevalind: you do not have a folder named php
14:38 numkem sevalind: what salt is looking for is a file that would be named php/pkgs_dev/init.sls
14:38 sandah joined #salt
14:39 numkem sevalind: or php/pkgs_dev.sls if the first one isn't found
14:39 sevalind numkem: Sorry, that tree was from within the php folder
14:41 numkem sevalind: I've never used underscores in sls names, that might be it. Beside that try to run your state on the targetted minion using salt-call -l debug this helped me a lot
14:42 sevalind numkem: I'll run it with -l debug, see what it says. I was told to use underscores instead of dots or dashes, but that could be wrong
14:43 numkem sevalind: I'm looking into my own states and I happen to use something similar to yours. Where would be that php folder?
14:45 sevalind numkem: I'm running this masterless from a test machine, so I currently have it sitting in /root/salt/php/. I have file_roots: base: /root/salt defined in /etc/salt/minion
14:46 irctc037 joined #salt
14:46 numkem sevalind: Oh ok, I've never used masterless setups before. What about the usual culprit: selinux? Do you see any warnings or denied access if you are on centos?
14:47 sevalind numkem: Good call, let me check. It should be disabled
14:47 sevalind Yeah, it's set to permissive (this is centos)
14:48 VR-Jack By default there's no policy for salt, so unless you mandate policy on selinux there shouldn't be an issue there.
14:48 ndrei joined #salt
14:48 TyrfingMjolnir joined #salt
14:49 numkem sevalind: getenfore returns permissive?
14:49 obestwalter joined #salt
14:50 sevalind numkem: yessir
14:50 obestwalter Hi
14:51 obestwalter Question: how is automated testing done for Windows at the moment and who should I ask to get involved?
14:51 drawsmcgraw sevalind: I use dashes in my states all the time with no issues, for what it's worth to you.
14:51 sevalind drawsmcgraw: hrm, maybe I should try that
14:51 sevalind here's the "full" error: https://gist.github.com/anonymous/fc2a2db8cd6a1e3b3c81
14:52 drawsmcgraw I really don't think it's a dashes-vs-underscores thing though...
14:52 numkem I don't think so either, its something else like the minion really cant read those files... Is it running as root?
14:52 JDiPierro joined #salt
14:53 drawsmcgraw sevalind: I've used relative includes with sucess
14:53 sevalind numkem: I believe so -- it doesn't have a problem running the main state file (pkgs.sls)
14:53 drawsmcgraw For instance, in your case -> change 'php.pkgs_dev' to just '.pkgs_dev'
14:53 sevalind I'm running it via: salt-call -l debug state.sls php.pkgs
14:53 drawsmcgraw (note the 'dot' at the start)
14:54 sevalind drawsmcgraw: what would that afford me over the current naming scheme? other than potentially working ;)
14:54 VR-Jack yeah, your tree shows pkg_dev as the proper name. php.pkg_dev would be under a php directory
14:55 drawsmcgraw sevalind: I'm always a fan of relative includes in general (not just Salt states). They're more portable
14:55 drawsmcgraw Don't change any filenames
14:55 drawsmcgraw Just update your 'include' stanza
14:55 sevalind VR-Jack: Sorry, I clarified above, but that tree was run from within the php directory
14:55 sevalind drawsmcgraw: ah, I see, I can try that out
14:56 drawsmcgraw k
14:56 drawsmcgraw I commented on your github gist.
14:56 sevalind drawsmcgraw: got it
14:57 VR-Jack there's issues with some of the pathing concepts in salt. some things are relative
14:57 conan_the_destro joined #salt
14:57 N-Mi is there a grain to determine which init system is in use on a minion ? as Debian Jessie can run either with sysvinit or systemd, testing on the release does not seem safe to me
14:57 smcquay joined #salt
14:58 sevalind OH crap, I think I know what the issue is
14:58 ek6 included states are always handled first correct?  regardless of their position in the calling state file.
14:58 dimeshake joined #salt
14:59 VR-Jack ek6: they are always included first, so that things referencing can see them
14:59 sevalind Ok, well that's gotten me somewhere. My spacing was incorrect, so the include was being run underneath the previous functions
14:59 VR-Jack same goes with includes in top. The tree is built first, then it processes
14:59 drawsmcgraw VR-Jack: I had always visualized it as replacing the 'include' stanza with the states found in the mentioned statefile. Is that about right?
15:00 WildPikachu does all salt minion have to be the same version as the master?
15:00 ek6 vr-jack: yup understand why..just wanted to make sure i was correct with my 'always' assumption
15:00 sevalind Now I get a different error: https://gist.github.com/anonymous/697441b7ccf6019fcef5
15:00 VR-Jack drawsmcgraw: it is, but it's 2 passes
15:01 drawsmcgraw VR-Jack: 2?
15:01 VR-Jack from a salt perspective, these are just dicts and lists. include is loaded up first pass, then ignored second pass... At least it was in pillar top.
15:02 sevalind Could I be getting that error because I have a standalone "include" in the upper part of that file?
15:03 drawsmcgraw Ah, I see. Okay
15:03 timoguin joined #salt
15:04 drawsmcgraw sevalind: I don't think so. I have some 'install' states that are nothing but a single include stanza with several state files mentioned.
15:04 sevalind drawsmcgraw: Yeah, this is two separate include stanzas
15:05 sevalind I have one at the top and then some farther down (only included based on a grain)
15:05 drawsmcgraw hrmm..... I don't know about multiple includes. But I don't think it would be a problem.
15:05 VR-Jack yeah, my main init.sls files are often nothing but include
15:06 sevalind https://gist.github.com/anonymous/81baf8a70bf7eb830d8b <--- A small breakdown of the pkgs.php file
15:07 sevalind By the way, thanks for taking the time to help, it's greatly appreciated :)
15:08 sevalind hrm ok, if it's fine to have multiple includes, not sure why I'm getting an SLS rendering issue with conflicting id for "include"
15:09 sdm24 joined #salt
15:10 Rory joined #salt
15:11 iggy obestwalter: utahdave
15:12 obestwalter thanks iggy :)
15:12 Rory How can I have an "if" block that depends on a pillar value? I would expect this to work, but the stuff inside the if block gets ignored, despite the pillar being set.  http://pastebin.com/8LKpkQSi
15:13 Rory Use case is, write the entry to the hosts file if the pillar exists and isn't blank. Otherwise, do nothing.
15:14 sevalind seems other people have had similar issues: https://github.com/saltstack/salt/issues/9400
15:14 VR-Jack savalind: not sure you can have multiple includes
15:14 VR-Jack the nature of yaml, that might not work
15:14 iggy Rory: take out the default value and the comparison
15:15 sevalind VR-Jack: right, that's what I'm getting from that github issue thread
15:15 sevalind So should I put my ifs inside the include above?
15:15 Rory iggy: What will happen if the pillar is defined, but is empty string?
15:15 VR-Jack yeah, and just drop in the extra modules
15:16 iggy Rory: not entirely sure, test
15:16 VR-Jack Rory: this line works. {% if salt['pillar.get']('hosts:' + phostname + ':network','') != '' %}
15:17 VR-Jack only diff I see between mine and yours is I used '' and not ""
15:17 Rory I'm thinking it's an inconsistency in quoting styles, probably a Python thing not salt directly
15:18 Rory I see problems with inconsisent quoting in Python a lot, so I'll double-check that and retest now. I'll also try the behaviour without any default specified at all
15:18 sevalind VR-Jack, drawsmcgraw: That worked, putting the ifs in with the same include
15:18 sevalind awesome
15:18 drawsmcgraw sevalind: Nice! TIL
15:18 obestwalter left #salt
15:18 bradthurber joined #salt
15:18 drawsmcgraw Yeah, it makes sense now that I remember states, yaml, etc.... Only one  include per state file
15:19 sevalind yeah
15:19 sevalind Now to figure some other stuff out... I'm sure I'll have more questions
15:19 sevalind ;)
15:19 VR-Jack I confused master once so that it reported duplicate yaml id's in pillar. had to restart master. heh
15:19 sevalind the final stanza for those interested: https://gist.github.com/anonymous/b5a587466ad4dc33516d
15:21 VR-Jack hmm. GH tag backport mean they'll eventually backport the fix?
15:21 bradthurber I'm having trouble getting salt-cloud to create an instance with a public ip in a VPC. I'm using AssociatePublicIpAddress: True - see Gist https://gist.github.com/bradthurber/b9f778edc2c4d58c4fef I noticed in salt-cloud ec2.py source a comment "Associating a public address in a VPC only works when the interface is not created beforehand, but as a p
15:21 bradthurber art of the machine creation request". Not sure what this means. Is there specific syntax for doing this?
15:23 bradthurber Should have mentioned that this is Amazon EC2 cloud and running salt 2015.5.0 on the master
15:23 CeBe joined #salt
15:23 VR-Jack bradthurber: means if only takes effect for the vpc creation. If added latter, it won't "change" it.
15:25 VR-Jack wow. I need coffee. I can't type.
15:26 bradthurber VR-Jack: Thank you for the reply. Confused. I thought I was creating an EC2 instance - not a VPC
15:27 dfinn joined #salt
15:27 timoguin bradthurber: the text means you don't need to create a network interface beforehand.
15:27 timoguin one will be created and associated during the server spin up
15:27 timoguin What are you having trouble with?
15:28 twork back again with a basic, basic question... i have some state defined under a file_root. my tests see it as differing from the state of my minion. but salt won't make any changes. all i get from 'state.hightate' or 'state.sls users' is a list of states, 4 succeeded, 3 failed.
15:28 twork "it worked last week"<tm>
15:29 VR-Jack more info if you use salt-call -l debug on the minion, twork
15:29 bradthurber timoguin: my instance does not get a public ip address - and therefore isn't able to access the Internet due to the way the vpc is configured (no NAT). This causes salt-cloud provisioning to fail
15:29 monkey66 left #salt
15:29 twork aha, thanks, that's one of the details i was forgetting. making note...
15:31 VR-Jack twork: with exceptions (reactor/orchestrate), states are run on the minion, so best debugging is there. Master just has to wait on minion to finish and collect results.
15:34 ALLmightySPIFF joined #salt
15:34 timoguin joined #salt
15:34 twork aha. progress: "failed to create user larry". probably because, to test, i jsut took larry out of /etc/passwd. ...so, salt doesn't steamroll my minion's state into what i want?
15:34 timoguin bradthurber: paste your profile config and/or any errors you get somewhere
15:35 bradthurber ok
15:36 julez joined #salt
15:37 twork more detail: the error is "group larry exists". ...now, suppose i have a minion that's been misconfigured somehow (say for instance that a line in passwd has been removed). what i'd want is for salt is to set that file to the desired state.
15:37 julez joined #salt
15:38 twork i realize that my OS (debian) is throwing the error here, not salt per se, but still...
15:38 VR-Jack twork: it's because you made the call that creates the group with the username
15:39 VR-Jack if you did user.absent, it would have deleted the group
15:39 twork i don't quite follow.
15:40 VR-Jack it's a security mechanism. You asked the system to create a user specific group. ie. user joe, group joe, but group joe exists.
15:40 bhosmer_ joined #salt
15:41 VR-Jack caused by gid_from_name: True
15:42 twork hm. i see the logic. but i guess i still wish that whatever is in salt could be relied upon to define the state of the minion.
15:42 VR-Jack it's the OS
15:43 twork yeah, i get that
15:43 VR-Jack group: joe should not exist if user: joe was deleted
15:44 mccricardo joined #salt
15:44 VR-Jack using salt's user.absent will automatically delete the group, as does the OS when you use userdel.
15:44 mccricardo Good afternnon guys!
15:44 rojem joined #salt
15:45 twork fwiw, i did userdel the user. probably without the right args, i dunno.
15:46 twork anyhow. mystery solved, thanks as always.
15:46 mccricardo quick question:
15:46 mccricardo I have a custom module that returns True or False
15:46 mccricardo I want to to have a file.managed that based on the result of that module execution (True or False) puts a file on a certain folder.
15:46 mccricardo Is that possible? Maybe using unless?
15:46 VR-Jack twork: yeah, that's broken. I did useradd joe, userdel joe and mine deleted the group properly
15:47 twork debian?
15:47 VR-Jack mccricardo: onlyif/unless run shell commands
15:47 VR-Jack twork: centos 6.5... ymmv
15:47 mccricardo yeah, that's what I found out...
15:47 twork ...actually... now that i think of it, maybe i did b0rk passwd by hand. bad twork.
15:48 mccricardo I was interested in in catching the True or False result
15:48 VR-Jack if module runs as a state, then just activate the state and do a require. Don't know of a "if state failed do this"
15:48 twork the lesson is: if you hose your system, you can't always count on your tools to save you.
15:49 VR-Jack mccricardo: capturing results is one of salt's limitations
15:49 PI-Lloyd Anyone been able to successfully map a branch other than 'master' to base when using gitfs as an ext_pillar source?
15:49 Rory iggy: I tested without the default value and comparison, so the first line just reads: {% if salt['pillar.get']('myeeapp:SPGProxyAddress') %}
15:49 mccricardo yeah...
15:49 mccricardo maybe if a run the module, and 'require' in file managed it works
15:49 Rory iggy: It still gets skipped over:
15:49 Rory [DEBUG   ] Results of YAML rendering:
15:49 Rory {}
15:50 denys joined #salt
15:50 Rory probably just gonna go home
15:50 VR-Jack mccricardo: the usual method is to run a python program that can send a reactor signal and data to the master which can take that data and launch a state.
15:50 mccricardo hum...
15:50 mccricardo ok ok
15:50 mccricardo let me check that
15:51 VR-Jack but if you just need true, false, then run module as a state and if it succeeds, the require will flag. if it fails, requires won't run
15:52 mccricardo I thank that should work for this particular case
15:52 mccricardo let me try that out
15:52 VSpike I'm having trouble with the reverse-users formula. Probably PEBKAC. https://bpaste.net/show/3444312a3209 is the pillar I'm using, and the error is https://bpaste.net/show/afacaa95e697
15:52 VSpike Any idea what I'm doing wrong?
15:52 kaptk2 joined #salt
15:53 gladiatr joined #salt
15:53 Alan_S joined #salt
15:54 VR-Jack lol, you got a keyerror on pillar in opts? hahaha
15:55 bradthurber timoguin: re: salt-cloud AssicatePublicIpAddress not working - the profiles and log uploaded to https://gist.github.com/bradthurber/b9f778edc2c4d58c4fef
15:58 VSpike VR-Jack: uh.. explain? :)
15:58 VR-Jack VSpike: 2 things. When you do the I@, you shouldn't have userinfo, and the stuff under userinfo spaces in under the I@
15:59 VSpike VR-Jack: I have other users like that which do work. I'm referring to https://github.com/saltstack-formulas/reverse-users-formula/blob/master/pillar.example
16:00 timoguin bradthurber: the only settings I have that you don't have in that profile is PrivateIpAddresses:\n  - Primary: True for the element under the network_interfaces key
16:00 VR-Jack VSpike: I read it. Notice they use userinfo when not doing I@ for a specific user, but even if they work combined, your userinfo is at the present: tab level. That is wrong
16:00 timoguin bradthurber: that and your grains data looks malformed
16:00 VR-Jack hmm. or perhaps not
16:00 PI-Lloyd would someone mind taking a gander at https://bpaste.net/show/38daede56ee7 and see if you can spot anything, cheers
16:01 VSpike VR-Jack: this is the full pillar I have https://bpaste.net/show/193727610b69 .. all the ones before websync work fine
16:01 Gareth morning morning
16:01 VR-Jack VSpike: then your problem is, the module doesn't have support for loading pillar
16:01 VR-Jack thus the error
16:01 VR-Jack Perhaps a versioning issue in salt. Not sure.
16:02 VSpike Ah. Annoying :) OK.
16:02 ndrei joined #salt
16:02 VR-Jack Their example uses Grains, so I presume that works, though using grains seems weird in that case.
16:03 bradthurber timoguin: I'll get rid of grains and add PrivateIpAddresses section - and try again
16:04 thedodd joined #salt
16:07 iggy Rory: salt '*' pillar.get myeeapp:SPGProxyAddress
16:07 iggy do you see what you expect
16:09 Rory Against ALL instances?
16:09 iggy not necessarily, but whatever makes sense
16:09 Rory And no, I don't see what I expect, I see no output apart from the minion ID
16:10 Rory iggy: I can see it with pillar.data
16:10 iggy there's a bug open about that I think
16:10 Rory oh
16:11 Rory Now I get the pleasure of engaging Salt "professional" "support" that we pay through the nose for
16:11 Rory IRC is literally better, usually
16:13 iggy https://github.com/saltstack/salt/issues/23391
16:13 thayne joined #salt
16:13 Rory Thanks iggy , you're been helpful regardless :)
16:14 aparsons joined #salt
16:16 thedodd joined #salt
16:17 otter768 joined #salt
16:19 Nazca__ joined #salt
16:19 bradthurber timoguin: looks like the same result with changes suggested. New gist created: https://gist.github.com/bradthurber/397d1eeef77c299f5007 I'm wondering if this appears to work for others because their VPC subnets are set to automatically assign a public IP or they use a VPC NAT configuration. I'm very new to all of this so possibility there is some b
16:19 bradthurber oneheaded thing I'm doing
16:20 sevalind Is there a way to run multiple states at once with salt-call? for example, salt-call state.sls state1.foo state2.bar
16:20 iggy sevalind: that should
16:21 iggy sevalind: oh, comma separated
16:21 sevalind aha, derp :P Thanks iggy
16:21 linjan joined #salt
16:24 sevalind iggy: I get odd errors when I do that, namely: https://gist.github.com/anonymous/4d9380ccc18a0e176381
16:25 theologian joined #salt
16:25 sevalind If I run postgres.client or postgres.server by themselves, they work fine
16:25 iggy comma separated, not comma+space separated
16:25 sevalind So many rules! :P
16:25 iggy with the space, your shell is breaking that into separate args (rather than one comma separated arg)
16:25 iggy linux 101
16:26 sevalind iggy: for sure
16:26 iggy you might be able to get away with "state, state2"
16:26 mccricardo VR-Jack: it worked. thank you
16:26 iggy but that seems like more typing than necessary
16:27 dfinn joined #salt
16:28 VR-Jack cool. like it when things work
16:28 VR-Jack back to pizza
16:29 iggy sevalind: and thank you for pasting and not making me beat it out of you
16:29 sevalind iggy: word up
16:29 CeBe joined #salt
16:30 iggy sometimes I think people really don't want my (free) help ;)
16:31 KyleG joined #salt
16:31 KyleG joined #salt
16:32 smcquay joined #salt
16:33 monkey661 joined #salt
16:34 murrdoc joined #salt
16:36 monkey66 joined #salt
16:37 timoguin joined #salt
16:37 writtenoff joined #salt
16:37 MatthewsFace joined #salt
16:40 cheus joined #salt
16:44 murrdoc joined #salt
16:44 cpowell_ joined #salt
16:45 cpowell_ joined #salt
16:45 WildPikachu if I am using gitfs, would my pillar_roots base still be /srv/pillar or /pillar? assuming my git repo is my top level?
16:46 iggy WildPikachu: gitfs is for states (i.e. the equivalent of file_roots)
16:46 racooper gitfs works for pillars too...I'm using it
16:47 iggy that's ext_pillar
16:47 iggy it doesn't actually share any code with gitfs
16:48 WildPikachu "The pillar_gitfs_ssl_verify option specifies..."  that made me think I can store my pillar data in my gitfs :(
16:48 jonatas_oliveira joined #salt
16:48 iggy WildPikachu: misnamed option I guess
16:49 iggy but yes, you can keep pillar data in git and fetch similarly to how gitfs works for states
16:49 WildPikachu iggy, can you point me to some docs about that? :)
16:49 iggy ext_pillar
16:50 iggy but the thing is when you're using the git ext_pillar, pillar_roots doesn't impact how it operates
16:50 racooper http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html  at the bottom, 3.4.8.12
16:51 racooper and iggy the git external pillar docs are in the same document as gitfs for states so it's quite easy to understand the confusion.
16:51 iggy that's for states, not pillar
16:51 racooper "3.4.8.12. Using Git as an External Pillar Source"
16:51 WildPikachu http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#using-git-as-an-external-pillar-source  <= iggy  :)
16:51 iggy okay, you're right, I'll go stfu now
16:52 WildPikachu racooper, do you perhaps use git+ssh or https as the example has without any auth?
16:53 racooper I use git+ssh using keys
16:53 WildPikachu interesting, how are you specifing a key for ext_pillar?
16:54 racooper it uses a key defined in root's ~/.ssh configs
16:54 iggy we use ssh_config aliases
16:54 WildPikachu ah
16:54 WildPikachu got it
16:56 murrdoc joined #salt
16:58 randomusername joined #salt
16:58 murrdoc joined #salt
16:59 WildPikachu racooper, do you store your state in the same git repo?
16:59 racooper no, states and pillars are in separate repos in my config.
17:00 iggy we tried to combine them at first... didn't work out very well
17:00 WildPikachu yea, it says that the git repo is locked
17:00 randomusername I'm having problems with the redis module. One one system it uses localhost:6379 to connect and on another it uses salt:6379 to connect. So I end up getting connection refused on the second one. But if I pass host=localhost, it works as expected. How do I go about debugging this?
17:01 WildPikachu so basically I should split my   saltmaster-main repo into saltmaster-states and saltmaster-pillar?
17:01 bhosmer joined #salt
17:01 racooper I think that's the best practice way. I have salt-states and salt-pillars, and pretty sure I read that it was considered better that way.
17:02 elektrix joined #salt
17:02 pfallenop joined #salt
17:02 admgre joined #salt
17:02 etw joined #salt
17:02 stbenjam joined #salt
17:02 spader joined #salt
17:02 philipsd6 joined #salt
17:02 dfinn joined #salt
17:02 ksalman joined #salt
17:02 awerner_ joined #salt
17:03 iggy if nothing else, it gives you a little more flexibility as to who can see what (pillars generally being used for "sensitive" data and all)
17:03 hax404 joined #salt
17:03 stevednd joined #salt
17:03 numkem joined #salt
17:03 oravirt joined #salt
17:03 jdesilet joined #salt
17:03 jesusaurus joined #salt
17:03 bhosmer_ joined #salt
17:04 debian112 joined #salt
17:04 RedundancyD joined #salt
17:05 monkey66 joined #salt
17:05 ajw0100 joined #salt
17:05 twork my latest confusion: i'm making some changes to a template file, can't figure out what i'm doing wrong, so i took it down to the bare minimum... and at the minion end, contents i've removed from that file are still appearing. restarting the master and the minion hasn't had any effect either.
17:05 iggy anybody ever used the multi-master config syntax to fake multi-pathing to a single master? thinking of making it so our minions can go over a VPN to get to the master or fall back to the internets to get to the master (if the VPN is down)
17:06 iggy twork: what command isn't working?
17:06 zz_ashmckenzie joined #salt
17:06 dalexander joined #salt
17:06 conan_the_destro joined #salt
17:07 dingo joined #salt
17:07 twork at the minion end: salt-call -l debug state.highstate ...which is failing to compile a user config.
17:07 morsik joined #salt
17:08 iggy that should cause a sync from the master
17:08 twork at the master: https://gist.github.com/mjinks/75e75cf4fcfd4ea7b07b
17:09 iggy can you "salt-call cp.get_file salt://path/to/foo.sls /tmp/foo.sls" and see if the file in /tmp looks as expected?
17:10 iggy just fyi, you probably want group.present first (as the user will want it when it's created and Salt operates top-down)
17:10 mccricardo joined #salt
17:10 twork iggy: that might be my trouble
17:10 murrdoc joined #salt
17:10 twork the complaint on the minion end is that the group doesn't exist
17:10 iggy sounds like it
17:11 marcinkuzminski joined #salt
17:12 JDiPierro joined #salt
17:13 twork nuts, the minion's log file still throws "useradd: group '10010' does not exist"
17:14 twork and i don't know where it's getting that 10010 from. rather, it did appear in my archive previously, but it's not there now
17:14 twork something i don't know to flush
17:15 twork haven't tried that get_file yet. will now.
17:16 thayne joined #salt
17:18 JDiPierro joined #salt
17:18 twork hm... what i get is, on stdout, "local:", and in /tmp/foo.sls, no file created.
17:19 forrest joined #salt
17:20 twork aha. i misunderstood the server-side path name.
17:21 twork and, what i'm getting is a copy of the source file from several revs ago. no shock i guess, but not sure why.
17:22 murrdoc what are u trying to do ?
17:23 sdm24 woah, when was 2015.5  officially released?
17:23 twork oh. duh. pathname wrong in the master's config file. sigh.
17:23 sdm24 ie moved from development to stable
17:24 murrdoc like that like so yesterday sdm24
17:24 murrdoc like omg
17:24 sdm24 brb, time to upgrade all my minions again
17:26 VR-Jack I'm still waiting to see if it will be able to make epel.
17:28 forrest VR-Jack: It will
17:29 forrest VR-Jack: EPEL always takes forever unless 3 of us approve it because it's EPEL
17:29 VR-Jack forrest: it doesn't have dependencies that can't be met? I know dev might
17:29 forrest I don't know, terminalmage usually has the build available.
17:29 forrest I'd have to search for it in epel testing or whatever it is called.
17:30 VR-Jack it's the pro/con of epel. if a dependency from base can't be met, the package just can't go into epel.
17:32 jalaziz joined #salt
17:33 racooper salt-2015.5.0-1 is currently pending in Bodhi. testing requested.
17:34 rsimpkins left #salt
17:34 JPT joined #salt
17:37 WildPikachu racooper, one last question, is your ext_pillar files also in a pillar/ directory in your git?
17:37 forrest VR-Jack: What? Most of the time the reason it isn't in EPEL on release day is because the RPM was only built a day prior, and it has to sit in epel testing for 3 weeks.
17:37 hemphill joined #salt
17:37 iggy salt needs their own repo... everybody is doing it
17:38 racooper WildPikachu,  not sure I understand your question?
17:38 WildPikachu racooper, is your top.sls in / or in /pillar in your repo?
17:38 racooper it's at the top level of the repo.
17:39 VR-Jack forrest: may be the case here, too. Was just curious. At some point salt will probably exceed versioning on some of the base python modules. epel insures that base packages aren't overriden.
17:39 * WildPikachu debugs more ,thanks racooper :)
17:39 [dan] can anybody help me debug an issue with the redis module?
17:39 racooper I think as long as Salt want to support CentOS, it is going to have to stay compatible with base, at least until 2020
17:41 WildPikachu you are a star racooper :)
17:41 bhosmer joined #salt
17:41 racooper you're welcome.
17:41 [dan] according to the module documentation, the default host value should be localhost but that seems to be broken for me. It's "salt" instead.
17:41 VR-Jack racooper: yes and no. centos7 is out now. presuming master is newer centos, backwards compatability with older minions should be fine.
17:41 cpowell joined #salt
17:43 racooper I konw for my case, I'm not planning to move to 7 until a couple of third-party applications certify MariaDB  (looking at you, Atlassian and Hannon-Hill).
17:43 VR-Jack hehe, yeah. I usually hold off a year at least. let things settle in
17:44 VR-Jack python-crypto was the main issue I had with dev. had to pip it in
17:44 racooper I should say, third-party vendors certify their applications.  RHEL7 has been out nearly a year now and these vendors are saying that Maria isn't important enough to even look at.
17:46 VR-Jack something with crypto.Random I think.
17:47 racooper sounds like that needs a bug report then.
17:48 Kelsar joined #salt
17:50 VR-Jack racooper: probably. the compile needed gmp-devel and after that I kept getting a warning every time I ran salt because of the gmp version in base.
17:50 saurabhs joined #salt
17:52 kalessin joined #salt
17:55 ajw0100 joined #salt
18:00 lumtnman joined #salt
18:03 druonysus joined #salt
18:07 qpst joined #salt
18:07 wendall911 joined #salt
18:09 fbergroth joined #salt
18:10 murrdoc joined #salt
18:12 desposo joined #salt
18:15 baweaver joined #salt
18:17 bradthurber trying to figure out salt versions. 2015.05 is out, but salt-cloud running on a 2015.05 master is still making 2014.7.5 minions.
18:18 timoguin 2015.5 isn't out yet.
18:18 andrew_v joined #salt
18:18 timoguin It's just tagged but hasn't been fully released to all the packaging places.
18:18 aarontc joined #salt
18:19 timoguin salt-cloud is installing the latest stable version for whatever distro you're using
18:23 hackel joined #salt
18:27 spookah joined #salt
18:27 yggdrasil joined #salt
18:27 denys joined #salt
18:29 txomon|home joined #salt
18:29 sandah Will 2015.5 be on epel anytime soon?
18:29 edrocks joined #salt
18:29 murrdoc yes
18:30 sandah thanks
18:30 VR-Jack sandah: probably be a few weeks based on epel policy
18:32 ndrei joined #salt
18:32 txomon|home question, can I make check on if other pillar data is available?
18:32 txomon|home for example, does pillar jinja have all the info, or just the one included?
18:32 txomon|home I am trying to do something like if zsh package is installed, then make zsh the user shell
18:32 txomon|home but in pillars, not in states
18:33 giantlock joined #salt
18:34 iggy timoguin: /topic disagrees (but yeah, not every package repo has it yet)
18:35 babilen We are in the wonderful released-but-not-released phase
18:35 iggy txomon|home: don't try to lookup pillars in pillars
18:35 txomon|home iggy, why not?
18:35 babilen txomon|home: In that partcicular case I'd simply ensure that zsh is installed.
18:36 txomon|home it is a key feature xD
18:36 iggy babilen: I prefer this to the "tagged for a month and waiting on one slow ass distro" state
18:36 babilen absolutely
18:36 txomon|home babilen, but I don't want to have zsh installed in all cases =)
18:36 txomon|home I am designing a role pattern/formula
18:36 iggy txomon|home: no it's not, if it works ever, it's by chance
18:36 babilen What decides if you install zsh on a minion or not?
18:36 CeBe joined #salt
18:36 txomon|home babilen, a role
18:37 txomon|home and there is a user role that will decide the default shell upon that
18:37 babilen txomon|home: So use the same logic you use for assigning that role for deciding if you use zsh or not.
18:37 txomon|home maybe if I specify in list the roles, first the one that says the zsh one and then the other, should that work?
18:37 smcquay joined #salt
18:37 txomon|home let me upload my progress...
18:38 babilen But yeah, I can understand your problem now, and it brings us back the the "there are no static pillars that are available everywhere like grains" problem
18:38 babilen Lets call them "pre-pillars" :)
18:39 cheus joined #salt
18:39 iggy in new versions you can specify whether ext_pillars get processed before file pillars (I think)
18:39 iggy there's still no guarantee though
18:41 babilen What I mean is that salt obviously misses a simple master-side k/v store
18:41 babilen (which is why grains are being (ab)used for that)
18:43 borgstrom joined #salt
18:43 florinandrei joined #salt
18:45 txomon|home babilen, https://github.com/txomon/role-formula
18:46 cberndt joined #salt
18:46 txomon|home I didn't do a good markdown syntax I see
18:46 txomon|home xD
18:51 legnej joined #salt
18:52 Diaoul joined #salt
18:53 florinandrei joined #salt
18:56 iggy my first PR to salt was accepted :)
18:56 devramen joined #salt
18:57 Gareth iggy: congrats!
18:58 bradthurber iggy I always see you on here helping people - which is awesome, but I have no idea what PR means
18:59 forrest bradthurber: a PR is a Pull Reqest, iggy is referencing his update to some code against the main salt repo
18:59 iggy ^
18:59 iggy beat me to it
18:59 forrest iggy: I didn't realize you hadn't made a PR against the main repo in all this time..
18:59 forrest what a slacker ;P
18:59 lictor36 joined #salt
18:59 iggy ikr
19:00 iggy I just keep all my stuff to myself
19:00 bradthurber oh, I understand pull request
19:01 mens joined #salt
19:01 baweaver joined #salt
19:01 VR-Jack woohoo! "in before iggy" is my new tagline
19:01 txomon|home haha
19:02 kitplummer joined #salt
19:02 iggy #ssceapproved
19:02 forrest You guys are killing me with your tag there
19:03 hybridpollo joined #salt
19:03 joeto joined #salt
19:04 kitplummer hey guys, i'm trying to get a machine (RHEL-6.5) up and running with salt-cloud.  the provision works, but the deploy.sh is never copied over and no minion stuff is ever set up.  any ideas on what's up here?
19:04 overyander joined #salt
19:05 hybridpollo joined #salt
19:07 sevalind joined #salt
19:11 VR-Jack forrest, iggy: someone marked my PR as backport. does that mean it will eventually merge into older versions?
19:12 forrest VR-Jack: It might
19:12 iggy could
19:12 * VR-Jack was apparently not supposed to do it on dev
19:12 forrest VR-Jack: It happens, you could always modify the PR if they ask you to do os
19:12 forrest so*
19:12 racooper kitplummer,  aside from the fact that you are behind a few security releases if you're running 6.5, I can't help ya. need to get up to 6.6.
19:12 VR-Jack he said that next time I should do it on the oldest version and it would merge up to dev
19:12 florinandrei joined #salt
19:13 dfinn joined #salt
19:13 kitplummer racooper: are you implying that the version matters?
19:13 iggy which is ridiculous... they seem to barely have enough manpower to keep up with releases now, much less maintaining old stuff
19:13 racooper no, I'm saying that you have some security issues if you're running 6.5.
19:13 aparsons joined #salt
19:14 kitplummer what would prevent the deploy.sh from being scp'd over to a new minion (in salt-cloud land)?
19:14 VR-Jack So do you have tte a PR for each release individually? or is there a way to merge easier?
19:15 julez joined #salt
19:15 forrest VR-Jack: Nah I always just PR against dev, but I also don't do backport items
19:15 forrest VR-Jack: In this instance you would have been fine to put it on that single release probably.
19:15 VR-Jack it's not a common bug. imports into pillar top.sls aren't used much
19:15 forrest iggy: It really has gotten quite a bit better, if you watch the repo Colton is no longer doing the PR work, there is a new member doing that.
19:16 iggy I had to stop watching the repo, I got yelled at for telling someone that their question about running some random python crap on Windows had nothing to do with Salt
19:17 txomon|home joined #salt
19:17 basepi Hahaha
19:17 forrest iggy: oh that PR from a while back that terminalmage tweeted about?
19:17 basepi We just like to be nicer than you iggy xD
19:17 forrest Did you get yelled at for that? I don't remember a comment like that
19:17 lumtnman joined #salt
19:17 basepi And I think yelled is an exaggeration.
19:17 forrest That basepi guy, what an enabler...
19:17 basepi I know, I should probably yell more often.
19:18 VR-Jack Well, I'd like to have the fix in my production stuff and not wait for ber to release. You recommend that I just make a new PR and attach it to my bug for 2015.5 and 2014.7.5?
19:19 VR-Jack and hope it gets out to a package sometime?
19:19 basepi And honestly I think we're better than we've ever been for maintaining old stuff. We still have a long way to go, but we're slowly making up ground.
19:20 iggy forrest: something else
19:20 basepi VR-Jack: we should be doing a fairly quick 2015.5.1 so you shouldn't have to wait too long.
19:20 forrest basepi: His content is for an old release.
19:21 VR-Jack basepi: my merged PI is on dev is why I was wondering. The bug is as old as pillar
19:21 VR-Jack s/PI/PR/
19:21 basepi Well, we actually may also do a 2014.7.6, but we won't be patching 2014.1
19:21 basepi Mention me on your or
19:21 forrest VR-Jack: I'd just confirm it is on the newest release, and then paste that into the PR, boom, your issue is now a relevant issue for the newest release.
19:21 iggy basepi: I agree things have improved drastically (in almost every area)... still think you guys are biting off more than you're equipped to handle right now (my-don't-know-shit-opinion)
19:21 forrest stop stealing peoples JERBS basepi!
19:22 basepi mention me on your PR and tell me to back port it, I'll get it labeled and backported to 2014.7
19:22 babilen basepi: Regarding the branch naming convention and RC releases: I guess that your issue is primarily to have rc releases that sort in a specific way or what are your problems with, say, beryllium.rc1 ?
19:22 forrest please no babilen, I can't remember how to spell beryllium every time.
19:22 babilen hah
19:23 VR-Jack rofl. I didn't keep an eye on it. haha. rallytime backported to 2014.7
19:23 ndrei joined #salt
19:23 timoguin baroolium
19:23 babilen But we would all learn the elements!
19:23 basepi babilen: that kind of version wouldn't play well with package managers. How do you sort beryllium compared to 2015.5?
19:23 babilen forrest: But then it'll mostly be be<TAB> so should be too bad
19:23 basepi needs a number.
19:24 mattiasr joined #salt
19:24 hemphill joined #salt
19:24 forrest clearly you guys should use the java naming scheme java-realrelease-stupidrelease, so that we can't actually sort by any package manager
19:24 basepi I think the real answer is to just tighten our rc schedule and *actually* feature freeze.
19:24 babilen basepi: Yeah, that is what I figured. I just wanted to clarify that correct sorting of versions is what you are on about.
19:24 iggy basepi: yes please
19:24 forrest basepi: Lol, you'd have to get a machine to slap Tom's hands
19:24 iggy I kept seeing features go into 2015.2 and wanted to scream every time
19:24 babilen yes, feature freeze and pure maint and bug fix branches!
19:24 basepi We do too many last minute additions.
19:24 forrest just one of those crazy ones that is a bunch of hands on a pinwheel.
19:25 murrdoc got a recommendation for modifying server path ?
19:25 murrdoc via salt
19:25 forrest server path?
19:25 basepi We're also toying with the idea of more of a rolling release so feature releases aren't as different.
19:25 babilen basepi: Trust us: Feature freezes and tighter policies are perfectly fine
19:25 iggy basepi: one way to fight that is to have an actual schedule with reminders ("you have one week till the freeze, get your shit in now")
19:25 babilen yeah
19:25 murrdoc yeah add to existing path
19:25 babilen And then simply sort out bugs before the release.
19:25 hemphill Does anyone have a handy example of installing a package that is stored on the salt server?
19:25 forrest murrdoc: you can set env variables with salt if that's what you want.
19:26 forrest murrdoc: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.environ.html
19:26 racooper hemphill,  what OS/Distro?
19:26 murrdoc thats for the current salt run
19:26 murrdoc forrest:  i want to set the path of the server
19:26 forrest murrdoc: I don't understand the question, the salt server?
19:27 hemphill it's amazon linux as a saltmaster talking to a windows minion
19:27 florinandrei joined #salt
19:27 murrdoc forrest:  the minion
19:27 * basepi goes back to actually listening in his meeting
19:27 forrest the location of where the minion is installed? The location of the config?
19:27 babilen basepi: To be honest: I am not sure what YYYY.MM really bought us, but I guess it is too late for that discussion now. Have a good meeting :)
19:27 murrdoc sorry forrest
19:27 murrdoc not for the salt minion
19:27 murrdoc but on the minion
19:27 murrdoc i want to add the PATH for the root user
19:28 forrest for the root user's home directory? Sorry I am confused.
19:28 murrdoc k nvm
19:28 forrest okay, sorry :(
19:29 bluenemo joined #salt
19:29 bluenemo joined #salt
19:30 florinandrei joined #salt
19:31 babilen murrdoc: What do you mean by "the PATH of the server" or "for the root user" ? Are you talking about the PATH that is being used if you actually log in as root?
19:31 murrdoc uh hmm
19:32 smcquay joined #salt
19:32 basepi babilen: I'm kind of with you. We should have just done 2015.1 as the first release of 2015, 2015.2 as the second, etc. it's been kind of a cluster****
19:33 basepi or maybe we should have just released salt 1.0. *shrugs*
19:33 murrdoc u over it basepi
19:33 basepi It has its advantages.
19:33 babilen basepi: And I am simply thinking about ways to mitigate that. I am deeply grateful for the fact that .2 was renamed to .5, but there has to be a way to take the "crystal ball" out of the equation.
19:33 basepi But we haven't executed it particularly well.
19:33 babilen yeah, 1.0!
19:34 murrdoc the yyyy.mm naming is way better than 1.0
19:34 babilen As it would be even more of a clusterfuck to go back to X.Y versioning we shouldn't discuss it ...
19:34 rhand joined #salt
19:35 VR-Jack basepi: flagged you on the issue
19:35 baweaver joined #salt
19:35 basepi Yep, that's a big focus, is eliminating the crystal ball. And I'm actually with murrdoc, I still like the idea of date-based, we just haven't executed it well.
19:35 babilen But I would have preferred it and don't really see the merit of YYYY.MM if you don't *also* implement a strict release schedule. Unfortunately that collides with "when it's ready" (something I'm really fond of)
19:35 murrdoc failing to hit a pre hit version name is a tiny failure
19:36 murrdoc it made more sense to ship 2015.5 anyways, it reflects when it shipped
19:36 babilen absolutely
19:36 murrdoc and i prefer a working version
19:36 babilen *That* move was more than justified
19:36 basepi Yea, we don't want to have hard dates like Ubuntu. It'll definitely get better.
19:36 denys joined #salt
19:36 murrdoc u dont want to be in a place like mongodb
19:37 basepi Yes, I was surprised how little blowback there was on the rename.
19:37 babilen I mean one could simply rename RC releases as we go along (they'd still sort nicely)
19:37 murrdoc where people dont install a .0 version ever
19:38 murrdoc yeah
19:38 babilen I mean I very much like the idea of using something ephemeral such as "beryllium" to refer to the "next release" and creating the YYYY.MM branch during the release. The problem with that is that it is unclear how to name release candidates in such a way that they behave nicely in the context of version number sorting.
19:39 ckao joined #salt
19:39 whytewolf use the atomic number of the element?
19:39 hemphill From a user perspective I have never found the code name concept to be useful, it just adds lookup steps to figure out what version needs to be searched for.
19:40 babilen whytewolf: That is ... intriguing :)
19:41 thedodd joined #salt
19:41 babilen hemphill: It allows one to use branches that don't have to be renamed to reflect changes in the release schedule. Debian uses "unstable", "testing" and "stable" to refer to "development branch", "this is what the next release will be cut from" and "current stable release".
19:41 felippeb joined #salt
19:42 bhosmer_ joined #salt
19:42 tkharju joined #salt
19:42 hemphill Those kinds of cuts makes sense and are useful, when you start talking about trusty and raring though you are in a different world
19:42 ek6 so if there is a fix is develop that without it im getting lovely warnings on 2015.5 whats the proper way to request a backport?
19:42 felippeb upgrading to 2015.05. custom state is now returning import errors.    " import salt.utils.ipaddr as ipaddr ImportError: No module named ipaddr". any ideas?
19:42 babilen ek6: You open a bug or comment on the PR in which it was fixed so that it gets marked for backporting
19:46 supersheep joined #salt
19:48 timoguin felippeb: looks like stuff was moved into the salt.utils.network module
19:48 ek6 babilen: fix went into develop via a basepi remote-tracking merge and im not sure how to dig out the specific fix from @22169
19:48 VR-Jack joined #salt
19:49 donmichelangelo joined #salt
19:50 florinandrei joined #salt
19:50 babilen ek6: So it is already in 2015.5, what would you like to get it backported into?
19:50 * babilen is confused
19:51 tracphil joined #salt
19:52 ek6 babilen apologies.... search for return "serverdensity_device"  there in develop branch..not there in 2015.5 and so its blowing warnings becaues the module returns None
19:53 babilen So the fix is not in 22169 then
19:53 tracphil advise wanted: Do you run your highstates from master or run it from minions with salt-call in a random cronjob?
19:53 babilen from master
19:53 babilen Who would want to login to hundreds of minions to do that?
19:53 babilen (or worse: trigger a salt-call from the master ;)
19:54 elfixit joined #salt
19:54 tracphil I setup a cronjob to do it from the minion. It's setup during the initial preseed build.
19:54 babilen Ah, cronjob ... no no no. You could use a schedule on the master for that, but I prefer to run them explicitly.
19:54 tracphil cool, thanks. Anyone else?
19:54 babilen http://docs.saltstack.com/en/latest/ref/states/all/salt.states.schedule.html
19:55 tracphil ohhhh very very nice!
19:56 tracphil just wow.
19:56 felippeb thanks timoguin
19:56 babilen "function: state.highstate" is essentially what you are looking for, a maxrunning would probably not be a bad idea either
19:56 iggy 2015.2 4lyfe
19:56 babilen :D
19:56 davisj Nice. It turns out snagging all events off the event bus within a python process is stupidly simple https://gist.github.com/davisj/eef5ed0b96404ed1b4dc
19:57 davisj This is going to make shoving job data into a db without a returner easier than I thought :)
19:58 timoguin davisj: check out the master_job_cache: http://docs.saltstack.com/en/latest/topics/jobs/job_cache.html#master-job-cache
19:58 timoguin It'll dump the events into a database from the master
19:58 NickD joined #salt
19:59 davisj timoguin: yeah, I stumbled on that as well. I thought this way might allow for a simpler db sice I can filter what goes in.
20:00 NickD Hey all, I am having issues downloading tar/zip file from s3. I filed this issue: https://github.com/saltstack/salt/issues/23567
20:00 NickD any ideas?
20:01 iggy NickD: it's always a good idea to paste the command you ran to get the error message (in addition to the error)
20:01 davisj timoguin: I guess master_job_cache is what most folks are using for reporting (aside from returners)?
20:02 iggy smtp returner + gmail + lots of rules
20:02 timoguin davisj: It's pretty new. It's what the enterprise version uses to drive the web UI
20:03 davisj timoguin: cool. thanks for the suggestion
20:03 davisj iggy: :)
20:03 VR-Jack does my fork of salt dev automatically update?
20:03 VR-Jack in GH
20:04 hemphill is the salt way to install a package hosted on the master to file.managed it to the slave and then use cmd.run to actually install it?
20:04 VR-Jack ahh. hope. shows it's behind.
20:05 dfinn1 joined #salt
20:06 NickD iggy: i updated the issue with the command. https://github.com/saltstack/salt/issues/23567
20:06 iggy file.managed has s3 support built-in (just fyi)
20:07 iggy I would guess the file doesn't exist, but yeah, the traceback should be fixed
20:07 NickD if i put a non tar/zip file it works
20:09 NickD from the traceback it seems that s3fs.py fails to parse headers ?
20:10 NickD File "/usr/lib/python2.7/dist-packages/salt/fileserver/s3fs.py", line 585, in _get_file_from_s3 name, value = header.split(':', 1)
20:11 baweaver joined #salt
20:12 kunersdorf joined #salt
20:14 VR-Jack hmm. not really sure how to update the docs to refer to matching the master in pillar top.sls :(
20:14 kunersdorf how do I escape a { in a Multi-line text blurb?
20:16 baweaver joined #salt
20:16 chiui joined #salt
20:18 iggy kunersdorf: {% raw %} ... {% endraw %}
20:18 iggy kunersdorf: or {{ '{' }}
20:18 kunersdorf gracias
20:19 otter768 joined #salt
20:22 saurabhs joined #salt
20:25 Deevolution left #salt
20:25 Deevolution joined #salt
20:25 florinandrei joined #salt
20:26 tracphil babilen: thanks a million for your help. Have a super day!
20:28 yggdrasil joined #salt
20:28 twork something i don't follow in the docs. from: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.ssh_auth.html ...
20:29 twork " and since SSH keys are often longer than that, you may have to use a YAML 'explicit key', as demonstrated in the second example below." ...is that referring to the "source:" item in... what looks to me like the third example?
20:29 Ryan_Lane anyone know why batch mode would fail this way? https://dpaste.de/FWsU/raw
20:29 Ryan_Lane I think this is for a 2014.7.5 master
20:30 Ryan_Lane the next "Executing run on" line looks really odd
20:30 MindDrive joined #salt
20:31 Ryan_Lane basepi: ^^ ?
20:31 babilen I haven't seen that before. Ever.
20:32 babilen twork: I guess that is the case, yeah
20:32 druonysuse joined #salt
20:32 manfred never seen that, it is currently working for me :/
20:32 monkey66 left #salt
20:32 Ryan_Lane I'll need to verify they're on 2014.7.5
20:32 babilen I am quite frequently using batch mode, but that is a new error. Which versoins ..... yeah :)
20:32 twork babilen: okay, thanks.
20:33 manfred I have never used it with 10%
20:33 babilen I used it with percentages
20:33 babilen In fact the last big dist-upgrade was performed that way
20:34 manfred Ryan_Lane might be worthwhile to look at blame and see when and why it was changed
20:34 manfred sed -n '183p' salt/cli/batch.py
20:34 manfred for minion, data in six.iteritems(parts):
20:34 kunersdorf iggy: should raw escape everything between it and endraw?  https://gist.github.com/anonymous/d20990f74afe8d7ca9dc
20:35 manfred hrm odd
20:36 manfred it was only changed recently for python3 compatibility
20:36 manfred Ryan_Lane:  no idea <3
20:36 Ryan_Lane I don't think it's an issue with for minion in parts
20:36 Ryan_Lane I think it's an issue with next
20:37 Ryan_Lane since the first small batch was a list, but the next was a list of dicts, which look like minions that have returned
20:37 manfred that is an odd error though
20:37 Ryan_Lane yeah
20:37 manfred cause the serializable shouldn't matter
20:37 andrej iggy, thanks for the pro-tip :}
20:37 andrej I never claim to be professional ;}
20:37 manfred Ryan_Lane:  it used to be .keys()
20:38 manfred https://github.com/saltstack/salt/commit/152154df5701b269d4e7d8bd32a79afec5a367ec
20:38 Ryan_Lane well, it's unnecessary to use .keys()
20:38 andrej VR-Jack : the state doesn't carry the symlinks to the minion as symlinks, but rather creates files.
20:38 mirko (repost from earlier today) i think i'm having an issue with "file.recurse" - the directory to copy over contains an empty one which is skippsed. although "include_empty: True" is specified.
20:38 manfred sure
20:38 andrej iggy : when you said the indentation looks messed up ... could you be more specific?
20:38 VR-Jack andrej: it made symlinks on mine
20:39 andrej VR-Jack : what does your state look like, do you mind sharing?
20:40 VR-Jack andrej: copied yours, but here you go. https://gist.github.com/vr-jack/7cc4444c6b6ba6132686
20:40 kunersdorf andrej: does your code render right in yaml renderer?
20:41 Setsuna666 joined #salt
20:41 florinandrei joined #salt
20:42 manfred Ryan_Lane:  it almost sounds like minion is a dictionary already, and is being passed as the key for parts?
20:42 solidsnack joined #salt
20:42 Ryan_Lane I think they may be running mixed versions
20:43 baweaver joined #salt
20:43 manfred Ryan_Lane:  http://ix.io/iw7
20:43 andrej VR-Jack - what does the content of salt://test look like?
20:43 andrej Thanks for the paste, btw
20:44 andrej kunersdorf : how do I assess that?
20:44 solidsnack joined #salt
20:44 rap424 joined #salt
20:44 kunersdorf paste your yaml into a tool like this: http://yaml-online-parser.appspot.com/
20:44 kunersdorf if yaml is good, no red text
20:44 VR-Jack andrej: updated that jist
20:44 RedundancyD left #salt
20:45 chiui joined #salt
20:45 RedundancyD joined #salt
20:45 solidsnack joined #salt
20:46 andrej Thanks VR-Jack  ... that's confusing. It might be an ubuntu issue
20:47 seev joined #salt
20:47 VR-Jack andrej: could be. selinux? fs type? etc etc
20:47 andrej just one more question - you're also using 2014.7.5?
20:48 VR-Jack yes. master and minion 2014.7.5 centos 6.5
20:49 ndrei joined #salt
20:54 Ryan_Lane not an issue with mixed versions... I got them to run manage.versions
20:54 solidsnack joined #salt
20:54 Ryan_Lane there's two minions that are out of date, but not ones that would be in the batch
20:56 florinandrei joined #salt
20:56 murrdoc joined #salt
20:58 andrej Hmmm ...
20:58 _2_1drummer2 joined #salt
20:59 drawsmcgraw I've built a 'vars.map' that has a Jinja dictionary in it. When I use the values in that dictionary to render a value in a shell script, I get a rogue 'u' at the start of the values I'm trying to render (makes me think of things like    u'someString')
20:59 drawsmcgraw Paste: http://dpaste.com/3RQXFZH
20:59 drawsmcgraw Anybody know wtf?
21:00 dendazen joined #salt
21:01 murrdoc joined #salt
21:01 VR-Jack drawsmcgraw, did you try using ' instead of "?
21:02 andrej drawsmcgraw - is that data comning out of json? You're seeing "unicode" then.
21:02 lietu- joined #salt
21:02 VR-Jack nah. he's assigning it out of jinja. still looks like unicode, though
21:03 twork now i'm taking my first swing at making ssh_auth state work. a pub key (my own) is stored at the url implied: https://gist.github.com/mjinks/297a94a45a59ee5f1a0f
21:04 drawsmcgraw VR-Jack: andrej, I'll try swapping out the quotes..(?)
21:04 twork i gather that 'jdoe' showing up as both a user and a... user with a key? is the issue, but that can't be right...
21:04 drawsmcgraw And no. Swapping out the quotes makes no difference
21:05 VR-Jack drawsmcgraw: might try referencing using ['core_tarball'] as well
21:05 VR-Jack instead of the . syntax
21:05 drawsmcgraw Yeah it's definitely something, something, unicode :/
21:05 baweaver joined #salt
21:05 drawsmcgraw VR-Jack: lemme give that a try
21:06 giantlock joined #salt
21:06 drawsmcgraw VR-Jack: Also no good (nice try though. I'd have never thought of that)
21:06 drawsmcgraw It's being used in other places just fine
21:06 iggy kunersdorf: it should, but without more context, it's hard to tell what's wrong there
21:07 drawsmcgraw i.e. the file.manage() stanza works fine with {{nagios.core_tarball}}
21:07 drawsmcgraw So.... something goes pear-shaped when the shell script goes through the jinja rendering(?)
21:07 twork the example i'm cribbing from is 'thatch' in the doc: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.ssh_auth.html
21:07 VR-Jack drawsmcgraw: scan through the jinja filters and see if there's a filter that converts from unicode
21:07 drawsmcgraw VR-Jack: will do. Thanks
21:07 iggy andrej: it looked like wrong
21:07 VR-Jack internally, unicode is fine, but passing ot a shell might not work right
21:09 florinandrei joined #salt
21:10 drawsmcgraw VR-Jack: Agreed. something cagey happens when it crosses that line. I'll figure it out eventually.. Have to bow out for now
21:10 drawsmcgraw Thanks!
21:11 bhosmer joined #salt
21:11 ponpanderer joined #salt
21:11 ponpanderer hello
21:14 twork sifting through this again... in [file root]/users/init.sls, i have 'jdoe' defined, with the kind of info a uid needs; and in [file root]/ssh_keys/init.sls, there's a jdoe entry with 'ssh_auth.present:' ...but the error i get -- 'jdoe' and is found in SLS 'base:users' and SLS 'base:ssh_keys' -- tells me i'm not defining my data right, somewhere.
21:14 iggy twork: you can't have 2 things with the same id
21:15 iggy (the id being the part that is completely unindented in a sls file)
21:15 andrej thanks iggy ... I got what you mean :}
21:15 VR-Jack yeah, use the name: attribute
21:15 andrej it wasn't me creating the file
21:16 andrej I just updated the fleet to 2015.5.0 ...
21:16 andrej and the symlinks still end up as files
21:16 andrej =(
21:16 twork yeah, i get that... but, what i don't get is, how does salt know that both sets of data should be associated with the same user account? "jdoe:" isn't some kind of header in each file?
21:16 timoguin joined #salt
21:17 twork (...obviously it isn't, but what is?)
21:17 VR-Jack twork: the modules use the name:, if it doesn't exist, it uses the id by default. In this case, you need different id's and set name: the same
21:18 iggy it's not about the outcome of the states, it's about salt actually reading the states (you'd end up overwriting one key with the other if they didn't complain and quit)
21:19 moloney joined #salt
21:19 VR-Jack people run into the issue because they are used to shortcutting and not specifying name: :(
21:19 hal58th_ Damn, 2015.5.0 forced me to fix my lazy, hacked together work.
21:19 * timoguin always specifies name, always descriptive SLS IDs
21:20 moloney iggy: After updating salt to the latest release, I got the reactor->orchestrate stuff to work.  Thanks for the help!
21:20 VR-Jack mine is created via jinja, so the user stuff is user_{{username}} and the ssh_keys are sshkey_{{username}} for id, and then name: {{username}} on both
21:21 iggy hal58th_: ikr... bastards
21:22 twork VR-Jack: i think i'm getting there. but not quite yet: https://gist.github.com/mjinks/297a94a45a59ee5f1a0f
21:23 twork ...pasted that before i saw your jinja remark
21:24 twork i need to go back and read through your jinja again. it keeps making my head swim, but i'm getting closer. i think.
21:24 VR-Jack best practice is to always set name: and set descriptive id. it avoids id conflicts
21:25 twork unlike the docs...? :)
21:25 twork ...or, twork, learn to read the docs... i'm really not sure which sometimes.
21:25 iggy I kind of disagree
21:25 VR-Jack twork: https://gist.github.com/vr-jack/37a3eabed54e15e6f6f5
21:25 iggy you have to use some experience on what to use descriptive names for
21:26 linjan joined #salt
21:26 iggy but it's actually helpful to have salt piss and moan when you try to make 2 overriding edits to the same file (etc)
21:26 iggy which can happen fast when you start getting multiple working on your states
21:27 murrdoc it should actually be ssh-auth-jdo: instead of ssh_auth_jdo:
21:27 VR-Jack should alse have an e on the end of it. lol
21:28 twork i had to read that _/- three times before i got it...
21:28 twork ...damn picky computers...
21:28 fyb3r left #salt
21:28 murrdoc :)
21:28 murrdoc ssh_auth_jdo: sucks in vi
21:29 murrdoc when u hit w … it goes the whole word
21:30 iggy don't use vi?
21:30 * iggy runs
21:31 VR-Jack if I hit w, I probably want to go the whole word. :P
21:31 twork ok, so, what is the functional significance of (would have been) ssh-auth-jdoe: in that example? any?
21:31 VR-Jack but that's just me
21:31 murrdoc yeah but
21:31 murrdoc ssh_auth_jdo: is not the word
21:31 babilen murrdoc: https://github.com/bkad/CamelCaseMotion
21:31 murrdoc ssh auth jdoe is the words
21:31 VR-Jack twork: it's the key id for the stanza
21:31 murrdoc thats nice
21:31 twork referenced elsewhere?
21:32 VR-Jack require, watch, etc
21:32 murrdoc yeah its way better
21:32 VR-Jack if name: doesn't exist, name: is set to the id as well
21:32 iggy I tend to use _'s because python is kind of picky about -'s... but that's just kind of habit, not really a hard rule
21:32 murrdoc than using name
21:34 iggy other way of solving it? put the user creation and ssh stuff under the same stanza (in the same file)
21:34 murrdoc yeah thats better
21:34 moloney How do I call a custom execution module from a custom state module.  Doing __salt__['mymodulename'] doesn't work.
21:36 VR-Jack lots of ways to do things. My only complaint about the shortcut is people get id and name confused and it leads to failures until they get used to salt.
21:36 pcdummy joined #salt
21:36 pcdummy joined #salt
21:40 iggy moloney: __salt__['module.function']()
21:40 e-rb joined #salt
21:41 twork ok, so, bumbing along here... my ssh_auth.present: is now directly inside my users/init.sls file, with "- source: salt://ssh_keys/blah"
21:41 murrdoc gist it up man
21:42 twork yeah, coming.
21:42 murrdoc we ll nitpick it more
21:42 iggy boy will we
21:42 bhosmer joined #salt
21:43 moloney iggy: Tried that, I get a KeyError on the dict lookup
21:44 VR-Jack and twork: at your level, don't ever look at my pre-pillar gist. It's evil. :P
21:44 twork https://gist.github.com/mjinks/3bb4ddf5fb58b626b279
21:44 iggy moloney: that means something is wrong with your module
21:44 iggy moloney: wait, are you calling it in the __virtual__ function?
21:45 murrdoc No matching sls found for 'ssh_keys' in env 'base' ?
21:45 twork ah, probably because: there's nothing in ssh_keys/mjinks-rsa.pub except the key itself...?
21:46 iggy twork: you top file is wrong since you combined that stuff
21:46 twork ovs...
21:47 subsignal joined #salt
21:48 VR-Jack twork: ssh_auth is also weird. add - user: jdoe under ssh_auth.present:
21:48 twork so trying for some context... under "jdoe:", the "group.present", "user.present", and "ssh_auth.present", those all refer to salt.states modules? if that's the term?
21:48 VR-Jack yes
21:52 VR-Jack since the modules don't have a name, it is set to id, and passed to each module. ssh_auth.present also needs a user: set. it's layout is different. name is actually the key name, not the username. although it's cool to have them the same.
21:53 twork uh. yes! of course! ahem. this will all make sense eventually, i know, but it shore don't now.
21:55 forrest twork: let me gist something for you, hang on a second
21:55 twork progress. think i see some clues myself, but for those following along at home: https://gist.github.com/mjinks/fbd04fab2f6e6b7cebc9
21:55 moloney iggy: not calling it in __virtual__, but I guess I did something to break the module as I can no longer call it from the CLI either.  I don't see any errors in mater/minion debug logs though
21:55 iggy moloney: I think you know what to do...
21:55 iggy Just Gist It!
21:56 dfinn joined #salt
21:57 twork ...yeah, i no longer have any init.sls in the dir where my key lives. because i thought i no longer needed it, because i thought that was now just a path to a file.
21:57 VR-Jack twork: is the .pub in proper format? <enc> <key> <comment> on a single line?
21:58 twork yep
21:58 twork sourced from a Real Computer
21:58 iggy top.sls
21:59 forrest twork: refresh https://gist.github.com/mjinks/3bb4ddf5fb58b626b279
21:59 forrest I've added a comment, there is no reason to avoid verbosity
21:59 iggy sure there is
22:00 forrest in what situation would you recommend it for a new user? Or any user who wants to make things easy
22:00 iggy docs say so, it is kind of one of Salt's selling points (conciseness), all the extra lines
22:00 iggy the ones that are reading the damned docs that do it all over the place
22:00 forrest there is a difference between the concise nature of salt, and avoiding clarity.
22:00 forrest salt is still much more concise in design and implementation than something like puppet is
22:00 iggy WORKSFORME
22:00 * iggy pulls the cord
22:01 murrdoc the problem is your shit stinks
22:01 murrdoc and u think its a rose
22:01 murrdoc :
22:01 murrdoc :P
22:01 forrest talking to me murrdoc?
22:01 murrdoc no the id stuff works for me because i use a ton of listens
22:01 twork my shit smells like lilacs. ftr.
22:01 murrdoc YOU TALKING TO ME FORREST
22:01 murrdoc :)
22:01 * murrdoc was talking to no body
22:02 forrest if your states are terribly organized, then yes :P
22:02 forrest cringe city when people mix IDs
22:02 murrdoc for the amount of work my states are doing
22:02 murrdoc i think they are pretty
22:02 moloney iggy: here is my custom module: https://gist.github.com/moloney/2c20fa4b8e67fee8a01e   I am concerned by the fact that whatever error is happening is not getting logged.  I tried commenting out the "depends" decorator to see if that would at least get an error logged, but nope. I do see the module being synced in the log, but thats it.
22:02 iggy do it all with the pyrenderer, then you have to be concise
22:02 murrdoc eugh
22:02 forrest no thanks
22:02 VR-Jack forrest: I wonder if there's a problem with the salt line. it's not acting right from what I can tell.
22:03 iggy all beginners should start off with pyrenderer
22:03 forrest VR-Jack: the source line?
22:03 murrdoc why not pyobjects
22:03 iggy then they'll appreciate yaml+jinja
22:03 murrdoc puppets dsl stinks
22:03 ndrei joined #salt
22:03 VR-Jack forrest: yeah. it's like it's trying to load it as a module
22:03 murrdoc forcing all my states to be yaml makes it easier for people to not destroy
22:04 forrest that line will be looking in /srv/salt/ssh_keys/key_name
22:05 forrest might also need a - enc line to determine the type of key
22:05 iggy moloney: what version of salt are you running?
22:05 twork VR-Jack: inch by inch this is sinking in... so the key that salt uses to identify each stanza is variable. in the stuff you posted, 'group.present' is identified by '- name: jdoe', while the (otherwise meaningless) jdoe_ssh: stanza is identified by '- user: jdoe' ...?
22:05 forrest no idea what the directory structure looks like on the box.
22:05 moloney iggy: 2015.5
22:05 forrest VR-Jack: I was the one who posted that updated comment on your jist
22:05 druonysus joined #salt
22:05 forrest *gist
22:05 forrest err twork ^
22:06 VR-Jack forrest: yeah. what bothers me is the fetch failure lines on his gist
22:06 twork oops, sorry. credit/blame where due.
22:06 forrest VR-Jack: Without knowing what the box looks like it's impossible to say, probably just the directory is wrong.
22:06 twork forrest == gravyboat?
22:06 forrest yep
22:06 forrest the - name: line is the actual NAME of the user/group
22:07 VR-Jack twork: ssh_keys directory under /srv/salt?
22:07 forrest I left the third example alone to show you don't have to use name for jdoe_ssh
22:07 twork VR-Jack: yes
22:07 forrest twork: you could easily have a - name: jdoe-ssh-key or whatever you want there.
22:08 forrest twork: Are you running that as a highstate?
22:08 VR-Jack twork: do you have any jinja in /srv/pillar/top.sls?
22:08 twork VR-Jack: no i lied. /srv/salt/file_root is where everything lives; ssh_keys is directly under there
22:08 forrest Is the top file already cleaned or did you leave ssh_keys in there.
22:09 forrest twork: change the source to be the correct path
22:09 forrest salt://file_root/ssh_keys/....
22:09 iggy moloney: I'd stick with the "old fashioned" way of using __virtual__
22:10 iggy there's one module using @depends and it looks like it's more meant for gating single functions (whereas your whole module is hosed if that binary isn't there)
22:10 iggy the postgres module is a good thing to look at
22:10 twork i don't yet grok what it means to be running something as a highstate. i'm crgo-culting "salt-call -l debug state.highstate" and watching what comes out.
22:11 moloney iggy: I will give it a quick try, but with the "depends" decorator commented out I shoud be getting an error or access to the module
22:11 Guest10514 joined #salt
22:11 VR-Jack twork: do you have any jinja in /srv/pillar/top.sls?
22:12 moloney iggy: Do I have to worry about module names and state names colliding?
22:12 twork VR-Jack: i don't have any pillar directory
22:12 twork ...i set that aside a couple days ago in a fit of simplification
22:13 VR-Jack twork: what's under /srv/salt/file_roots/top.sls?
22:13 iggy moloney: no, they are namespaced under salt.{states,modules}
22:14 murrdoc joined #salt
22:14 iggy moloney: with @depends commented out, you need a __virtual__ function
22:15 twork VR-Jack: one file, top.sls, and a 'users' directory. the ssh_keys directory was there, just moved it one layer up, no difference.
22:16 VR-Jack twork: what's in the top.sls file, though
22:16 twork i'll gist my top.sls
22:17 twork ...ah, n/m. under base: / '*':, two items: - users and - ssh_keys. leftover from when ssh_keys was trying to be its own separate thing.
22:18 twork https://gist.github.com/mjinks/a87393968f6625399cb5
22:18 smcquay joined #salt
22:18 iggy 17:46 < iggy> twork: you top file is wrong since you combined that stuff
22:18 VR-Jack twork: delete the extra - ssh_keys, thank iggy, and should be good
22:19 iggy (it's now 18:18 for those of you at home)
22:19 twork yep. thaks iggy, thanks VR-Jack...
22:19 moloney iggy: sure, but right now my one and only test minion has that binary and I am just trying to debug.
22:19 forrest Such anger iggy, I feel like we're in #ubuntu or #git
22:19 twork sorry, that scrolled past me
22:19 murrdoc try #php
22:20 forrest twork: It happens, now you know for the future :)
22:20 twork ouch
22:20 otter768 joined #salt
22:20 VR-Jack the difference is, we've only got iggy. :)
22:20 iggy I'm actually in a good mood, but okay... peace out
22:20 twork hey, wait 'til i'm less bashful.
22:20 twork we're among friends. i sure hope.
22:21 forrest iggy: I'm just messing with you, the relaxed nature doesn't come across in text.
22:21 murrdoc forrest and iggy conversation, http://i.imgur.com/i1Ok6qN.gif
22:22 moloney iggy: argh, needed to restart the minion for some reason to get it to recognize updated module
22:22 forrest better to be soft than the diamond turds that inhabit other channels I've been in.
22:25 dendazen joined #salt
22:26 mosen joined #salt
22:27 twork IT fucking WORKS. (i can swear here, right, this is irc?)
22:29 twork time for twork to go home for the day. meager though it be, an accomplishent is an accomplishment.
22:29 twork thanks one and all.
22:29 forrest later
22:34 pipeep What's the best way to recursively copy the contents of a directory on a minion to another directory on the minion?
22:34 pipeep file.recurse only works with files on the master (salt://)
22:34 pipeep (oh, I should've clarified, from a state file)
22:34 VR-Jack cmd.run rsync?
22:35 pipeep VR-Jack, or cp -r, but that doesn't manage state properly
22:35 pipeep It'll always be marked as changed unless I pass the creates flag, but then it won't ever update the files
22:35 twork rsync can't handle state? what kind of state do you need to handle?
22:35 pipeep twork, I mean salt will claim that it's always changed
22:36 pipeep which is less than ideal
22:37 DaveQB joined #salt
22:39 pipeep Maybe the stateful argument will work with the right arguments passed to rsync or cp
22:39 whytewolf use the rsync module?
22:40 pipeep whytewolf, oh, there's one of those?
22:40 whytewolf http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.rsync.html#module-salt.modules.rsync
22:40 twork i must not get your drift. how can you write a file, by whatever method, and not change its state?
22:40 twork or do you mean on the source end?
22:40 pipeep whytewolf, I see a module, but not associated state module
22:41 hal58th joined #salt
22:41 pipeep twork, if the source file doesn't change, the copy should be skipped or marked as "not changed"
22:41 whytewolf you can call modules in states with the state.module
22:41 pipeep Like the behavior of file.copy with the force argument
22:42 pipeep Although I think that's currently broken in dev: https://github.com/saltstack/salt/commit/bb021bc1e5db9aec5064bf722d64a47fd28106a7#commitcomment-11122251
22:42 whytewolf but you are back to the always reporting change
22:42 pipeep whytewolf, that's interesting. I didn't know that.
22:43 VR-Jack you could do rsync wrappered in a script that checked output for changes and issued a return result and then issue that in an onlyif clause (nasty, but...)
22:44 whytewolf worse case. write a _state modules that does what you want
22:44 pipeep VR-Jack, I just feel like this is way more complicated than it should be.
22:44 pipeep Maybe I should just give up on trying to get the "changed" output perfect
22:45 VR-Jack pipeep: have you tried to use a local file specification in the sources on file.recurse?
22:45 VR-Jack I know it says salt:// specifier, but it may or may not be limited to that
22:45 pipeep VR-Jack, I did.
22:45 pipeep It errors
22:45 VR-Jack figures. it's a rare case. normally you want things from the server itself.
22:46 pipeep There's a check in the code: https://github.com/saltstack/salt/blob/develop/salt/states/file.py#L2062
22:46 Tyrm_ joined #salt
22:46 pipeep VR-Jack, I'm also a bit confused as to why file.copy exists when it seems like you could use file.managed with file:// for most things
22:47 pipeep Okay, well thanks guys. I've got a few things to try.
22:48 keimlink joined #salt
22:48 pipeep (or gals, I don't really know)
22:50 Tyrm joined #salt
22:52 Singularo joined #salt
22:52 cmcmacken joined #salt
22:52 julez joined #salt
22:55 hasues joined #salt
22:55 hasues left #salt
22:55 primechuck joined #salt
22:57 desposo joined #salt
22:59 gladiatr joined #salt
23:00 pdayton joined #salt
23:01 joehoyle joined #salt
23:01 pdayton joined #salt
23:03 ndrei joined #salt
23:04 joehoyle hey, is there a salt command to update a salt-minion config on all minions
23:04 joehoyle kind of like grains.setval but for config configs
23:06 whytewolf joehoyle: file.managed and service.running with a watch?
23:07 VR-Jack or use the salt-formula possibly
23:07 joehoyle I'm looking to run it once off
23:08 joehoyle or is that what you mean
23:09 VR-Jack there's a formula for creating and setting minion configs.
23:09 VR-Jack of course, for one off, you could use some of the file options to change a line then issue a service restart
23:10 solidsnack joined #salt
23:10 joehoyle yeah, that's what I'm looking at. file.replace or something just seems a bit of a sledgehammer approach
23:11 VR-Jack ahh, sorry. Beryllium has the file.line :(
23:11 baweaver joined #salt
23:11 joehoyle doh!
23:11 joehoyle beryllium is > 2015.5 ?
23:12 murrdoc yeah
23:12 murrdoc its obvious
23:12 VR-Jack yeah, it's current dev
23:12 VR-Jack file.patch applies a patchfile
23:12 whytewolf file.append if you are just adding something to the end
23:12 VR-Jack ^^
23:13 joehoyle yeah, I could do append, as this line isn't elsewhere, luckily!
23:13 VR-Jack here's the link to the module. tons of stuff. http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.file.html
23:13 VR-Jack good for running one offs and sometimes in states
23:13 joehoyle does append add line returns?
23:13 joehoyle file.append /file '\nsomethig: else\n'
23:14 joehoyle perhaps
23:14 VR-Jack file.replace if something does exist
23:14 VR-Jack searches for pattern and replaces it
23:14 VR-Jack has prepend_if_not_found
23:15 VR-Jack good for a state as it can replace or append and knows if it hit a match
23:16 rojem joined #salt
23:17 whytewolf joehoyle: append will start on a new line iirc [never used it personally as i tend to just build states to controll everything] to carry in new lines i think you have to use "\n"
23:17 murrdoc or file.line might help
23:18 VR-Jack it should. most line editing is single line. replace requires special flags to do multiline
23:18 VR-Jack murrdoc: that's a ber option
23:18 joehoyle ah nice, thanks!
23:18 VR-Jack I think replace is bet option currently
23:18 VR-Jack best
23:21 whytewolf currently kind of wishing the nova module had network functions
23:21 amcorreia joined #salt
23:22 moloney What is the recommended way to deal with a file I just need temporarily for some state update?
23:24 moloney I guess I could use "module.run" to run "cp.cache_file"?
23:24 jschroeder joined #salt
23:31 iggy moloney: can you not use __context__?
23:31 bfoxwell joined #salt
23:32 murrdoc moloney:  what u trying to do
23:40 moloney I just need a firmware file when updating some firmware.
23:41 moloney iggy: Wouldn't I still need to call "cp.cache_file" or similar for it too show up in __context__?
23:43 bhosmer joined #salt
23:46 iggy oh, no, __context__ is just a "per state run" memory storage thing... you use it like any other dict, it just happens to be global and only persist across a state run
23:46 iggy dunno if that would work for your situation
23:47 moloney iggy: Ah, got you.  That does look helpful in general
23:47 bash124512 joined #salt
23:48 moloney I think I should just choose a place for the firmware file to live on the minion and use the standard "file.*" state options.  Just occured to me I will always need the file to compare versions anyway.
23:50 murrdoc joined #salt

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