Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-04-24

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

All times shown according to UTC.

Time Nick Message
00:00 scoates joined #salt
00:01 codehotter how do I ensure a service is restarted? let's say, on the first run, the config file is edited, but the sersvice restart fails. On the second run, no config is edited, so the service is not restarted.
00:01 otter768 joined #salt
00:02 mosen joined #salt
00:03 codehotter I want to restart sshd after changing its config so that it listens on port 222 isntead of 22
00:03 dalexander joined #salt
00:03 KyleG codehotter: I think you're looking for the Reactor system
00:03 KyleG http://docs.saltstack.com/en/latest/topics/reactor/
00:05 codehotter KyleG: which of my questions is that an answer to? What event would I react to?
00:05 KyleG event: SSH config changes
00:05 KyleG reaction: restart ssh
00:05 wt Is the some config option to enable ext pillars.
00:06 codehotter KyleG: what if the restart fails? Is the event 'ssh config changes' handled then? But ssh wasn't restarted
00:06 KyleG Not sure honestly, I guess you'll have to write your code to verify it worked or failback
00:06 blacked joined #salt
00:06 codehotter OK. When using a custom mode that is in _states, using yml works, but pyobjects says the name does not exist
00:06 KyleG service.running can probably be used there
00:07 codehotter after yml has worked once, the pyobjects also works
00:07 codehotter what's going on here
00:07 codehotter is pyobjects a bad idea? since it's less tested?
00:08 subsignal joined #salt
00:10 wt Okay, I think that git pillar is broken.
00:11 wt Is anyone else using 2014.7.5 with git pillar successfully?
00:11 wt I see the files properly getting cached locally.
00:11 wt It just doesn't seem to be looking in those files when building the pillar data for a minion.
00:12 ajw0100_ joined #salt
00:12 mephx joined #salt
00:14 joeto I have same filling for S3
00:14 joeto going to bed see you guys tomorrow
00:24 lnr joined #salt
00:24 lnr joined #salt
00:25 FeatherKing joined #salt
00:26 baweaver joined #salt
00:28 iggy codehotter: states say service.running... so the subsequent highstates will try to start the dead service
00:28 iggy assuming the init system/scripts report the proper state of the service
00:29 iggy wt: you're better off opening an issue (check if one is open first)
00:32 Ahrotahntee joined #salt
00:32 Ahrotahntee joined #salt
00:35 codehotter iggy: service isn't dead, it failed to stop =(
00:36 wt >2400 open issues
00:36 wt wow
00:37 solidsnack joined #salt
00:38 JDiPierro joined #salt
00:39 jhujhiti i'm trying to write a state which can retrieve a list of minions which will also execute the same state... how might i go about this?
00:39 MatthewsFace joined #salt
00:40 otter768 joined #salt
00:49 ajw0100 joined #salt
00:57 dalexander joined #salt
00:59 jhujhiti i guess i could mine the output of state.show_top
01:07 amcorreia joined #salt
01:07 eyeoh_ joined #salt
01:08 bhosmer_ joined #salt
01:10 ITChap joined #salt
01:14 wt iggy, If you are interested, https://github.com/saltstack/salt/issues/23006
01:14 wt These kinds of upgrade surprises are getting old.
01:19 eyeoh_ i ran into a serious problem with salt and how multi environments work. as long as the minion has an environment set it seems to be properly isolated to the file-root on the master but when the minions environment var isn't set it gets all the enmvironments. using a gain to set a environment and 1 big top.sls in the base dir didn't help. I've talk to some other people and they said it's broken
01:19 eyeoh_ and they only way they successfully built a multi environment system was using dedicated masters for each env
01:19 eyeoh_ there's a couple issues open about it and talk about solutions but so far I guess only the online manual talks about how top.sls files aren't working exactly as documented
01:20 eyeoh_ has anyone else tried a multi environment setup?
01:20 eyeoh_ with git, so top.sls files can't really change from branch to branch
01:23 baweaver joined #salt
01:23 yexingok joined #salt
01:25 kusams joined #salt
01:37 solidsnack joined #salt
01:42 dendazen joined #salt
01:45 yomilk joined #salt
01:45 ITChap joined #salt
01:45 solidsnack joined #salt
01:58 wt great, custom grains don't appear to be working either
02:02 wt is there anything like master tops for pillars?
02:03 TyrfingMjolnir joined #salt
02:08 ITChap joined #salt
02:10 kbyrne joined #salt
02:11 gmoro joined #salt
02:12 favadi joined #salt
02:29 zwi joined #salt
02:32 ice joined #salt
02:38 evle joined #salt
02:40 scbunn joined #salt
02:43 hasues joined #salt
02:43 hasues left #salt
02:44 donmichelangelo joined #salt
02:45 Singularo joined #salt
02:51 ITChap joined #salt
02:56 solidsnack joined #salt
02:56 ipmb joined #salt
02:57 thayne joined #salt
03:00 desposo joined #salt
03:01 zwi joined #salt
03:06 refnode__ joined #salt
03:09 bhosmer_ joined #salt
03:10 subsignal joined #salt
03:17 writtenoff joined #salt
03:20 hybridpollo joined #salt
03:21 wt Okay, I have finally found something that helps.
03:24 wt I have to both disable git_pillar and run "salt-master -l debug" in the foreground
03:25 wt then I can actually run the saltutil.sync_grains commmand from a minion successfully
03:25 SheetiS joined #salt
03:29 nafg joined #salt
03:29 fusionx86 joined #salt
03:31 ITChap joined #salt
03:33 wt turning off git fileserver backend seems to help
03:34 wt nevermind
03:34 wt it's so inconsistent
03:36 SeeDickCode joined #salt
03:40 mwpher joined #salt
03:43 wt turning off the git fileserver backend helped a lot
03:49 beneggett joined #salt
03:52 radd joined #salt
03:54 I joined #salt
04:00 solidsnack joined #salt
04:01 hybridpollo joined #salt
04:06 nene i am trying to do something with pillars
04:07 nene but not getting any o/p
04:08 nene here is my work http://pastebin.com/JCLqJAVu
04:08 nene can some one help?
04:09 nene im not sure why salt '*' saltutil.refresh_pillar or salt '*' pillaritems not returning anything
04:11 solidsna_ joined #salt
04:13 pheer joined #salt
04:14 pheer left #salt
04:15 yomilk joined #salt
04:18 solidsnack joined #salt
04:20 yomilk joined #salt
04:20 vandemar I can set something like this up without salt and I can probably cobble together a way to do it with salt, but I'm not sure how/where to approach it efficiently with salt: CF publishes its list of netblocks. I need to periodically check the urls for changes, when they change do a simple sed on them to turn them into nginx directives for inclusion in the web config, and then trigger all ...
04:20 vandemar ... nginx-role minions to run the config-mirroring state.  Any advice?
04:21 seev yes, use a cmd.run that fires a shell script
04:21 seev have it check for changes using a download + checksum, and abort if nothing changed
04:23 dendazen joined #salt
04:24 vandemar targeting the minion on the master server?
04:26 hybridpollo joined #salt
04:33 catpig joined #salt
04:33 ITChap joined #salt
05:04 ckao joined #salt
05:06 blacked joined #salt
05:09 TyrfingMjolnir joined #salt
05:10 bhosmer_ joined #salt
05:12 pdayton joined #salt
05:13 nafg__ joined #salt
05:15 zwi joined #salt
05:19 bmcorser joined #salt
05:22 catpigger joined #salt
05:26 scarcry joined #salt
05:26 zwi joined #salt
05:28 malinoff joined #salt
05:31 jasonrm joined #salt
05:39 solidsnack joined #salt
05:47 krelo joined #salt
05:51 ITChap joined #salt
05:54 shubzero joined #salt
05:55 scoates joined #salt
05:55 Kelsar joined #salt
05:55 otter768 joined #salt
05:57 cztanu joined #salt
05:58 cetanu joined #salt
05:59 yexingok1 joined #salt
05:59 cetanu joined #salt
06:00 cetanu joined #salt
06:01 cetanu joined #salt
06:02 colttt joined #salt
06:02 cztanu joined #salt
06:03 I3olle joined #salt
06:10 faust joined #salt
06:14 tmh_ joined #salt
06:21 kopnd56 joined #salt
06:23 wt joined #salt
06:23 wt Is there any reason that anyone can think of why a custom grain delivered via salt://_grains would not run on some machines?
06:24 joeto joined #salt
06:24 mosen maybe if the grain depended on some import statement?
06:25 wt I don't see anything in the debug log.
06:26 wt specifically, "salt-call -ldebug grains.items"
06:26 wt I can see the files cached into the minion's cache dir in /var/cache
06:28 KermitTheFragger joined #salt
06:28 mosen hmm
06:31 joeto1 joined #salt
06:31 und1sk0 I have a 'env':\n  'fqdn:name*':\n    - match: grains_pcre\n[...etc] in my top.sls that doesn't seem to want to execute on any matching minion
06:31 walker_ joined #salt
06:31 und1sk0 it will execute 'base':\n  '*'\n    - core
06:32 cztanu joined #salt
06:33 und1sk0 doesn't seem to be getting the whole top.sls either:
06:33 und1sk0 [root@api1 /opt/local/var/cache/salt/minion]# wc -l files/base/top.sls
06:33 und1sk0 3 files/base/top.sls
06:33 und1sk0 heh NM i have a borked symlink ;)
06:33 und1sk0 derp
06:34 mosen hehe
06:36 mosen wt: can you call saltutil.sync_grains or sync_all to make sure the grains are synced up?
06:39 joeto joined #salt
06:39 tmh_ joined #salt
06:41 wt mosen, I did. It wasn't pulling in the file
06:41 wt However, if I run the salt master in the foreground. It works. WTF?
06:41 mosen wt: ahh ok
06:42 mosen wt: got a custom file_roots config in the /etc/salt/minion ?
06:42 mosen I'm just trying to exhaust options
06:42 wt in the minion?
06:42 wt no
06:43 mosen ahh ok
06:43 wt mosen, I appreciate the help
06:43 wt mosen, we may end up having to pick a different config management system.
06:44 flyboy joined #salt
06:45 mosen wt: so the grain exists at /srv/salt/_grains? sure if you want :) I'm not a saltstack guy or anything :)
06:45 jxm_ joined #salt
06:45 JayFK joined #salt
06:46 wt mosen, sorry, I am just frustrated
06:46 rofl____ salt<3
06:46 nene i created one sample pillar and ran  salt '*' saltutil.refresh_pillar and salt '*' pillar.items on master.. but not seeing any changes
06:46 wt Yes, the grain module exists in /srv/salt/_grains
06:46 rofl____ you will never be disappointed again wt
06:46 wt some minions even get it while others do not
06:46 rofl____ youll do more dailywtfs with puppet
06:47 mosen wt: fair enough. I think the doco is pretty ahh..
06:47 mosen wt: disorganised :)
06:47 wt rofl____, I've used puppet in the past. I have no illusions about it or chef.
06:47 nene mosen: ^^
06:48 wt See, the fact of the matter is I had a nicely working 2014.7.1 infra working. 2014.7.5 appears to be broken.
06:48 mosen wt: yeah I read that earlier i think
06:48 wt I'm assuming it must be working for someone. So I am trying to figure out if I am tripping on some known issue.
06:49 hybridpollo joined #salt
06:50 wt daemonizing makes the problem worse
06:50 wt use gitfs or git_pillar makes things worse
06:51 mosen not sure if its a 2014.7.5 issue as im still on 7.1.. i could check real quick.. i have some custom grains
06:54 wt The thing is, I can tell that the grain isn't even running since I inserted a pdb.set_trace(), which will throw me into a debugger if it runs
06:54 wt it runs on some machines and not on others.
06:55 subsignal joined #salt
06:55 wt and now that my master is running in the background again, the minion I just had it running on is not running it after syncing and calling grains.items
06:57 hybridpollo joined #salt
07:05 lb1a joined #salt
07:06 blacked joined #salt
07:07 jxm_ basepi, do you remember looking at the the problem mentionned here: https://groups.google.com/forum/#!topic/salt-users/9cNJKiS2lQw ?
07:07 jxm_ I am hitting it with snmpd, and could use a hint to start debugging it...
07:08 jxm_ Not familiar with the codebase, but I really need to scratch that itch, a workaround outside of salt is not going to satisfy me...
07:10 Romlok joined #salt
07:11 bhosmer_ joined #salt
07:11 hebz0rl_ joined #salt
07:12 jxm_ Looking at the code, mod_watch should trigger anyway, which it does not, and debug with -l all on the minion just give no explanation
07:24 Grokzen joined #salt
07:25 wt ok, I found that my master had reverted to using git
07:25 wt I updated the config file directly
07:25 wt Disabling the git fileserver backend and using files instead is working.
07:25 wt however, that is a lame solution
07:27 wt jxm_, you  shouldn't need require and watch
07:27 wt I think watch is a superset of require
07:30 bemehow joined #salt
07:30 jhauser joined #salt
07:32 CeBe joined #salt
07:33 blacked joined #salt
07:33 solidsnack joined #salt
07:34 jxm_ wt, it is. But I don't use require and watch. The problem is about mod_watch not restarting the service if enabled: true is set
07:36 krelo joined #salt
07:37 jxm_ Mmmmh, #21084 seems heavily related, need to check if it fixes this one too (probably #18311 related)
07:40 evle1 joined #salt
07:42 markusr joined #salt
07:44 ndrei joined #salt
07:47 badon joined #salt
07:56 otter768 joined #salt
07:57 markusr left #salt
08:00 chiui joined #salt
08:05 kawa2014 joined #salt
08:09 Xevian joined #salt
08:11 Ashwee joined #salt
08:12 Ashwee I want to state to run only if a certain registry value is present or not present. I figured out that i need to use 'unless' or 'onlyif' and reg.read_key I just don't know how to (with salt syntax) turn "reg.read_key HKEY_LOCAL_MACHINE 'path' 'valName'" into a logical test on the unless/onlyif line
08:18 lothiraldan joined #salt
08:19 blacked joined #salt
08:20 jrluis joined #salt
08:20 babilen "registry value" -- Are you referring to the Windows Registry?
08:20 Ashwee yep
08:21 babilen Is reg.read_key a salt execution function?
08:21 aquassaut joined #salt
08:21 ptinkler joined #salt
08:21 Ashwee salt.modules.reg        http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.reg.html
08:22 Ashwee hope that answers that? as i'm not sure
08:23 ptinkler hey guys, any idea what a hey guys, anyone able to help me with my output here: http://pastebin.com/B7nWF6Va
08:23 ptinkler my first salt state is failing, the one to create a group called supervisor
08:23 ptinkler and the result is "None" with no error logging, so I'm a bit lost
08:24 ptinkler oh hang on...
08:25 ptinkler says the group is "set to be added" and not actually created
08:25 ptinkler that's interesting.
08:25 ptinkler what on earth could be causing that? doing this as root on a fresh digital ocean ubuntu 14.04 droplet
08:37 refnode__ joined #salt
08:37 markm joined #salt
08:39 refnode joined #salt
08:41 CeBe1 joined #salt
08:48 Hell_Fire joined #salt
08:54 joeto Hi guys, I have an issue with s3fs and pillars, they are not loaded at all. If I move files localy everithing is workin :(. Salt version is 2014.7.5 is there any new option which I need to use or?
08:54 joeto I mean if I configure master to use local filestore not s3
08:55 pdx6 joined #salt
08:56 wnkz joined #salt
08:56 ktosiek joined #salt
09:01 wnkz_ joined #salt
09:04 yidhra joined #salt
09:05 evle joined #salt
09:09 Auroch joined #salt
09:10 eliasp yepee… managed to let Salt run into a recursion because it apparently doesn't catch all recursive requisites properly… worked on a patch for saltstack-formulas/mysql-formula: http://pastie.org/10111213
09:10 bluenemo joined #salt
09:12 bhosmer joined #salt
09:12 martineg_ left #salt
09:16 markm_ joined #salt
09:18 Ashwee bah still struggling with this logical test thing :[
09:28 denys joined #salt
09:31 bhosmer joined #salt
09:38 blacked joined #salt
09:38 TyrfingMjolnir joined #salt
09:40 peters-tx joined #salt
09:42 thayne joined #salt
09:57 otter768 joined #salt
10:00 joeto is it posible to install specific version of salt with current bootstrap script and ppa repo? to put version after "...  stable" or?
10:04 dramagods joined #salt
10:06 VSpike Which do people prefer for automatic AWS builds completely? The boto-* states + salt-cloud? AWS CLI + salt-cloud? CloudFormation?
10:14 joeto Its really depends what you want to achive and how. We are moving from aws cli to salt-cloud and cloud formation (we will use all of them for now), because our infrastructure allow this . CloudFormation actually will be used only for VPC configuration. The goal is to have automated initial deployment and cloning of envs. So really depends of requirements for me.
10:15 is_null hi all, wouldn't it be cool to be able to use relative paths in file_roots and pillar_roots ?
10:18 __ale__ joined #salt
10:18 giantlock joined #salt
10:28 babilen is_null: Relative to what?
10:29 GnuLxUsr joined #salt
10:30 is_null babilen: to its own path ? what does relative means ?
10:31 is_null ie. if --config-dir=foo then in say foo/minion it would be relative to foo/
10:31 is_null would that make any sense ?
10:33 babilen is_null: The current default is for file_roots to be /srv/salt and references to states are relative to *that*. I see no advantage in changing that and mixing configuration files with file_roots or pillar_roots
10:33 babilen Why do you think that that would be great?
10:34 asido joined #salt
10:35 yexingok2 joined #salt
10:37 is_null babilen: it gets you going faster with salt-formula
10:37 babilen How so?
10:39 asido is it expected to see state.highstate fail in the following way: https://gist.github.com/Asido/f83d68371ff712b1e557 ? meaning that the last target failed, because the first 2 user/groups were not actually added, but rather tested for success
10:39 is_null then you don't really need a bootstrap script anymore, just install salt and do a highstate with -c bootstrap/, so i thought it would be nice for this usage to have relative paths inside bootstrap/minion
10:40 * zipkid agrees with is_null on the relative paths
10:41 dendazen joined #salt
10:47 Ph-x Wohoo! Salt 2014.7.5 available in EPEL yum repos. It's a good day :)
10:52 echo joined #salt
10:59 joeto this version have some issues, test it first
11:00 ninkotech joined #salt
11:15 wnkz joined #salt
11:26 slav0nic joined #salt
11:26 slav0nic joined #salt
11:28 echo joined #salt
11:31 xf10e joined #salt
11:31 xf10e hi everyone
11:31 PI-Lloyd joined #salt
11:35 I3olle joined #salt
11:38 jonatas_oliveira joined #salt
11:38 Tyrm joined #salt
11:42 joehh1 joeto: which version are you after?
11:42 joehh1 i'm guessing 2014.7.4
11:44 amcorreia joined #salt
11:45 joeto joehh1: yes
11:46 joehh1 trusty or precise?
11:46 joeto trusty
11:47 xf10e we don't have a nice way to fail a state when necessary pillar-data is missing, have we?
11:48 lothiraldan joined #salt
11:48 joeto joehh1: to not mislead you, I am talking about bootstraping and staying on 2014.7.4 till all issues which I hit are solved in newer versions.
11:49 joehh1 no worries - I'm going to add a specific ppa for 2014.7.4
11:49 joehh1 and re upload to launchpad
11:50 joehh1 it is a common request for old point releases
11:50 PI-Lloyd +1
11:50 PI-Lloyd never made any sense to me to not have older versions available, it's caused us much ballache
11:50 wnkz joined #salt
11:51 zwi joined #salt
11:51 joehh1 not a deliberate thing - and having a ppa per release feels a little hacky, but it should keep most happy
11:51 funzo joined #salt
11:53 PI-Lloyd for me it's more a case of not being able to version pin salt packages without a highstate moaning that the version requested is not available
11:54 PI-Lloyd we ended up re-uploading versions to our private repo to get around it, which is far from ideal
11:54 joeto thank you
11:55 __number5__ joehh1: you guys should set up your own ubunut/debian repos using aptly
11:55 __number5__ or something
11:56 fredvd joined #salt
11:57 diegows joined #salt
11:58 otter768 joined #salt
11:59 bkleef joined #salt
11:59 fxhp joined #salt
12:00 joehh1 packages currently building in https://launchpad.net/~saltstack/+archive/ubuntu/salt2014-7-4
12:01 joehh1 ppa:saltstack/salt2014-7-4
12:05 teogop joined #salt
12:06 bersace joined #salt
12:07 bersace Hi, how to isolate a minion in a specific saltenv without environemnt: ?
12:07 bersace when i run state.show_top, it shows all envs :(
12:14 joehh1 packages for 2014.7.4 for ubuntu now available from ppa:saltstack/salt2014-7-4
12:14 joehh1 feels a little backawards though :)
12:14 joehh1 any other releases that people are attached to?
12:17 faust joined #salt
12:17 XenophonF joined #salt
12:18 faust left #salt
12:19 bhosmer_ joined #salt
12:19 __number5__ joehh1: ubuntu 12.04?
12:21 __number5__ bersace: how do you run state.show_top it should only match your current minion? or you run it with salt-run?
12:21 joehh1 yes - though I meant salt releases
12:22 bersace __number5__: salt-call
12:23 mly joined #salt
12:28 slav0nic left #salt
12:28 ndrei joined #salt
12:29 cmcmacken joined #salt
12:32 zwi joined #salt
12:32 redzaku joined #salt
12:34 pdayton joined #salt
12:34 pdayton joined #salt
12:39 tmclaugh[work] joined #salt
12:45 viq joined #salt
12:45 asido I have a state in base, which I want to extend in dev and prod environments with things which are not common for different environments. what is the recommended approach in this case?
12:47 jdesilet joined #salt
12:47 ksj joined #salt
12:50 badon_ joined #salt
12:53 subsignal joined #salt
12:54 XenophonF asido: my base environment is empty
12:54 XenophonF asido: except for top.sls
12:55 asido XenophonF, that wasn't for me I guess
12:55 XenophonF asido: i assign a minion to an environment via Pillar (e.g., "environment: development")
12:55 XenophonF asido: and then i use compound matches in states top.sls to make sure that the minions only pick up SLS assignments from the appropriate environment
12:56 XenophonF asido: https://github.com/irtnog/salt-states/blob/master/top.sls#L43
12:57 ksj what ways do people deal with "undoing" states? By this I mean, if I have a simple state that sets up some users and installs some packages, would it be best to create an "undo" package if I want to remove those packages and users from the server?
12:58 XenophonF asido: there are other ways to arrange things, but this makes the most sense to me
12:58 asido XenophonF, is this an answer to a question how to extend a state? I find it hard to follow
13:00 Deevolution ksj: That's more or less what's needed.  You can build states in such a way as to pass in (via Pillar for example) whether to add or remove the configurations.
13:00 XenophonF asido: you're asking about environments
13:00 Deevolution ksj: Although to be honest I generally only do this where it's actually important to un-configure things.
13:01 XenophonF as far as i know you can't reference development:foo/additional.sls from base:foo/init.sls
13:01 bastion1704 joined #salt
13:02 bkleef joined #salt
13:02 XenophonF asido: can you give us a concrete example of what you're trying to do?
13:02 asido XenophonF, yes, and what I want to do is to have a state with common rules in base, which other environment would be able to extend. this is what I tried: have base/ics.sls state and in dev/ics.sls start with ``include: - base: ics`` followed by new dev environment specific rules
13:03 dendazen joined #salt
13:04 lothiraldan joined #salt
13:04 asido but I didn't figure how to make it work yet. I am still trying things out. it either ignores base/ics.sls or says 'Detected conflicting IDs, SLS IDs need to be globally unique.'
13:04 JDiPierro joined #salt
13:04 asido where the conflicting ID is the one in base/ics.sls
13:05 asido 'The conflicting ID is '/test.txt' and is found in SLS 'prod:ics' and SLS 'dev:ics''
13:08 seblu joined #salt
13:11 magnus-lycka joined #salt
13:12 evle1 joined #salt
13:13 ksj Deevolution: thanks. I'm still trying to figure out the best way to approach this...making services only available when necessary. I don't think there's one clean, simple solution unfortunately
13:13 amcorreia_ joined #salt
13:13 Deevolution ksj: NP.  There are numerous ways to make it work.  You have to figure out what's best for your uses.
13:16 dkrae joined #salt
13:17 dalexander joined #salt
13:19 wpot joined #salt
13:19 cpowell joined #salt
13:19 magnus-lycka We're using git.latest to get a tagged revision of our application from a GIT repo. We move the same tag as new versions are ready to be used. The problem is that git.latest looks in its local (old) version of the repo, and find the tag (in its old place) there, so it doesn't bother to pull, and we don't get the software update we planned. Any idea on how to use this. We can force it to always wipe the old repo and
13:19 magnus-lycka clone again, but it would be nice if you could just force it to look at the remote repo and fetch what it needs.
13:20 lothiraldan joined #salt
13:21 FeatherKing joined #salt
13:23 fusionx86 joined #salt
13:23 babilen you really shouldn't "move tags"
13:24 babilen A tag references the same SHA forever
13:25 dyasny joined #salt
13:26 XenophonF so i have the following jinja template - https://gist.github.com/xenophonf/cf0789d11b411f8c5bd6 - but i'm getting this render error - https://gist.github.com/xenophonf/604f5bc0dd725df4c4f0
13:26 babilen You probably have to ensure that salt fetches and prunes "old" tags .... http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.git.html might come in handy for that ... but then, don't move tags. Really.
13:26 XenophonF the python code is basically [partner for partner in partner_list if partner not in ipv4_list]
13:26 JoeHazzers i want to install systemd user units system-wide, but only if the machine has systemd. instead of having a big checklist of OSes, can't I find out what the provider for the service module/state is from salt?
13:26 XenophonF any ideas why that isn't working?
13:27 babilen XenophonF: You can't use list comprehension
13:27 magnus-lycka The idea is that we somehow mark that a certain revision in the GIT trunk is ready for e.g. customer testing. It will change over time which version this is.
13:27 XenophonF babilen: well, that explains that
13:28 babilen magnus-lycka: You should have branches for that and then, if you update that "it is ready" branch a git.latest would work. A tag is a (optionally signed) name for one specific SHA/commit that *never* changes.
13:28 magnus-lycka It's easy to simply state the same tag in a salt state, and it's easy to tell Jenkins to move a tag in git when it succeeded in running through all the tests.
13:28 babilen XenophonF: jinja2 doesn't really make it easy to use Python .. it really isn't the best templating engine for this usecase
13:29 magnus-lycka If you have another good idea for how to agree between Jenkins, Git and Salt, please share!
13:29 zircote joined #salt
13:29 babilen magnus-lycka: Yes, use a dedicated branch into which you *merge* blessed commits
13:30 babilen the HEAD of that branch reflects the last "blessed, tested and nice" commit
13:30 paolo hi, i have a problem running a command from a state. if i execute the command from the shell everything is fine, but from the state it seems that the command args are ignored. could someone kindly have a look? http://pastebin.com/mX7iqM1Q
13:32 babilen paolo: Does it rely on environment variables to figure out how to connect?
13:32 diegows joined #salt
13:33 magnus-lycka I was trying to avoid merges. :-) Three way merges usually work fine as long as noone changes anything in the branch you merge to, but a merge is a merge, not a copy. If I ran the tests on rev X in trunk, I want to deploy rev X in the trunk, not something else which I hope is identical.
13:33 ja-s joined #salt
13:34 babilen magnus-lycka: It would be a simple ff merge from the "testing" to the "blessed" branch once jenkins sees that commit X passes all tests.
13:34 paolo babilen: more than probably, i forgot that, thanks i will use the "env" argument.
13:35 babilen paolo: Salt simply cleans the environment of *everything* that isn't strictly needed. If you rely on some variables to be there you have to pass them explicitly.
13:37 XenophonF babilen: do you think the following jinja would work? https://gist.github.com/xenophonf/560612f1c9c180a07348
13:37 jxm_ Quick one: I hesitate using nodegroups, but I am afraid they will lack flexibility down the line. I would like to have groups like 'vm', 'bare-metal' but also 'debian7', 'rhel6', and will need to target 'vm_debian7' and several permutations. With nodegroups, my understanding is that I will need to define all those compound groups beforehand, as match: nodegroup supports only one group name and compound matching does not suppo
13:37 jxm_ rts nodegroups. An alternative would be using Jinja macros, which might be more flexible. What is recommend best practice for this usecase?
13:38 JoeHazzers how can i check that a module is loaded from an sls file?
13:39 sulfur joined #salt
13:40 dramagods joined #salt
13:40 jxm_ An other possibility I thought of would be to use pillars to assign something like server_class to my minions, but that would have to be done dynamically based on grains
13:41 Grokzen joined #salt
13:42 magnus-lycka I still think it's odd for salt to assume that git tags don't move, since git allows you to move tags. The best approach might be to let packaged software rather than a git revision pass through the deployment pipeline. Assuming that a merge is a pure copy (and not actually a merge) is somewhat risky, even if it *should* work under certain circumstances unless someone does something stupid.
13:43 bersace left #salt
13:44 ndrei joined #salt
13:44 Romlok magnus-lycka: if you want to be absolutely sure of where a branch points, you could just `git reset --hard`
13:46 magnus-lycka Ok, I'll look at that, thanks!
13:46 Tyrm joined #salt
13:47 babilen XenophonF: That should work
13:47 _ale1_ joined #salt
13:48 babilen jxm_: You don't need nodegroups for debian7 as you can achieve that targeting much easier with compound matchers on grains
13:48 babilen jxm_: Why would pillars have to be assigned based on grains?
13:48 babilen magnus-lycka: It is normal for git that changed tags aren't fetched. That has nothing to do with salt
13:49 magnus-lycka How can I make it pull then?
13:49 racooper joined #salt
13:49 babilen magnus-lycka: You should have a branch into which you perform only ff merges .. I don't understand your problem with that.
13:50 babilen magnus-lycka: You might want to take this to #git
13:50 timoguin joined #salt
13:52 asido how are variables like {{env}} in states called? pillars?
13:52 andrew_v joined #salt
13:53 c10 quick question, how do I get the timestamp to use a filename in a state?
13:53 jalbretsen joined #salt
13:54 _Cyclone_ joined #salt
13:54 jxm_ babilen, I am trying to avoid repeated typing of matchers like "G@cpu_flag:hypervisor G@oscodename: wheezy I@role:development"
13:55 jxm_ babilen, instead, I would like to be able to simply match on some shortname for this, whose actual targeting might evolve over time in a central location
13:56 XenophonF thanks babilen - it rendered properly
13:57 XenophonF oddly, cmd.script doesn't rename its source argument to its name argument
13:57 jxm_ babilen, so re. your first point, yes I knoe, it is for the compound matches that this gets repetitive and I would like to have shortcuts
13:57 XenophonF so given source: salt://path/something.bat.jinja and name: something.bat, it ends up trying to run something.bat.jinja
13:58 babilen jxm_: So you essentially want "aliases" based on compound matchers?
13:58 bemehow joined #salt
13:59 jxm_ babilen, yes, I guess you could call it this way
13:59 babilen It doesn't exist, but I would like that feature
13:59 jxm_ babilen, me too :-)
13:59 otter768 joined #salt
13:59 babilen I figured :D
13:59 jxm_ :D
14:00 kusams joined #salt
14:00 jxm_ babilen, what you call "alias", I called "class"
14:00 kaptk2 joined #salt
14:00 babilen I'd probably call it "group alias"
14:01 babilen Either way, you can't have it
14:01 davisj Not sure if this provides "aliases" but it might be worth a look... http://docs.saltstack.com/en/latest/ref/tops/all/salt.tops.reclass_adapter.html
14:01 jxm_ babilen, the thjing is that it matches the semantics of my platform. I have classes of machines deployed, think generations of VMs, generations of hypervisors.
14:01 jxm_ But alias is indeed more generic, it depends how you think about it
14:02 jxm_ Think the class of a starship in StarTrek
14:03 jxm_ I have 3 classes of VMs in production currently, let's call them "akira", "intrepid" and "galaxy"
14:03 babilen I called it "alias" as I thought of it as a "named compound matcher to avoid typing"
14:03 jxm_ Same for hypervisors
14:03 sandah joined #salt
14:03 jxm_ Same for software routers
14:03 jxm_ etc...
14:04 babilen Why don't you use environments with compound matching in your top.sls ?
14:04 babilen Would that be appropriate?
14:04 jxm_ So, one possibility is just having a pillar listing those minions statically, but this is cumbersome. I can derive the alias (see, I am trying to put myself in your shoes here :-) ) from some grains data and a couple of static pillar data, so I though there must be a way...
14:05 jxm_ babilen, I just started testing salt yesterday, so I do not know what environments are
14:05 jxm_ Let me look that up
14:05 babilen The question is: What would you like to achieve?
14:06 xf10e here we go: http://pastebin.com/MvppytT2
14:06 babilen I mean is this all about you being lazy to type "salt -C "something awfully complex"" ?
14:06 jxm_ babilen, basically assigning the relevant state to a new minion on-the-fly
14:06 xf10e more next week ;) v yas
14:06 jxm_ babilen, in part, yes, but also to avoid errors
14:07 babilen jxm_: You could target the states in top.sls based on compound matchers
14:07 jxm_ I have many of those "something awfully complex" things, and a mistake in picking one could cause a disaster
14:07 jxm_ Also, the definition of that "something awfully complex" might vary with time
14:07 Tyrm joined #salt
14:07 jxm_ Let's say we upgrade our intrepid class VMs from wheezy to jessie
14:08 babilen (tomorrow!)
14:08 ndrei joined #salt
14:08 jxm_ Now I need to reflect that in my sls files with the minimum risk for error
14:09 babilen You have a circular definition there ...
14:09 jxm_ babilen, yes, that works. But it forces me to use a certain kind of layout if I want to avoid repeating myself
14:09 jxm_ Mmmh, it is long to explain, let me try
14:09 babilen I mean "intrepid class VMs" either uses "is running wheezy" as definition or not.
14:09 jxm_ YEs
14:10 babilen You, therefore, cannot upgrade them to jessie because they would no longer be part of the "intrepid" class
14:11 babilen That means that you base your definition of "intrepid" on something else and that these boxes just happen to run wheezy or jessie, but that that isn't some integral part
14:11 magnus-lycka babilen: I don't want to assume that merge == copy, even if that's true 99.9% of the time in certain conditions. We got it to work running a command "git fetch --tags && git reset --hard <tag name>".
14:11 babilen Do you define those attribute <-> class mappings in a db ?
14:11 jxm_ babilen, imagine: state my_intrepid_specific_snmp_config matching "class: intrepid". But this in turns calls the snmp state. And the snmp state has a map template that acts differently depending on the installed OS.
14:11 babilen magnus-lycka: That is super fugly
14:11 magnus-lycka Eventually I think we'll let Python packages pass through the deployment pipeline instead of git revisions.
14:13 babilen jxm_: Yeah, sure. States can easily be tailored to "do the right thing for different releases or distributions"
14:14 jxm_ babilen, actually I had the same kind of organisation problem with cfengine, and later with puppet. It is common to all of those tools. Some states/recipies/whatever you call them expect you only apply them on certain environments, while otheres are going to be self-adapting depending on the environment.
14:14 jxm_ It's never a nice clean top-down hierarchy
14:15 jxm_ You cannot say I have slat/intrepid salt/enterprise and be done with it
14:15 jxm_ There is oging to be some states shared among those, some of which specific to an environment, and some generic (more or less),
14:15 magnus-lycka In my experience it's dangerous to rely on the assumption that merge == copy.
14:16 StDiluted joined #salt
14:16 babilen jxm_: The basic, and most important, question is: How do you want to define what "groups / classes / roles / ...." (whatever you call it) a certain minion belongs to. Salt is quite powerful, but you have to answer that question *once* and then design your environment in line with that decision.
14:16 Brew joined #salt
14:16 babilen jxm_: Give me a minute and I elaborate
14:16 jxm_ babilen, exactly, I think you got my problem. This is the basic question. And I am currently playing with salt to see what is the best fit for it associated with my environment
14:17 redzaku joined #salt
14:17 dave_den joined #salt
14:17 jxm_ One way could be to only develop clean, generic formulas, and have role-based top-level states and be done with it
14:17 babilen jxm_: You basically have two basic options: 1. You have a pre-defined list based on one attribute that *never* changes (minion id would be a prime example) or 2. You have "dynamic" classes based on certain attributes of your minions that reflect their current status
14:17 jxm_ Unfortunately, this never works 100%
14:18 jxm_ (re my comment, not yours)
14:18 babilen My feeling right now is that you actually want to tell a box *once* that it will forever be an "intrepid" box and it should do whatever it needs to do to achieve that.
14:18 babilen Is that correct?
14:18 jxm_ yes
14:19 jxm_ and the states must adapt whenever we decide to upgrade all intrepid boxes to use the next release
14:19 jxm_ (of the OS)
14:19 jxm_ Or to use a different storage pool
14:19 jxm_ Actually it is even more complex than that because of staging
14:19 babilen Okay, are all intrepid boxes identical or do they rather reflect a certain "stage" in a testing / deployment process? (in that changes percolate through intrepid to akira to tetsuo to ....) ?
14:20 jxm_ The upgrade process will split the intrepid boxes in an staged-for-upgrade and do-not-touch-yet
14:20 jxm_ groups
14:21 jxm_ babilen, more like identical
14:21 Deevolution Has anyone else seen 2014.7.4 reporting it's version as 2014.7.0?
14:21 babilen How do "intrepid" boxes differ from "akira" ones?
14:21 jxm_ One might use RHEL6, the other one is Debian wheezy based
14:21 jxm_ One might use iSCSI storgae
14:21 edrocks joined #salt
14:21 jxm_ The other FC
14:21 jxm_ One is going to be based on KVM (no ntp required), the other under a Xen hypervisor (we want NTP!)
14:21 jxm_ etc.
14:22 racooper sounds like there's some major standardization needed in that environment.
14:22 jxm_ racooper, not going to happen, that's simply life
14:23 frankers joined #salt
14:23 babilen jxm_: And you have staging along "layers" in each of "Akira" and "Intrepid" ?
14:23 jxm_ racooper, basically, there are 5 generations of virtualization clusters
14:23 babilen *sigh*
14:23 frankers hi folks.
14:23 jxm_ Some because we decided to go for KVM instead of Xen and RHEL to debian at some point in time
14:23 Deevolution NM.  Figured out what was going on.
14:24 jxm_ Other because of purely licensing reasons (hyper-V running windows server 2012 VMs makes more sense re. licensing and a couple of features)
14:24 jxm_ etc.
14:24 denys joined #salt
14:24 frankers anyone here running their salt-master states completely via gitfs and is unsing different branches as environments?
14:25 jxm_ babilen, yes, when updating all akira to use the last service pack, or migrating all intrepid to FC, we need staging
14:25 babilen jxm_: Could you say two or three more words about the "staging" ? I have the feeling as if your "akira" / "intrepid" classes aren't actually very important, but just some idiosyncrasy you have to adapt states for (in that states can work on KVM / Xen / Debian / CentOS / ...), but that the actual decision as to which state is on which box is rather based on your "staging" layers
14:25 jxm_ babilen, no, there are actual important differences
14:26 jxm_ Some host VDI client environements, using different NTP, DNS, network topologies than the other
14:26 babilen sure, but you would adapt those based on those attributes
14:26 jxm_ Yes, that could work
14:26 babilen Those aren't important differences
14:27 jxm_ staging basically means:
14:27 babilen I mean you decide that foo class gets an NTP state, but you set different NTP servers in pillars for boxes based on something
14:27 JoeHazzers do any of you have some nice jinja tricks that can help me reduce the bulk of the following in say, sshd_config: {% if sshd.permit_root_login is defined %}\nPermitRootLogin {{ sshd.permit_root_login }}\n{% else %}PermitRootLogin no\n{% endif %} ?
14:28 jxm_ "We'll upgrade all the XYZ contract customers to the new antivirus"
14:28 JDiPierro joined #salt
14:28 jxm_ "OK, let's try it first with not-so-important customers A, B and C" -> stage1
14:28 jxm_ (That is after internal testing, compliance, etc.)
14:29 fyb3r joined #salt
14:29 jxm_ "OK, now lets migrate D which is a heavy one and might fail in different ways" -> stage2
14:29 jxm_ etc.
14:29 Deevolution JoeHazzers: What's wrong with what you wrote?
14:29 babilen I have the feeling as if you want to do the following: 1. Define nodegroups based on a collection of attributes (feel free to generate those from data in an external pillar/database if you want to be able to adapt those easily) 2. Design states according to current formula best-practices (check out the salt formula) in that they can adapt to different distributions / distribution releases 3. Define pillar data that drive the states in 2 and in ...
14:29 JoeHazzers Deevolution: it gets messy/long quickly
14:29 babilen ... which you overwrite data based on merging.
14:29 babilen jxm_: I also think that you should take a long look at reclass
14:29 babilen (as an alternative)
14:30 Deevolution JoeHazzers: I don some jinja where I include other files in a given file, which would allow you break up the jinja into smaller chunks I suppose.
14:31 JoeHazzers Deevolution: i recall a very interestingly horrid job for me was managing ini-like configuration files of openstack services about this time last year
14:31 jxm_ babilen, looking right now
14:31 Deevolution JoeHazzers: Something like {% include FILENAME %}
14:32 Deevolution JoeHazzers: I can see how that could be a problem.
14:32 jxm_ babilen, haaa, interesting, I did not know about reclass
14:32 jxm_ So, basically you suggest using an external classifier instead of trying to shoehorn my class stuff in salt/jinja?
14:33 babilen jxm_: I'd also consider an approach based on minion lists in an external pillar and then targeting based on that pillar. (you could reference a MySQL database or whatever you use to manage your customers for that)
14:33 frankers when using my own salt state directory in a git repo, mixed with formulas from github, I run into issues when using branches as environments. IE: I have a dev environment set up in my top.sls where I want to install ntp.ng (from the github formula) on some machines. now salt complains that it cannot find ntp.ng in the environment 'dev'.
14:34 babilen jxm_: No, I'm not necessarily saying that that is the best idea, but I have the feeling as if you shouldn't decide to go with one way unless you at least evaluated reclass.
14:34 frankers ntp.ng is configured as a git_remote in /etc/salt/master
14:34 frankers but since there only exists a 'master' branch, no 'dev' branch, there, I guess salt cannot find it and does not care to look in the master branch (ie base)?
14:34 JoeHazzers Deevolution: i can see the appeal, but i'd appreciate a more concise "default" option like from pillar.get, like {{ blah_default(var, default_val) }}
14:34 babilen jxm_: You can definitely get pretty damn far with external pillars, minion naming schemes, environments (for staging!) (nicely reflected as branches in gitfs), nodegroups, custom grains, ....
14:35 JoeHazzers isn't ntpd the "Hello, World!" of configuration management systems?
14:35 jxm_ babilen, actually it makes sense as our puppet uses some postgres tables to do just that, said tables being fed ny our internal information system (customer SLA, quotas, etc.)
14:36 babilen jxm_: The main idea is that you write your states in such a way that they are completely driven by pillar data and that states can be used on every platform (because they come with the necessary data to use, say, the right package and paths and ....) much like formulas in https://github.com/saltstack-formulas
14:36 huddy joined #salt
14:37 jxm_ babilen, well, yes, external pillars look good. I did read about those but forgot they existed and was stuck in a salt-centric loop. Actually generating my own pillar data using whetever ENC make better sense if salt does not support what I want to do out-of-the-box.
14:37 frankers JoeHazzers, it very well may be, but a formula is provided, so I may as well use it ;) Also: If what I want to do does not work with that formula, it will not work with any. But I am looking for experience with managing a salt-master and its states in git
14:37 jxm_ Even just a simple python script that would spit out static pillar sls files would work actually
14:37 JoeHazzers frankers: I assume I could (probably easily) write my own little helper function and bring it into the template's environment, no?
14:38 JoeHazzers oh sorry, wrong question
14:38 JoeHazzers frankers: i've been doing that recently. it's been great fun :)
14:38 jxm_ babilen, but now I am curious re. reclass, never used a dedicated ENC before, just custom code
14:39 jxm_ babilen, do you know if there is good integration with foreman ?
14:39 babilen jxm_: http://docs.saltstack.com/en/latest/ref/pillar/all/index.html
14:39 JoeHazzers frankers: i believe the gitfs documentation has information about setting branch aliases/"redirects", no?
14:39 jxm_ Not sure if I should look on foreman side or on salt side to find it...
14:39 babilen jxm_: https://github.com/theforeman/foreman_salt is available now, but I have no experience with it unfortunately
14:39 jxm_ hahha, cool, both foreman and puppet
14:39 JoeHazzers jxm_: i had to use foreman on a year-ish long internship last year. it was a horrible beast. why, do you use it? 8]
14:40 jxm_ I don't, but it is on my "list of things to try"(tm)
14:40 jxm_ :-)
14:40 babilen jxm_: But you have access to puppet (hiera data in particular and foreman data as external pillars
14:40 babilen (on which you can base your targeting for example)
14:40 jxm_ <nod>
14:40 JoeHazzers jxm_: all i'll say is our use case quickly surpassed the capabilities of foreman such that foreman mostly became a read-only web interface for us to look at our infrastructure with.
14:41 babilen heh
14:41 jxm_ ok, so yeah, of course if I generate the "aliases" externaly and store them in salt in the form of static pillars, then no more problems.
14:41 JoeHazzers frankers: are you talking about mapping a branch other than master as the base environment?
14:41 frankers JoeHazzers, hmm I cannot find anything on redirect right now
14:41 frankers no
14:42 JoeHazzers frankers: oh, i see. so you've configured gitfs to use branches for environments, but then you have different environments in your top.sls?
14:42 jxm_ babilen, thanks for the chat, it unstuck me! Good to play words ping-pong with someone who understand what you say :-)
14:43 babilen jxm_: One thing to keep in mind is that there are a lot of places in which you want to make security relevant decisions based on some data. That data has to come from trusted sources. In particular you shouldn't base your decisions based on grains as those are generated on the minions themselves. External pillars or minion ids are much better ...
14:43 frankers yes
14:43 frankers basically I have the top.sls file in my master branch
14:43 jxm_ JoeHazzers, specific provisionning needs broke it, or was it scale, flexibility or classification?
14:43 JoeHazzers jxm_: just tell your puppet users that they can get mcollective functionality to scale to tens of thousands of machines without it breaking :x
14:43 frankers and it defines a base environment and a 'dev' environmant
14:43 jxm_ babilen, Imy understanding is that everything secure should be in pillars, not on public salt:// fs
14:43 frankers I have one machine in my dev environment and want it to install ntp.ng.
14:44 jxm_ s/secure/confidential
14:44 babilen jxm_: You are most welcome ... You have quite a complicated environment there and I have to say that I don't have the feeling as if I *really* grasped what you are doing, but I thought it might help to point out some of the bits and pieces that you might find useful
14:44 frankers but now salt complains during highstate that ntp.ng cannot be found in the dev environment
14:44 Tyrm joined #salt
14:44 jxm_ babilen, TBH it is not just "one" environment, this is the thing
14:44 frankers probably because the ntp repo only has a master branch
14:44 babilen jxm_: Yes, that understanding is correct. But you also shouldn't make that data availabled based on, say, grains (or anything that is not under the control of the master)
14:45 JoeHazzers jxm_: it was a bit of both. we already had our own network boot system. we already had our own hardwaredb/inventory, and we also had our network managed by another system, so foreman just became a sort of aggregate data source. we quickly abandoned node classes or groups or whatever they were called because of security concerns RE any manifest being able to access data from any other part of puppet in the same environment, so we had to push people to
14:45 JoeHazzers their own enviromnents if they wanted to keep secrets (e.g. database passwords) until we came up with a homegrown solution for secrets
14:45 VSpike http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkgrepo.html says "python-apt" is required for ubuntu/debian. Is that for any pkgrepo stuff, or just PPAs specifically? Does anyone know which systems it's missing on by default?
14:45 JoeHazzers jxm_: the problem was puppet's (lack of) capability, not foreman itself.
14:45 jxm_ babilen, I am providing management and hosting services for a few different businesses, some which are mine, some entirely owned by customers and sme other mine but providing hosted services (VDI, etc.)
14:46 frankers it is kind of weird that salt will not look into the 'base' environment if it cannot find something in my 'dev' environment, no?
14:46 jxm_ babilen, right, a minion can decide to expose any grains it wants
14:46 JoeHazzers frankers: i'm not sure. it seems like edge case / undefined behaviour.
14:46 jxm_ babilen, this is actually a good point, classification based on grains is at the mercy of a compromised minion whose key has already beenaccepted
14:46 babilen jxm_: Same here (at least our virtualisation platform is very homogenous ... sure we might have to account for RS710 vs RS730, but nothing as crazy as what you seem to have running there)
14:47 jxm_ babilen, to that regard, I actually appreciate a lot that the pki depends on the minion id, this way that's a secure point of reference
14:47 babilen jxm_: Don't trust grains. Use them, but don't expose *anything* you don't want to expose. In particular if you have customers on those boxes.
14:48 jxm_ babilen, noted
14:48 babilen jxm_: Yeah, minion id is secure. And if you have an easy way to generate "tags" / "aliases" / "classes" based on them you are golden.
14:48 JoeHazzers ^
14:48 __number5__ VSpike: very old system, any thing older than precise in ubuntu already have python-apt, not sure about debian
14:48 JoeHazzers work out roles and groups etc. on the master *if* they're used to access sensitive data
14:49 frankers JoeHazzers, well it is not really an edge case if you really want to use environments and provided formulas, no? Say I have a testing environment, where I test new formulas that I want to use, ie the ntp formula from saltstack. Now I define that testing branch, add a machine to it and tell it to install ntp. And it starts doing that, but because the formula does not have a testing branch it fails miserably
14:49 ndrei joined #salt
14:49 babilen jxm_: fwiw, we are a shop with a bunch of customers and it paid off to have a git repository for each of their states, pillars and top.sls files along with formulas + "global" states (those that haven't quite reached "formula" maturity or are very specific to us)
14:49 VSpike __number5__: great, thanks. I'm only really interested in 12.04 and 14.04 at the moment so I should be OK then.
14:50 sxar joined #salt
14:50 __number5__ VSpike: yep those are my daily systems too, so 100% sure
14:52 JoeHazzers frankers: ouch
14:52 frankers yup, ouch :)
14:52 magnus-lycka joined #salt
14:53 JoeHazzers frankers: from the documentation (and what i've used GitFS for myself), I can't see any way of doing it. I hate to be "that guy", but you could always write the code yourself...
14:53 JoeHazzers or even better, submit a bug/issue :D
14:53 frankers maybe i misunderstand the workflow here, coming from puppet. But that is how we did it before and it makes sense-
14:53 frankers No, be that guy and I can completely understand it!
14:53 frankers ;)
14:54 frankers will file an issue, but before I do that I wanted to see if it was my fault
14:54 JoeHazzers frankers: i'm not aware of any "fallback" to base, and my assumption about enviromnents is that they're completely isolated from oneanother
14:54 frankers yeah seems to be..
14:55 jxm_ JoeHazzers, interesting
14:55 frankers gotta run, will check in again on monday and see if I cant find someone that also extensively uses gitfs with salt in their work environment
14:55 frankers thanks JoeHazzers for the talk. Nice weekend to ya'll!
14:55 JoeHazzers JoeHazzers: concievably if you add an option to map any enviroment to any branch, you could add the same gitfs remote multiple times, mapping different environments to the same branch
14:55 JoeHazzers crap
14:55 JoeHazzers i have no idea why my IRC client corrected his name to mine after he left :/
14:56 jxm_ babilen, I always keep everything versionned in git anyway. But you mean you have several salt installs for these customers, not specific states for cutomer-related boxes that you manage internally, right?
14:58 jxm_ On an unrelated note, how would you, with salt purely, keep a file containing a list of all minions matching some compound expression on a specific minion?
14:58 babilen jxm_: I also use multiple masters (read up on syndic to learn how I tie those together), but my main point was that I keep each customer's data and states that are specific to them in separate repositories, while trying to use "global / generic" formulas whenever possible.
14:58 Tyrm joined #salt
14:58 jxm_ babilen, got you
14:58 babilen jxm_: I'd generate those from data in the salt mine
14:58 babilen (or salt['test.ping](....) )
14:59 jxm_ Ha, one topic that was next on my reading list
14:59 babilen :D
14:59 jxm_ Hey, yeah, one day only has so many hours ;-)
15:00 babilen You probably have private networks and I found it highly beneficial to have mine aliases for network.ip_addrs with the respective cidr masks of those networks (to make it easy to configure boxes with their "correct" ip and so on
15:00 jxm_ Can the salt mine data be stored privately on the master, aka not on the saltfs ?
15:00 ShadowHntr joined #salt
15:00 babilen I have to go now, it is pub o'clock
15:01 babilen well, training o'clock
15:01 babilen See you guys tomorrow / Monday
15:01 jxm_ Good drinking/training
15:02 JoeHazzers babilen: pfft, every hour is pub o'clock! have fun :)
15:02 jxm_ Stop it guys, you're making me thirsty :-)
15:05 sxar joined #salt
15:06 JoeHazzers speaking of drinks, i was watching one of the conf videos earlier today, and one of the speakers said "we just have to wait for february to roll around before we can get beacons" (or similar) and i spat my drink on my lap laughing
15:06 scbunn joined #salt
15:07 jxm_ :-)
15:10 kunersdorf joined #salt
15:13 iggy the conference was in March, so that was obviously meant to make people spit drinks
15:14 JoeHazzers iggy: yes :3
15:14 JoeHazzers i wonder (with the addition of engines and beacons) how long it'll take for salt to end up competing/integrating with logstash/heka
15:15 iggy the use case I heard mentioned more often was more of a tripwire type setup
15:16 JoeHazzers yeah, i found that to be a useful concept
15:16 scarcry joined #salt
15:16 iggy I'm totally going to do it
15:16 JoeHazzers e.g. watching essential/sensitive system files for changes
15:16 JoeHazzers like being able to detect an /etc/shadow change outside of authorised methods
15:16 iggy user edits file in /etc -> send me notification -> run highstate
15:17 JoeHazzers i was actually looking into systemd's APIs (dbus and other) to see if it would be possible to actively watch systemd services in a useful manner
15:18 JoeHazzers i don't see it taking long before it being *easy* for salt to be a monitoring solution, too.
15:19 iggy except there are already 1000 other options out there
15:20 JoeHazzers iggy: but the advantage of having it with salt is that you would get it mostly "for free"
15:20 JoeHazzers i (personally) quickly gave up on monit, sensu, nagios and the like
15:21 TooLmaN joined #salt
15:22 JoeHazzers i'm not arguing against those solutions so much as that i think because of salt's solid event backbone and the introduction of the reactor, engines, and beacons, monitoring is sort of an emergent capability
15:24 jxm_ JoeHazzers, I just had an idea to experiment over the weekend. Use salt-mine to collect data and export wiki pages - instant overview of the systems from the wiki :-) This stuff is great
15:24 speedlight joined #salt
15:24 speedlight joined #salt
15:25 c10 does anyone have any idea how to save the current timestamp in a jinja variable?
15:25 iggy except salt's main timer runs at 1m intervals... so you'll be hard pressed to get great resolution out of it
15:26 JoeHazzers iggy: can't that be tuned (caveats included)?
15:26 jxm_ iggy, ha, yes, that's and issue. cron-era :-(
15:26 jxm_ But hey, most monitoring systems use typical 5m resolution...
15:27 jxm_ And 1m is enough to generate data usable by graphite
15:27 iggy sure, if you don't mind everything that's tied to that same timer (gitfs updates, etc.) to happen more often
15:27 iggy c10: shouldn't be too hard to write a custom module that spits out datetime
15:28 iggy then {{ salt['mymodule.datetime']() }}
15:28 gladiatr joined #salt
15:28 c10 iggy: i see, ty
15:29 iggy I was looking for something that had it already, but I don't see anything
15:29 JoeHazzers iggy: maybe if we change everyone's main loop timer to ~3s, we can get another github DDoS going?
15:30 jxm_ So reading on sltmine, am I wrong in saying that this thing yells DNS, firewall, monitoring, BGP, IGP and PXE server config automation? I mean is this what it is done for, or are there large caveats for that type of usage (apart from the obvious potential security issues)?
15:30 dayid joined #salt
15:30 jxm_ *saltmine
15:31 SeeDickCode joined #salt
15:31 * jxm_ is excited about saltmine
15:31 iggy I think there are a few less users of salt than people in China, but GH would probably frown upon that nonetheless
15:31 JoeHazzers jxm_: depending on what you're looking for, but i generally found hashicorp's consul to be useful for a few things like that, although i can't comment on practicality at scale.
15:33 notnotpeter joined #salt
15:33 jxm_ JoeHazzers, will look that one up, baby cries, BBL
15:33 magnus-lycka joined #salt
15:35 asido joined #salt
15:37 hasues joined #salt
15:39 adelcast1 left #salt
15:39 sxar joined #salt
15:40 vimmonkey joined #salt
15:41 slav0nic_ joined #salt
15:42 Auroch joined #salt
15:43 stanchan joined #salt
15:44 adelcast joined #salt
15:44 echo joined #salt
15:45 thayne joined #salt
15:46 litwol left #salt
15:47 basepi jxm_: I don't recall. Not even sure if an issue was ever filed. If you're hitting that issue you should file one. =)
15:59 c10 iggy: made it work with the module, thanks :)
16:00 otter768 joined #salt
16:01 iggy feel free to https://github.com/saltstack/salt-contrib
16:02 ntk joined #salt
16:03 ninkotech joined #salt
16:04 ntk It looks like the systemd module only manages services. Does salt know how to mask mounts?
16:04 ntk specifically, I want to a state that masks tmp.mount, e.g. "systemctl mask tmp.mount" if it's not masked.
16:05 ntk or another good way to disable tmp-on-tmpfs in redhat-land.
16:05 jalbretsen joined #salt
16:07 jalbretsen1 joined #salt
16:10 ntk ok, I'm ignorant. all that does is make a symlink, so I can just have an explicit state for a symlink /etc/systemd/system/tmp.mount -> /dev/null
16:13 TheOtherDude joined #salt
16:14 TheOtherDude joined #salt
16:14 magnus-lycka joined #salt
16:15 bluenemo joined #salt
16:16 Guest74914 joined #salt
16:20 overyander joined #salt
16:21 vexati0n Running 2014.7.5 on Ubuntu 14.04.2, I have enabled master_job_cache: mysql in the master cfg file, now the log keeps showing the error "RemoteFuncs object has no attribute 'fire_event'"
16:24 spookah joined #salt
16:25 MatthewsFace joined #salt
16:25 OnTheRock joined #salt
16:27 KyleG joined #salt
16:27 KyleG joined #salt
16:30 iggy vexati0n: you've configured the mysql settings in the master config file?
16:30 vexati0n yes, and it works correctly as far as i can tell. it writes to and reads from the database
16:31 iggy but there's an error in the log...
16:31 vexati0n there are ~108,000 jobs and ~125,000 returns logged
16:31 vexati0n in the db
16:31 vexati0n i'm not sure what the error in the log is actually impacting
16:31 iggy probably open an issue (check for existing ones first)
16:32 iggy sounds like something cosmetic, but still should be fixed
16:32 ghostisic joined #salt
16:42 bhosmer_ joined #salt
16:45 desposo joined #salt
16:47 hemphill joined #salt
16:48 theologian joined #salt
16:48 vimmonkey joined #salt
16:48 jxm_ basepi, it was filled, #18311
16:49 jxm_ (and I added to it already)
16:55 florinandrei joined #salt
16:56 debian112 joined #salt
16:57 Ssquidly joined #salt
16:58 basepi cool
16:59 solidsnack joined #salt
17:01 smcquay joined #salt
17:01 jxm_ basepi, not so cool, it's been 4 months and no progress
17:02 VR-Jack joined #salt
17:02 jxm_ I had some hope re.  commit 61ed4798c42929d24ca643689913e6885ef13677 but it does not fix the problem
17:03 VR-Jack anyone good at jinja know how I might clean this up a bit? http://pastebin.com/pf0tcdmM
17:04 iggy VR-Jack: might throw your pillar in there so we have a better idea what format it's in
17:04 iggy protip: gist.github.com supports multiple files per paste
17:05 iggy (and doesn't have a bunch of ads and jacked up whitespace)
17:05 thayne joined #salt
17:05 hasues left #salt
17:08 magnus-l_ joined #salt
17:08 bhosmer_ joined #salt
17:09 VR-Jack thanks. I like the multi-file.
17:09 VR-Jack https://gist.github.com/anonymous/787cc742d03d6876b570
17:10 VR-Jack initial node pillar is passed via commandline with the hostname. for this example, node: myserver
17:10 hermanbergwerf joined #salt
17:14 robothands joined #salt
17:14 ben_NN joined #salt
17:15 iggy are you really only handling one at a time?
17:15 hermanbergwerf left #salt
17:17 iggy I hate tons of set's when they only get used once
17:17 dalexander joined #salt
17:17 iggy but lines 500 characters long aren't fun either
17:17 VR-Jack To be honest, this is a bootstrap definition
17:18 iggy yeah, I'm starting to see what you're doing with it
17:18 VR-Jack eventually, it will have a list of 200 servers defining roles, host systems, etc. I can bootstrap the bare metal, and when done, it will have all vm's installed
17:18 iggy if you were looping, you could do something like {% for hostname, data in salt['pillar.get']('hosts').iteritems() %}
17:19 VR-Jack I have 1 week experience with salt now. mostly reading. lol
17:19 sevalind joined #salt
17:19 iggy you can try type = node.type, but I don't know
17:19 VR-Jack yeah. the main problem I have is that jinja doesn't seem to do embedded references very well, and referencing a dict in a list doesn't seem to work right
17:20 VR-Jack tried that. :)
17:20 iggy meh... whatever works
17:20 VR-Jack I can pass node as a pillar (as I did) to an sls and that sls can then do salt.pillar.get and reference everything, but not in the main file
17:21 hal58th joined #salt
17:21 hal58th_ joined #salt
17:21 VR-Jack but I dont' know jinja/salt well, so thought I'd see if anyone knew of a method I missed.
17:21 sevalind Hello! Is there any way to use a variable for the current module name/path in .sls files? for example, if I had a module called test, and in test/init.sls I had a state for providing a file for test/files/foo, and then I moved the module to be named test2, I'd have to go in and change the file path to be test2/files/foo
17:22 sevalind What I'd like to do is something like $module/files/foo, or maybe there's a better way I don't know about
17:23 ndrei joined #salt
17:24 VR-Jack probably wrong, so probably ignore me, but I briefly thought I read something about a $self
17:24 magnus-lycka joined #salt
17:25 sevalind VR-Jack: Hrm, I'll take a look at that, thanks!
17:25 toastedpenguin joined #salt
17:26 writtenoff joined #salt
17:27 asido I executed salt state.highstate and the utility returned in a couple secs, while the job was executing for several minutes. how can I see the result output now? /var/log/salt contains just some old error messages
17:27 asido why is it that sometimes the execution blocks until report is printed while other times it quits before printing anything and supresses all the output?
17:27 kunersdorf run salt-call state.highstate on the minion is very verbose
17:28 iggy VR-Jack: keep in mind that grains/pillars/etc are a bit weird in orchestrate jobs as they are running in the master context
17:28 kunersdorf or install halite
17:28 VR-Jack iggy: yeah. I've noticed that
17:28 dave_den joined #salt
17:29 iggy sevalind: {{ source }} is the current file (relative to the base of the cache dir)
17:29 iggy and you can use most string functions to further narrow that down
17:30 c10 i'm getting "State example_com_prod in SLS 'deploy' is not formed as a list, where the deploy SLS looks like this: https://www.dropbox.com/s/5x97ndoh5wj8lk1/Screenshot%202015-04-24%2020.29.22.png?dl=0
17:30 c10 any ideas why?
17:30 VR-Jack iggy: on the other hand, without that context, I couldn't do what I'm doing. I was worried by day 3 when I didn't see a master side context. finally hit the 1 page on orchestrate. lol
17:30 sxar joined #salt
17:30 iggy asido: -t to extend the time the salt command waits salt-run jobs.* to inspect the job cache for stuff that's already happened
17:31 iggy VR-Jack: yeah, just pointing it out... it still confuses me at times...
17:31 asido iggy, thanks
17:32 solidsnack joined #salt
17:32 asido iggy, you sure the command is correct? I get 'Function 'jobs.*' is unavailable'
17:32 iggy c10: {{ site.path }}/production... and down needs to be unindented a block
17:33 sevalind iggy: thanks, I'll check that out as well
17:33 VR-Jack spacing on yaml is killer
17:33 iggy asido: that's shorthand for everything in http://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.jobs.html#module-salt.runners.jobs
17:33 jonatas_oliveira joined #salt
17:33 c10 iggy: you mean the symlink block cannot be indeted?
17:34 iggy c10: no
17:34 VR-Jack the line before that
17:34 iggy the line before that and everything after (so line 10-14) needs to be unindented a block
17:35 VR-Jack c10: your site.path line is at the git.latest indent level. it should be at the base level if I read that right.
17:35 iggy you can't nest stanzas inside other stanzas
17:36 slav0nic joined #salt
17:36 slav0nic joined #salt
17:37 asido iggy, I don't see anything to print history report in jobs.*, except that jobs.list_jobs prints that I had executed state.highstate half an hour ago. is it possible to see how did it ended now?
17:38 racooper jobs.lookup_jid
17:38 c10 iggy, VR-Jack, that worked. Now, why can't the file.symlink state be indented there, while both git.latest and file.managed can?
17:39 racooper or jobs.print_job perhaps
17:40 VR-Jack c10: it was at an indent level that it thought it was part of git.latest
17:40 Tyrm joined #salt
17:40 tedbot joined #salt
17:41 iggy asido: what racooper said
17:41 VR-Jack c10: sorry, it thought it was part of the line 6 stanza. *brain dead here*. By removing indents, you create a new stanza
17:41 iggy c10: it wasn't indented at the same level as the other stuff
17:42 bkleef joined #salt
17:42 asido iggy, racooper: https://gist.github.com/Asido/8dcf68d90af325367508 it doesn't say much
17:42 asido does it mean it is still running?
17:42 asido jobs.active prints nothing
17:43 c10 i'm confused, it was on the same level as "git.latest" (had two spaces before it, the same as git.latest)
17:43 racooper asido,  jobs.lookup_jid 20150424101143099539
17:44 VR-Jack c10: I'm not sure your git.latest is working right either.
17:45 iggy asido: it means it's still running, yes
17:45 asido racooper, ok, I was using the same ID as for print_job and it printed nothing
17:45 asido racooper, iggy: does it mean that master and minion contains different jids?
17:46 iggy asido: I'm not sure... I don't use the job cache much
17:46 iggy c10: it isn't... file.symlink is indented 2 spaces further than git.latest
17:47 asido iggy, do you have any idea why `salt-run jobs.active` doesn't list anything now? It used to list that highstate for several minutes and now I thought it's done, because the output is empty. but according print_job it is still running
17:47 iggy c10: if that isn't the case, then you should try pasting code to gist.github.com instead of taking screenshots
17:48 iggy asido: no clue, sorry... as I said, don't use the job_cache much
17:48 denys joined #salt
17:48 racooper all I know is what's in the docs, I'm afraid.
17:49 asido iggy, racooper: but lookup_jid says it's done: https://gist.github.com/Asido/442563ce86e91ecb477f
17:49 gchao joined #salt
17:50 asido while print_job keeps printing the same output
17:50 toastedpenguin joined #salt
17:50 c10 iggy: i see what you mean. i thought {{ site.path }}/production/revisions/{{ date }} it's what defines the indent for the symlink block. you're saying only the "file.symlink" statement does.
17:51 sevalind Is there a switch statement I can include inside a state file? I could do the same with a bunch of {% if blah %} {% endif %} but they're ugly :P
17:51 iggy c10: "{{ site.path }}/production/revisions/{{ date }}:" is the state_id... it has to be completely unindented... everything else is based off that
17:51 iggy sevalind: sadly, no
17:52 sevalind iggy: darn, all righty :)
17:52 sevalind thanks for the quick answer!
17:52 hemphill Is there a document that talks about running multiple commands from one salt state, be it using modules or some other method? I seem to be banging my head into the wall repeatedly trying to get very simple things to happen.
17:52 iggy sevalind: there are other ways to do similar (dict lookup, etc.)
17:53 iggy sevalind: try googling for "python what to use instead of switch"
17:54 iggy hemphill: just put them in order
17:55 sevalind iggy: It's not so many things that I can't just use a few ifs, was just making sure I wasn't missing out on the easy fix
17:55 c10 iggy: i understand now. i see that usually state ids can be the name attribute value. Is that true for file.symlink as well? can i give it a custom state id, and move "{{ site.path }}/production/revisions/{{ date }}" to the name attribute?
17:55 hemphill I've tried that, running multiple mine.send stanzas blows up
17:56 iggy sevalind: yeah... it goes back to python's (lack of) support for switch statements... so if's or dict lookups/etc.
17:56 sevalind So everything inside {% %} is python? As you may be able to tell, I'm not super fluent with salt
17:56 iggy c10: yes, you can (and probably should... using filenames/etc for state_id tends to lead to name collisions)
17:57 iggy sevalind: sort of...
17:59 scbunn joined #salt
18:00 sevalind Can I do something like this: https://gist.github.com/anonymous/c8ad40c6d0c86538dd87
18:01 otter768 joined #salt
18:01 VR-Jack sevalind: yes, although using pillar might be better in some cases.
18:01 solidsnack joined #salt
18:02 sevalind VR-Jack: I don't really understand pillars or what they're useful for
18:02 iggy you will
18:03 iggy go with whatever works for now and understand that anything you write in your first month or so of using salt is subject to a rewrite ;)
18:04 sevalind True. I've been using salt for ~2 years though. This is the first big cleanup/rewrite that I'm doing. My previous setup has a bunch of modules, but everything inside of init.sls
18:04 OnTheRock joined #salt
18:04 VR-Jack the biggest use is for variable data. you can have a variable be one thing to one server and something else to another server, while keeping the state file the same.
18:04 wendall911 joined #salt
18:04 sevalind so I'm splitting that out now and cleaning a bunch of stuff up
18:05 denys joined #salt
18:06 hermanbergwerf joined #salt
18:06 sevalind Ok, another question of about a billion: Is there any way to do an onlyif to check if a package is installed? I don't mean a package defined by salt
18:07 sevalind So for example, if I wanted to install a vim config file, but wanted to check if the vim package was installed (but vim isn't managed by this salt module, if that makes sense)
18:08 hermanbergwerf left #salt
18:09 hermanbergwerf joined #salt
18:09 sevalind Is it as simple as "onlyif: - pkg: vim"
18:11 XenophonF isn't onlyif a shell command?
18:11 VR-Jack actually, I believe onlyif and unless only do shell commands, so you'd need to write a command to check it and return true/false
18:11 XenophonF what's stopping you from adding a vim pkg.installed state and depending on that?
18:12 wt joined #salt
18:13 hermanbergwerf I'm writing a python script which can create virtual machines (like you can with `salt-cloud` in shell, but with some additional functions) Can I use the functions of `salt-cloud` using pure python libs? (I could not find much documentation but I could use https://github.com/saltstack/salt/blob/develop/salt/cloud/cli.py as an example) Or do you suggest writing a bash script which calls `salt-cloud` and add the functionality in bash?
18:13 baweaver joined #salt
18:15 sevalind XenophonF: I have a pkg.installed state, but it's in a separate submodule, and I'd like to try to not have them depend on each other
18:15 XenophonF gotcha
18:17 kunersdorf any idea why {{ grains['fqdn_ip4'] }} returns [] in state run?
18:18 paolo is there any way to do this obtaining an output? salt minion cmd.run htop
18:18 XenophonF kunersdorf: maybe reverse dns isn't working?
18:19 XenophonF kunersdorf: i'm using the ipv4 grain to get the list of configured ip addresses in my states/templates
18:19 kunersdorf rgr, let me try that
18:19 hemphill joined #salt
18:19 kunersdorf is that the null symbol?
18:19 XenophonF kunersdorf: kind of - empty list
18:20 kunersdorf kk, ty
18:20 XenophonF np
18:21 druonysus joined #salt
18:21 sevalind Ok, so I can probably do onlyif: rpm -q vim
18:21 sevalind (I'm on CentOS)
18:22 XenophonF that should work
18:22 VR-Jack or if you don't care about the package, just check to see if the file is there
18:22 sevalind VR-Jack: I mainly care about the package to make sure the config isn't overwritten later when the package is installed, and to make sure the proper directory structure is in place so I don't have to tell salt how to create it
18:22 hal58th kunersdorf I know why it's not working I think. grains['fqdn_ip4'] is a list, but you are expecting it to be a single value
18:23 kunersdorf their is no dns for my vbox minions, but fqdn_ip4 returns single value on master
18:23 kunersdorf ipv4 returns a list
18:23 babilen |first is your buddy
18:25 babilen fwiw, I would strongly recommend to use network.ip_addrs with a suitable cidr mask, so that you can be sure you get the address from the network you want -- http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#salt.modules.network.ip_addrs
18:25 babilen extra win with the salt mine :)
18:26 yekta joined #salt
18:26 kunersdorf I'm trying to do this without salt mine, but that might be dumb
18:27 yekta Hello, I have changed the hostname of one of my minions and now I can’t provision to it any more, because “The key glob ’new-hostname’ does not match any unaccepted keys.”  What must I do to remedy this?
18:27 sevalind Can init.sls be empty? Or must there be something in there?
18:27 yekta sevalind: it can be empty
18:27 sevalind yekta: neato, thanks :)
18:27 VR-Jack yekta: delete old key, accept new one using salt-key on master.
18:27 rap424 joined #salt
18:28 tmclaugh[work] joined #salt
18:28 VR-Jack presuming you changed the id and not the hostname. just guessing there
18:28 VR-Jack if you only changed, hostname, the id will still be the old one
18:28 hermanbergwerf I figured I should probably use salt.modules.cloud to use `salt-cloud` functions in python :-)
18:29 yekta VR-Jack Which “id” are you referring to?
18:29 hermanbergwerf left #salt
18:29 VR-Jack yekta: salt minion id's are not actually related to the hostname of the server itself. Defaults to hostname, but doesn't have to be
18:30 babilen kunersdorf: You only have to involve the mine if you need information about *other* minions. My main point was to use network.ip_addrs so that you can filter by network (rather than relying on a specific order in the grains)
18:30 wt is anyone else having problems with gitfs or git_pillar on 2014.7.5
18:30 wt ?
18:31 babilen wt: No
18:31 VR-Jack my node id's are hostname-type-priority-company, while the nodename is the hostname of the server. So I can match on grains for hostname, or just match on the minion's id
18:33 eyeoh_ joined #salt
18:33 VR-Jack yekta: unless you are doing a grain matchtype, globs default to nodeid, which won't change unless you change it. Stored in /etc/salt/minion_id on the minion.
18:34 kunersdorf babilen: this failed: {{ salt['network.interface_ip eth0'] }}, do have a snippet that works?
18:34 stoogenmeyer_ joined #salt
18:35 VR-Jack Is there a document where someone aggregated/templated all the terms used for salt? I know documentation can switch between them sometimes, but was curious if there is an official list.
18:36 yekta joined #salt
18:36 yekta VR-Jack: OK, just deleted the key but I’m still getting the same error with “No minions matched the target. No command was sent, no jid was assigned.”  Do I need to do something o the minion?
18:37 sxar joined #salt
18:37 mimiandi joined #salt
18:38 kunersdorf whoops, {{ salt['network.ip_addrs'] }} compiles but returns <function ip_addrs at 0x1b9cb90>
18:38 mimiandi hi
18:38 tomh- joined #salt
18:38 mimiandi any using external_auth with ldap ?
18:39 I3olle joined #salt
18:40 VR-Jack yekta: check the /etc/salt/minion_id file on the minion.
18:41 VR-Jack it's probably the same as the old hostname
18:41 tmclaugh[work] Ryan_Lane: ping?
18:41 Ryan_Lane tmclaugh[work]: sup?
18:41 tmclaugh[work] now that we have > 140 characters
18:41 VR-Jack minion_id doesn't change when you change hostname
18:41 Ryan_Lane :D
18:41 tmclaugh[work] “Remember: conflicting keys will be overwritten in a non-deterministic manner!”
18:42 Ryan_Lane so, the way pillar key conflicts are handled is configurable
18:42 tmclaugh[work] so, it is deterministic?
18:42 Ryan_Lane the default is that conflicting keys overwrite if they aren't dicts
18:42 Ryan_Lane if they are dicts, they recursively merge
18:42 Ryan_Lane the overwrite order is based on the inclusion order
18:42 Ryan_Lane (same with the merge order)
18:43 Ryan_Lane this is a shitty place for this to be documented: http://docs.saltstack.com/en/latest/ref/configuration/master.html#pillar-source-merging-strategy
18:43 Ryan_Lane it's the only place it's documented, too
18:44 tmclaugh[work] So the doc i read is incorrect or misleading right?
18:44 Ryan_Lane which doc did you read?
18:44 tmclaugh[work] http://docs.saltstack.com/en/latest/topics/pillar/#pillar-namespace-merges
18:45 Ryan_Lane that's a recursive merge
18:45 Ryan_Lane note that there's no conflicting keys in that dict
18:45 VR-Jack it has warnings, and above it mentions issues concerning non-deterministic overwrites on conflicts
18:46 Ryan_Lane https://github.com/saltstack/salt/issues/23044 :)
18:47 Ryan_Lane tmclaugh[work]: what you read is accurate, but it's not a really good doc.
18:47 yekta joined #salt
18:47 Ryan_Lane it's saying that if you have a key with a conflict and it's a dict, it'll recursively merge that dict by default
18:48 Ryan_Lane pillar_source_merging_strategy lets you change that behavior
18:49 Ryan_Lane using #!yamlex in your pillar file gives you the most flexibility
18:49 iggy kunersdorf: {{ salt['network.ip_addrs']() }}
18:51 kunersdorf thank you iggy, I thought it was a reference, just didn't how to de-reference
18:52 jonlangemak joined #salt
18:52 babilen kunersdorf: You shouldn't care about interfaces, but networks. Interfaces may change. Don't hardcode that. salt['network.ip_addrs'](....) (it's a function, you have to call it)
18:53 kunersdorf do you know how to remove the brackets and ticks from the result?
18:54 babilen I've seen various customers getting into problem because "Oh, no. The internal IP *has* to be on the eth0 and the public on eth1. Yes, even if there is no internal, we still have to ensure that .... Don't hardcode interfaces. Reference networks by cidr (i.e. their definition).
18:54 babilen kunersdorf: |first to get the first element in a list (as mentioned earlier)
18:54 babilen Or [k] for the k-th
18:56 kunersdorf ok, didn't understand what you meant
18:56 Vynce joined #salt
18:56 babilen http://jinja.pocoo.org/docs/dev/templates/#first
18:59 vexati0n GAH. ok this is non-bueno. trying to run a large routine with --batch, but salt keeps blowing up with "unhashable type: 'dict'"
19:00 SheetiS joined #salt
19:00 babilen vexati0n: Do you, by chance, have more details?
19:01 sxar joined #salt
19:01 iggy I've seen that too
19:02 vexati0n unfortunately no. It's just a cp.get_file against all minions, using --batch 50, and after the 2nd or 3rd iteration it crashes with that error.
19:03 iggy I've seen it with -b 1
19:03 vexati0n it would be just a minor annoyance but the way our system is architected i need -b to work.
19:05 17SACE0H5 joined #salt
19:05 iggy it's not unreasonable to expect advertised functionality to work
19:06 iggy open an issue, let us know what # (after you search for an existing one of course)
19:07 SheetiS joined #salt
19:08 Guest70 joined #salt
19:09 nafg joined #salt
19:13 vexati0n #23047
19:13 vexati0n I looked for the issue but couldn't find a match.
19:14 hybridpollo joined #salt
19:21 baweaver joined #salt
19:30 Tyrm joined #salt
19:33 viq joined #salt
19:33 viq joined #salt
19:35 badon_ joined #salt
19:40 Zachary_DuBois joined #salt
19:41 hybridpollo joined #salt
19:43 hybridpollo joined #salt
19:44 Zachary_DuBois joined #salt
19:45 hybridpollo joined #salt
19:46 ajw0100 joined #salt
19:50 nafg joined #salt
19:53 Tyrm_ joined #salt
19:57 hasues joined #salt
19:58 hasues left #salt
20:02 otter768 joined #salt
20:06 Guest70 joined #salt
20:08 bhosmer__ joined #salt
20:12 JayFK joined #salt
20:12 nesv joined #salt
20:13 XenophonF on windows, how would i go about installing pip, boto, etc. such that the salt-minion could use them?
20:13 wt Is anyone else using salt 2014.7.5 on Amazon Linux?
20:14 iggy XenophonF: make sure you are using the newer windows installers and you should just have pip (afaik)
20:14 XenophonF by newer do you mean 2014.7.2?
20:14 iggy newer!
20:14 XenophonF something's wrong with the windows version of 2014.7.4
20:14 iggy not really sure
20:15 XenophonF and i don't know of 2014.7.5 has been released for windows yet
20:15 iggy I know they changed the way the installer works a month or so ago
20:15 iggy I doubt 2014.7.2 would work (unless they respun the old code with the new installer)
20:18 nesv Is it possible to call wheel modules from the reactor system?
20:19 bhosmer joined #salt
20:19 aquassaut joined #salt
20:19 dave_den joined #salt
20:20 babilen wt: I would be surprised if not
20:21 iggy nesv: the reactor docs have an example (using wheel.key.delete)
20:21 iggy http://docs.saltstack.com/en/latest/topics/reactor/
20:21 wt babilen, then I would be surprised is no one was having a similar issue as I am having with the gitfs/git_pillar
20:22 iggy unless your problem is just local to your config for some reason
20:22 wt unless no one is using that config
20:22 nesv iggy: Thanks, chief!
20:23 wt It was working with 2014.7.1.
20:23 babilen it ?
20:23 wt My config.
20:23 babilen What *is* the problem? What have you tried to solve/debug the issue ?
20:23 wt babilen, I have and I have filed bugs
20:24 XenophonF i kind of wish the salt-minion install on windows integrated better with python and windows
20:24 iggy XenophonF: that's what the newer installer does
20:24 babilen Good, how can we help or are you simply looking for someone who can reproduce your issue, wt ?
20:24 wt babilen, I am trying to find someone running this config that is either work or having the same problem
20:25 wt s/work/working/
20:25 babilen Okay, I can't help you with that
20:26 XenophonF iggy: so if i have a python runtime already installed, salt-minion will know about it?
20:26 XenophonF because that would be really nice
20:26 Norbell_ joined #salt
20:26 wt babilen, I assume that means that you have a working setup on Amazon Linux with salt 2014.7.5 using gitfs?
20:27 wt oh, can't :)
20:27 babilen No, I am not working with Amazon Linux
20:27 wt sorry
20:27 wt I thought I saw "can"...sorry
20:27 babilen I would have been willing to at least take a look at your issue, but if all you want is to find someone to reproduce your issue then I can't help you with that.
20:27 XenophonF wt: what problem are you having?
20:27 babilen wt won't tell us
20:28 XenophonF i'm running 2014.7.5 in ec2 using centos 7
20:28 wt XenophonF, I am trying to boil down my master config so that I can share it.
20:28 VR-Jack so the output for running my orchestator is blocked until completion; with only info logs displaying during the processing. Is there a middle ground? I'd like an easy indicator that a specific part of the process has finished.
20:28 iggy link the issue at least
20:29 iggy I'm the only one silly enough to follow random issues that have nothing to do with me
20:29 babilen btw, do we finally have a way to get a nice summary of a highstate run on the command line? (something that makes it easy to see how hundreds of minions behaved and, in particular, spot those that had issues/inconsistencies)
20:30 babilen wt: Seriously, there are *many* people in here that are quite familiar with salt and willing to read code and whatnot ... but there is literally nothing we can do if you don't at least tell us what the problem is
20:32 StDiluted joined #salt
20:33 Tyrm joined #salt
20:33 VR-Jack actually, INFO isn't too bad. the only annoying entry was the return information from doing file changes.
20:34 iggy VR-Jack: sadly, that's not the way salt works for the most part... it takes some getting used to, but you learn to live with it
20:35 wt The problem is the grains in salt://_grains are not being handed to my minions when I have either gitfs or git_pillar enabled.
20:35 VR-Jack iggy: yeah. orchestration isn't the key point of it. guess I can wrap it in a shell script, use INFO and strip out the 'ret' value.
20:35 nesv iggy: I followed that example in the reactor docs, but I'm left with this error, and I have no idea what it's referring to: https://gist.github.com/nesv/9fb11cf6ab1510f13119
20:35 wt Here is a config that doesn't work with 2014.7.5, but did with 2014.7.1: https://gist.github.com/wt/8cbf4787e76318afa3c4
20:36 wt Here's what I had to do to that config to work around the issue:
20:36 wt https://gist.github.com/wt/bedee85c60e7d8ba7b0a
20:36 iggy nesv: what does your reactor actually look like?
20:38 nesv iggy: I just added another file to the gist
20:38 wt With the bad config, doing "salt-call saltutil.sync_grains" from a minion results in no custom grains module being run when I do "salt-call grains.items".
20:38 wt With the good config, I get the grain module and it works.
20:38 bhosmer joined #salt
20:39 babilen heh, just commented on that bug :)
20:39 wt To create the directories mentioned in the good config file. I exported the files from a git clone of the repo referenced in the back config
20:39 * babilen would be interested in more info on "I am having a similar problem with the git pillar."
20:40 wt If I enable either the git pillar config or the gitfs config, the sync_grains stops working.
20:41 babilen https://github.com/saltstack/salt/issues/22987 is the issue btw
20:41 wt Only disabling both makes it work.
20:41 babilen (not sure why the secrecy)
20:41 solidsnack joined #salt
20:41 babilen Is this only with new custom grains, or did custom grains stop working completely?
20:41 wt What secrecy?
20:41 iggy nesv: looks okay
20:41 babilen Are they simply not synced?
20:41 wt the custom grains were working with 2014.7.1
20:42 wt They are only working with 2014.7.5 if gitfs and git_pillar are turned off in my config.
20:42 babilen wt: You could have simply asked: "I am having a problem with custom grains since I upgraded to $VERSION. For example the $LINK_TO_PASTE_OF_GRAIN is not syncing as you can see in $LINK_TO_PASTE_OF_COMMANDS. Relevant issues I reported are #12345 and #23432. Do you have any ideas?
20:43 babilen wt: And you are only calling those locally on the minions themselves?
20:43 moos3 joined #salt
20:43 wt calling, as in the salt-call commands?
20:43 babilen Custom grains are definitely working for us on .5
20:43 babilen yeah
20:44 wt yes, that is only happening on a minion
20:44 babilen So it works if you use salt on the master?
20:44 wt if I change the config to the working config (no git enabled), the custom grains work.
20:44 wt babilen, as in using salt to sync the grains?
20:44 babilen sure
20:45 babilen "salt 'some_minion' saltutil.sync_grains"
20:45 wt like "salt '<host>' saltutil.sync_grains"
20:45 wt you clearly type faster. :)
20:45 babilen I have power of gtypist
20:45 nesv iggy: Do you have any idea what that error code means?
20:45 wt yes, fails similarly
20:45 wt What it does is just not get any custom grains.
20:46 babilen wt: Are grains no longer synced or did they stop delivering data?
20:46 wt the grains still appear to be cached in the minions /var/cache/minion/<wherever> dir
20:46 wt What do you mean did they stop delivering data?
20:47 wt I have the custom grains working when they are sourced from the filesystem instead of the gitfs backend.
20:47 babilen I am referring to the case in which grains are synced successfully, but "grains.item FOO" does not return anything
20:48 VR-Jack nesv: are you sure you're passing the right value to match: ?
20:48 iggy nesv: no, but you should open an issue... we want to rid the world of tracebacks
20:48 nesv iggy: Will do!
20:49 iggy VR-Jack: it should be... it's technically a glob match, but a full minion_id should work there too
20:51 iggy reactors are notoriously hard to debug, crank the master log level up to debug and see if you see the rendered reactor file
20:51 wt babilen, I am going to try to get that actual output from the salt-call commands
20:51 wt give me a moment
20:55 VR-Jack Was just curious where it came up with the names in  "SaltInvocationError: '__id__', 'state', 'order', 'name' and 'user' are invalid keyword arguments for salt.loaded.int.wheel.key.accept."
20:55 baweaver joined #salt
20:56 solidsnack joined #salt
20:56 SheetiS joined #salt
20:59 nesv iggy: Issue opened: https://github.com/saltstack/salt/issues/23054
20:59 nesv Please let me know if I need to change/clarify anything.
21:00 iggy does the key actually get accepted?
21:00 solidsnack joined #salt
21:00 nesv iggy: Nope
21:00 nesv I'll add that in
21:00 iggy yeah, it kind of sounds like it might from what's there
21:01 * nesv nods
21:01 nesv iggy: I've edited it.
21:01 wplatnick joined #salt
21:02 iggy okay, I'm following it now, so if anything changes I'll see
21:02 nesv iggy: Sweetness. Thank you very much, again. :)
21:03 tempspace Is there a way to do a try/except in jinja somehow? I want to try to iterate through a pillar that I don't know if it will be there or not. Currently I do this by doing 2 for iterartions, but it's kind of ugly
21:04 iggy tempspace: {% for k,v in salt['pillar.get']('foo:bar', {}).iteritems() %}
21:04 iggy if the pillar doesn't exist, it returns an empty dict to iterate over
21:04 smcquay_ joined #salt
21:05 Norbell_ joined #salt
21:05 iggy i.e. no loops
21:05 tempspace iggy: fantastic, I don't know why I didn't think of returning the empty dict
21:05 tempspace iggy++
21:06 smcquay joined #salt
21:07 tempspace iggy: now, is there a way to use the value of a grain in the pillar key I'm iterating? For instance, I'm looking to iterate over a pillar item1:item2:server's fqdn:item4
21:07 KyleG joined #salt
21:07 KyleG joined #salt
21:07 dalexander joined #salt
21:08 pdx6 joined #salt
21:08 iggy salt['pillar.get']('foo:bar:' ~ grains['nodename'] ~ ':baz')
21:09 tempspace I am unfamiliar with the ~ syntax
21:09 iggy concatenate
21:09 iggy but it casts everything to strings first
21:09 iggy it's just a habit I'm in
21:09 iggy you could use + as well
21:10 tempspace hmm, I tried that before and it didn't work
21:10 tempspace I'll assume I must have done something wrong
21:10 iggy so if you were trying to do 'asfj' + grains['somegrainthatsanint'] + 'string'... you'd get an error about the grain being an int not a str
21:11 VR-Jack iggy: thanks. ~ my new favorite friend.
21:12 iggy you see it less with grains and more with fetched pillar values because the yaml parser will make everything that's numbers into int/float/etc
21:13 VR-Jack yeah. with variable data, you never know for sure. I just presumed + would typecast. didn't know about ~
21:14 tempspace that is probably what happened to me
21:14 iggy + in jinja acts just like + in python
21:14 tempspace I'm teaching some salt to co-workers soon and I want to unlearn my bad habits
21:15 iggy TypeError: cannot concatenate 'str' and 'int' objects
21:15 VR-Jack doesn't help that I come from perl for interpreted. :)
21:15 iggy you get something like that (but jinja specific iirc)
21:15 Brew joined #salt
21:18 ajmath joined #salt
21:24 [7hunderbird] joined #salt
21:29 JayFK joined #salt
21:33 jrluis joined #salt
21:34 baweaver joined #salt
21:35 mpanetta joined #salt
21:35 Hell_Fire joined #salt
21:38 baweaver joined #salt
21:45 codehotter I want to ensure sshd is running on port 222 - what's the best way to accomplish this?
21:45 spookah joined #salt
21:46 codehotter I used file.replace to replace the Port 22 option in /etc/ssh/sshd_config, then I used a service.running with listen on /etc/ssh/sshd_config, but the service fails to restart (gives 'out of memory' error)
21:46 nesv codehotter: Set up a state to put a templated sshd_config in place, have the ssh service watch that config (so it restarts when it is changed), and set the sshd port in a pillar.
21:47 codehotter nesv: I used listen instead of watch, but that's pretty much what I did, right? The file was edited, but the service was not restarted. It gives an out of memory error
21:47 codehotter how do *check* what port ssh is running on?
21:47 toastedpenguin joined #salt
21:47 nesv :[
21:48 nesv codehotter: I think the approach here, is to be declarative about which port sshd is listening on. If you want to inspect the current system, you should be able to list the contents of sshd_config, and `netstat -tpln` to see what port sshd should be listening on, and if sshd is running
21:49 nesv ...should be able to with salt commands.
21:49 baweaver joined #salt
21:49 seev add more memory
21:49 codehotter seev: it has 1gb of memory, with nothing runnning except salt-minion
21:50 codehotter nesv: how do I be declaritve about what port sshd is listening on? I was declarative about changing the config file, and that worked, the config file is changed, but sshd is still listening on port 22.
21:50 LtLefse well, *are* you out of memory? what does free -m say?
21:51 nesv codehotter: Set the port in a pillar; something like `sshd.port`
21:51 nesv ...or just hard-code Port 222 into your sshd_config template
21:52 codehotter LtLefse: free -m shows Mem:            992         125         551           6         316         714
21:53 codehotter nesv: I don't understand what you're asking me to do. The sshd_config file has been changed, it now says Port 222.
21:53 LtLefse codehotter: should be fine, can you restart sshd outside of salt?
21:53 [7hunderbird] joined #salt
21:54 nesv codehotter: To get sshd to restart whenever the sshd_config changes, add a stanza like this to your SLS file: https://gist.github.com/nesv/253e3e826dc9b9a27f1b
21:55 codehotter LtLefse: yes, I can. Now it's running on 222. However, if I destroy the vm, redeploy with salt-cloud, and run salt.highstate, I can reach the exact same nonworking state
21:57 mohae joined #salt
21:57 LtLefse can you post your code?
21:57 LtLefse (to gist.github.com)
21:58 bemehow joined #salt
21:58 mohae joined #salt
21:58 codehotter https://gist.github.com/codehotter/43fcd370c2bf8c48a378
22:02 radd joined #salt
22:03 otter768 joined #salt
22:03 tkelley joined #salt
22:03 LtLefse hrm. looks okay to me
22:04 blacked joined #salt
22:04 Vynce joined #salt
22:05 Vynce1 joined #salt
22:06 LtLefse does "salt-call service.restart sshd" work?
22:08 LtLefse gotta go. another idea is try "salt-call -l debug state.highstate" and see if that gives you any clues
22:10 kuromagi joined #salt
22:11 troyready joined #salt
22:16 pdx6 joined #salt
22:17 nesv iggy: Looks like that traceback issue with wheel.key.accept was totally fixed in 2015.2.0rc2
22:19 stanchan joined #salt
22:19 bhosmer joined #salt
22:21 Plastefuchs joined #salt
22:23 blacked joined #salt
22:24 smcquay joined #salt
22:24 bfoxwell joined #salt
22:35 codehotter The semanage.port module I made myself
22:35 codehotter maybe it's using too much memory (?)
22:38 Twiglet joined #salt
22:40 codehotter can someone be so kind as to sanity check this module? When I use it, I get out of memory error. https://gist.github.com/codehotter/72e5c5b1e6083dddf039
22:40 codehotter I just got started with salt and I don't know very much python either
22:40 codehotter Here's the sls that gives out of memory on restarting the sshd service: https://gist.github.com/codehotter/43fcd370c2bf8c48a378
22:41 blacked joined #salt
22:42 Hell_Fire joined #salt
22:42 nesv codehotter: Fun tip with Python, where you have things like `if something != 'foo' and something != 'bar'`, a "Pythonic" way to do that would be `if something not in ['foo', 'bar']`
22:42 kaiyou joined #salt
22:43 mfournier joined #salt
22:43 jcockhren codehotter: remove the ": []" on line 2
22:44 c10 joined #salt
22:45 nesv codehotter: Also, be wary of the use of `type` as a variable name, as it's a built-in function.
22:46 nesv For example, `type(4) => <type 'int'>`
22:46 wt added a comment showing the custom grain not execing -> https://gist.github.com/wt/8cbf4787e76318afa3c4
22:47 Not_ joined #salt
22:49 nesv codehotter: Also, you seem to be completely ignoring the values you're returning from your instance methods; in general, regardless of programing language, not the greatest thing to do.
22:50 c10 joined #salt
22:50 nesv codehotter: Wait, nevermind, I take that back...
22:50 nesv My sentiment still stands, but I just realized your code is never calling SemanagePort.for_real().
22:51 nesv Oh FFS...what is wrong with me today
22:51 nesv Please disregard everything I've said.
22:51 codehotter Here's the debug output https://gist.github.com/codehotter/0bcefeb502675351d36f
22:51 nesv http://imgur.com/u70jp
22:51 * nzero blocks nesv
22:52 theo joined #salt
22:52 wt babilen, I added the info to the gists and I added linkes to the gists on that issue.
22:56 theo__ joined #salt
23:00 badon joined #salt
23:00 blacked joined #salt
23:00 codehotter Any idea on the out of memory errors? Could they be caused by my module?
23:03 codehotter Is there a systematic way I can debug this? Like measure memory usage somewhere? Or figure out of memory is even the real problem?
23:03 codehotter can I insert a print or sleep command in some key place?
23:03 bhosmer_ joined #salt
23:05 hellome joined #salt
23:10 JoeJulian I notice a lot of states have different names from their module counterparts. Is there a design reason for that, or just legacy?
23:11 baweaver joined #salt
23:11 mfournier joined #salt
23:12 theologian joined #salt
23:13 baweaver joined #salt
23:13 VR-Jack codehotter: did you try running systemctl --all --full --no-legend --no-pager list-units | col -b
23:14 VR-Jack perhaps without the col -b. not sure if that was internal or shell pipe there
23:16 Plastefuchs joined #salt
23:19 mwpher joined #salt
23:19 Schmidt joined #salt
23:20 VR-Jack looks like the service mod is inefficient; at least with systemctl
23:29 solidsnack joined #salt
23:32 bemehow_ joined #salt
23:36 subsignal joined #salt
23:40 lictor36 joined #salt
23:43 Vynce1 left #salt
23:49 mwpher joined #salt
23:49 bluenemo_ joined #salt
23:49 JDiPierro joined #salt
23:55 TheOtherDude joined #salt
23:56 richardc joined #salt
23:59 SeeDickCode joined #salt

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