Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-04-22

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

All times shown according to UTC.

Time Nick Message
00:14 JDiPierro joined #salt
00:16 blacked joined #salt
00:16 rhodgin joined #salt
00:18 blacked1 joined #salt
00:19 badon joined #salt
00:23 JDiPierro joined #salt
00:28 cberndt joined #salt
00:29 evidence so added some extra debugging just before the _read_conf_file return.. it's parsing my config file and properly returning a dict
00:29 evidence so it must either not be going into config, or the merging is broken somewhere
00:32 yomilk joined #salt
00:39 hasues joined #salt
00:40 hasues left #salt
00:42 dendazen joined #salt
00:44 eyeoh_ joined #salt
00:46 florinandrei joined #salt
00:51 solidsnack joined #salt
00:51 solidsnack I'm not sure what is meant by `local.state.highstate` in the Reactor configuration example -- why is it not just `state.highstate`?
00:51 markm_ joined #salt
00:52 iggy because it's running on a minion (locally)
00:53 solidsnack I see.
00:53 Furao joined #salt
00:54 solidsnack So to run instantiate a `boto_route53.present` state on the master (in the master's minion), do I need `local.boto_route53.present`?
00:54 solidsnack Or is that different?
00:55 iggy looks right (with tgt: <master> )
00:55 cberndt joined #salt
00:56 solidsnack Because `boto_route53` and `state` are both modules?
00:56 iggy correct
00:57 iggy oh wait, boto_route53.present is a state function
00:57 solidsnack Oh.
00:57 solidsnack So what are the implications of that?
00:57 iggy so you'd want boto_route53.add_record
00:57 solidsnack Oh.
00:58 iggy http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.boto_route53.html#module-salt.modules.boto_route53
00:58 iggy not http://docs.saltstack.com/en/latest/ref/states/all/salt.states.boto_route53.html#module-salt.states.boto_route53
00:58 solidsnack Oh, wow.
00:58 solidsnack Okay, thanks.
01:00 ITChap joined #salt
01:03 druonysus joined #salt
01:03 druonysus joined #salt
01:08 Diaoul joined #salt
01:11 eyeoh_ i need to setup a salt-master to manager minions on small raspberry systems. these will be updated like a firmware update, full /dev/sda wipes and reloads from a preset image. is there a way to pre-generate a salt-key I can add to the firmware image and auto accept at the master level?
01:12 eyeoh_ or set it up so in the case of the master having a key for the minion ID but the minion has lost the private/pub keypair can it just regenerate and reassign a new keypair automatically?
01:16 iggy you can pre-gen keys, yes (salt-cloud does it, there's a wheel module to do it, etc.)
01:16 iggy the keys and minion_id's need to all be unique
01:16 eyeoh_ would this be a good place to start: http://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html ?
01:16 murrdoc yeah
01:17 murrdoc your other option is using reactors
01:17 murrdoc and so on
01:17 murrdoc http://docs.saltstack.com/en/latest/topics/reactor/#a-complete-example
01:17 iggy or depending on the circumstances autosign.conf, etc.
01:17 murrdoc you can improve that example by adding more testing, like having a list of expected attributes
01:18 rhodgin joined #salt
01:18 murrdoc there is also http://docs.saltstack.com/en/latest/topics/cloud/config.html#saltify
01:19 eyeoh_ awesome thanks I will start reading now
01:20 overyander does each file root require a top.sls file?
01:20 murrdoc nope
01:20 iggy no
01:20 iggy in fact, it's probably a terrible idea to have that
01:21 murrdoc i wish salt doc'ed more shit
01:21 murrdoc this saltify could be awesome
01:22 subsignal joined #salt
01:22 solidsnack In order to run boto_route53.add_record in the Reactor on the master but using the IP of the new minion, it seems like one needs a grain. But how does one get a grain from the new server with `tgt: <master>`?
01:23 solidsnack s/with/when/
01:23 jerematic joined #salt
01:23 murrdoc like i have all these bare metal machines sitting around and i am having to use stupid fabric to install salt
01:24 iggy solidsnack: you can't really do grains in reactors (master context), as you get the grains of the master
01:24 Furao joined #salt
01:24 solidsnack Is there a way to get the IP of the new minion?
01:24 solidsnack Like from data?
01:25 iggy data will probably have the minion_id... you'd need some other way to tie that to an IP
01:25 iggy not really sure how to do that in aws
01:26 solidsnack Well, this is rough. It basically forces me to give minions a profile that lets them write into Route53.
01:26 mosen joined #salt
01:27 ITChap joined #salt
01:27 iggy I believe that's how others do it (considering the only other person I know off the top of my head that does such things uses masterless...)
01:31 solidsnack Well...there are more evil options.
01:31 mosen joined #salt
01:32 murrdoc Ryan_Lane:  u around
01:32 mosen hiya murrdoc
01:34 yomilk joined #salt
01:34 murrdoc mosen:  :)
01:34 Ryan_Lane murrdoc: ?
01:34 murrdoc hey, you got time to answer a question i have about listen_in and using clean:True with directories ?
01:35 murrdoc if not i can ask again later
01:35 jonlangemak joined #salt
01:35 murrdoc ryan ?
01:36 Ryan_Lane hm. I'm actually about to leave for a meetup
01:36 jonlangemak Is there a good way to refresh a minions grain info in a state?  I know I can do a refresh_modules from the master.  Is there a better way to do it as part of the actual state executed against the minions?
01:36 murrdoc kk, later it is, i cant seem to use clean:True on a file.directory along with listen_in, but it works with require
01:36 murrdoc which sucks
01:38 manfred jonlangemak: that is what reload_modules is meant for.
01:39 jonlangemak manfred: But that’s something I can call from the salt master right?
01:39 jonlangemak Is there a way to execute that as part of the state?
01:39 jonlangemak Sorry if that’s an obvious question - Im still learning salt :)
01:39 murrdoc iggy:  u do any file.directory states with a clean:True in them ?
01:40 manfred you could just throw in a modul.run: name: saltutil.refresh_grains
01:40 manfred or whatever that module is
01:40 jonlangemak ah ok, cool.  I’ll try that
01:40 llua how do people normally handle salt minion package updates? i ask because the opensuse packages seems to restart the minion process, which cause the minion to not report back.
01:41 manfred jonlangemak: actually, there is a new reload_grains for states as well
01:41 zwi joined #salt
01:41 manfred but that is the point of it... if you like install something and a grain or module is going to change
01:41 eyeoh_ i'm moving to salt from a puppet enterprise world. would it be right to think of pillars as puppet hiera and states as puppet classes?
01:41 murrdoc yes it would
01:41 manfred like installing redis, and then the redis modules would work...
01:41 desposo joined #salt
01:43 murrdoc what u mean manfred
01:46 mosen eyeoh_: yep, but im not sure about the rules regarding pillar and inheritance.. it used to be that pillars never ever got merged?
01:46 murrdoc eyeoh_:  u can also continue to use hiera and facter as pillars in salt
01:46 manfred mosen: i believe they still just override each other
01:46 eyeoh_ oh cool
01:46 manfred or don't if it already exist... i don't remember
01:46 manfred I know that now the order matters, and pillars are an ordered dictionary... that used to not be the case
01:47 manfred jonlangemak: actually, it looks like saltutil.sync_grains is the thing, and that just syncs /srv/_grains, you actually do have to use the reload_grains: thing on a state to have it run all the salt/grains/*.py stuff again to set up the __grains__ dictionary
01:48 mosen manfred: yeah i think so, im still on 2014.7
01:49 manfred llua: i deploy from git and tags and don't use the packages, because you get those weird behaviors
01:51 manfred jonlangemak: saltutil.sync_grains refresh=True might work, but from a quick look over the code, it looks like it just refreshes them in the minion, and not in that running process, so it won't affect anything until you run the last state.
01:51 jonlangemak manfred: thanks!  I’ll run with this
01:52 manfred aight, i am going to play dnd ... on Twitch! o/ peace
01:52 eyeoh_ is there a central salt state file repo like puppet forge for puppet modules?
01:55 mosen eyeoh_: kinda, theres saltstack/salt-formulas repo
01:56 mosen eyeoh_: you can clone those git repos to get started. You might find that the formulas are more rudimentary than puppet modules
01:56 otter768 joined #salt
01:56 mosen eyeoh_: In my experience, i test out the formula.. if it doesnt do enough or doesnt do what i want, ill make my own local branch and add to it
01:57 dalexander joined #salt
02:02 blacked joined #salt
02:06 subsignal joined #salt
02:08 eyeoh_ maybe i'm reading this wrong but is the salt-minion agent really using this much ram? i expected it to be less than the puppet agent. this can't be right. ps aux shows minion agent at 647664
02:09 pass_by_value joined #salt
02:12 eyeoh_ ok ya, i should be looking at RSS
02:13 eyeoh_ puppet eats about 100megs and SMin is eating like 40
02:13 eyeoh_ salt master is blank though
02:14 murrdoc :)
02:15 eyeoh_ god things like ping are so much faster than puppet mcollective
02:18 Guest70 joined #salt
02:18 druonysuse joined #salt
02:18 druonysuse joined #salt
02:18 rhodgin joined #salt
02:21 thayne joined #salt
02:22 fxhp joined #salt
02:24 malinoff joined #salt
02:26 iromli joined #salt
02:31 jalaziz joined #salt
02:31 murrdoc joined #salt
02:32 __number5__ Is that the salt-bootstrap script not install salt-master upstart script on ubuntu any more?
02:32 fxhp joined #salt
02:32 __number5__ using `bootstrap-salt.s$
02:32 __number5__ -n -M -N git v2014.7.4`
02:34 echo joined #salt
02:40 evle joined #salt
02:43 jeddi joined #salt
02:43 donmichelangelo joined #salt
02:44 solidsnack joined #salt
02:47 zwi joined #salt
02:48 SeeDickCode joined #salt
02:51 solidsnack Where does `_get_conn` come from in modules like this? https://github.com/saltstack/salt/blob/0408bfef9b40cf2ad1ca667d995304ccde880465/salt/modules/boto_elasticache.py
03:03 clintberry joined #salt
03:07 __number5__ solidsnack: some monkey-patching magic here https://github.com/saltstack/salt/blob/develop/salt/utils/boto.py#L229
03:08 solidsnack Interesting.
03:11 favadi joined #salt
03:12 vimmonkey joined #salt
03:12 itru joined #salt
03:13 vimmonkey Hey there, anyone use salt with with windows? ansible is pretty weak w/ support in that area…
03:14 itru after bootstraping saltstack minion at CenOS 7.1, something creates /etc/salt/minion_id on every OS start… can’t find anything in services… how can I disable creation of this /etc/salt/minion_id??????
03:14 vimmonkey i have maybe 3 or so servers i have to deploy code to and configure a few services, just curious if people run into issues w/ window minions
03:17 druonysuse joined #salt
03:18 utahcon joined #salt
03:18 crd joined #salt
03:18 rome_390 joined #salt
03:19 rhodgin joined #salt
03:22 malinoff vimmonkey, from my experience, trying to automate windows with a tool from linux/unix world won't be easy. I've tried to write a couple windows deployments but hardly failed
03:22 malinoff vimmonkey, if you have 3 windows servers, it's better, imo, to simply manage them manually than fighting the broken infrastructure
03:23 malinoff vimmonkey, if you have dozens of windows servers, you'll probably need a correct AD policies
03:26 und1sk0 & learn powershell ;)
03:27 vimmonkey malinoff: hm, thanks. i'm thinking about re-working the servers and just host a few micro services for the stuff that really needs to run on windows. i still have to install a bit of custom software, and we will need to spin up additional instances in the future…so it is something i wish to automate. do you know if most of the ansible python modules will work on windows? i couldn't find a conclusive list of saying what does or dose
03:28 malinoff vimmonkey, what kind of software? self-written? placed in a public domain?
03:28 vimmonkey und1sk0: hm, yeah i've been fighting to avoid learning powershell, it might be worth just "giving in". i didn't want to have two separate languages for managing deployments. using python in both environments will be nice.
03:28 malinoff vimmonkey, it would be much easier to simply use something like chocolatey or nuget/oneget
03:29 malinoff vimmonkey, the problem is that linux and windows are too different from managing perspective, you can't apply linux approaches well to windows
03:29 vimmonkey malinoff: yes. most of it is self written. for the few chunks that needs to run on windows, i've written some code that uses DCOM to interact with a few applications to automate…something that dosen't work on linux afaik. these services should be limited to within the building.
03:31 malinoff vimmonkey, i'd simply manage this stuff manually. I don't have so much time to fight with windmills, and sometimes doing brute force is better than trying to automate things
03:32 malinoff vimmonkey, if your manager insist of automating, say him that automating windows will take 3x more time than usual. Almost all windows automation talks are ending at this point
03:33 vimmonkey malinoff: true, i'm the one who actually wants to automate a few things. i'm actually going to be leaving the project in the future and wanted to have a process in place so i'm not the one with all the domain knowledge heh.
03:33 vimmonkey *all the devops knowledge
03:34 writtenoff joined #salt
03:35 vimmonkey und1sk0 & malinoff: thanks for the input, i'll sleep on it and think about it for a bit
03:36 malinoff vimmonkey, haha, there is no time to share all the devops knowledge about what I've done to automate windows stuff :) It is really better to hire a dedicated windows admin which will setup AD and will maintain it if you *really* want to automate windows stuff
03:36 TyrfingMjolnir joined #salt
03:41 jpaetzel_ joined #salt
03:45 zwi joined #salt
03:52 favadi joined #salt
03:57 otter768 joined #salt
03:59 brianfeister joined #salt
03:59 favadi joined #salt
04:08 zz_Cidan joined #salt
04:08 Cidan joined #salt
04:17 XenophonF joined #salt
04:23 ITChap joined #salt
04:26 stanchan joined #salt
04:32 __number5__ any one have a fpm-cookery recipe for salt? ubuntu
04:35 fxhp joined #salt
04:36 zach __number5__: You mean a formula?
04:38 __number5__ zach: something like this https://github.com/bernd/fpm-recipes/blob/master/supervisor/recipe.rb  but for salt itself, to package salt into debs
04:40 ndrei joined #salt
04:41 echo joined #salt
04:43 fllr joined #salt
04:44 vimmonkey joined #salt
04:45 CF032043 joined #salt
04:46 wwwBUKOLAYcom joined #salt
04:57 teogop joined #salt
05:02 ckao joined #salt
05:02 zekoZeko joined #salt
05:18 thayne joined #salt
05:19 echo joined #salt
05:20 joeto joined #salt
05:21 badon joined #salt
05:25 iggy salt fairly well packaged as is
05:26 zach yeah __number5__ why would you want to re-package salt? the packages for debian and ubuntu are already excellent
05:28 __number5__ ppa only have one version, most of the time have bugs while latest tag fixed
05:29 subsignal joined #salt
05:31 __number5__ I'm using salt-bootstrap but it seems not install salt-master upstart script for me intermittenly
05:32 iggy ppa's use reprepro... it only allows one version
05:32 iggy should use aptly
05:33 rdas joined #salt
05:33 iggy the salt repo has a debian/ dir... easy enough to package
05:33 catpig joined #salt
05:35 ITChap joined #salt
05:40 joehh1 iggy: glad I caught you! the debian dir in the salt repo is outdated
05:40 joehh1 The best debian dir is the one from the packages for your distro
05:41 joehh1 or the debian dirs from the relevant branch at  http://anonscm.debian.org/cgit/pkg-salt/salt.git
05:42 joehh1 __number5__: if you are after particular patches, either get in touch with me to add them or I can walk you through adding them
05:43 joehh1 If you are after 2014.7.5, it is available in the salt-testing ppa
05:44 iggy keep salt/debian/ up to date?
05:45 iggy I've never understood the whole disconnect between pkgs and source debian/ dirs
05:45 __number5__ joehh1: ok, thanks, might just use aptly to cache the salt-testing ppa
05:45 joehh1 actually needs to be deleted - too much difference between packaging for each distro/release
05:45 joehh1 I've talked about it for a long time, but I think I'll do the pull request to do so now
05:47 krelo joined #salt
05:48 iggy I give up
05:48 rdas joined #salt
05:51 blacked joined #salt
05:55 Kelsar joined #salt
05:58 zekoZeko yay, i made the asterisk formula useful. It can build basic config files for a small office with a SIP trunk now :)
05:58 otter768 joined #salt
06:06 spookah joined #salt
06:08 monkey661 joined #salt
06:08 ajw0100 joined #salt
06:09 colttt joined #salt
06:18 ndrei joined #salt
06:19 viq joined #salt
06:22 rhodgin joined #salt
06:34 Nazzy joined #salt
06:36 Nazca__ joined #salt
06:36 KermitTheFragger joined #salt
06:38 kawa2014 joined #salt
06:39 Terminus- joined #salt
06:40 isodude_ joined #salt
06:43 flyboy joined #salt
06:56 Auroch joined #salt
07:01 joeto Hi all, My salt version is salt 2014.7.4 (Helium). I have some questions about S3 rootfs - in config "s3" do not works I need to use only "s3fs", also fileserver.update on master do not initiate s3 sync :( how I can do this and last but not least :) how to change default 60 secs sync?
07:04 j-saturne joined #salt
07:06 solidsnack joined #salt
07:07 solidsnack I tried creating a module and putting it in _modules/, then calling it with the `local.<module>.<function>` in the reactor.
07:07 solidsnack But Salt says "'<module>.<function>' not available"
07:07 blacked joined #salt
07:08 solidsnack And this even though I ran `saltutil.sync_modules`
07:09 funzo joined #salt
07:10 mosen did it show the module name after running sync_modules ?
07:11 solidsnack No.
07:12 eseyman joined #salt
07:13 solidsnack However, it did get placed on the minion:
07:13 mosen ah sorry i might be thinking of sync_all
07:13 solidsnack /var/cache/salt/minion/extmods/modules/<module>.py
07:13 solidsnack /var/cache/salt/minion/files/base/_modules/<module>.py
07:15 Romlok joined #salt
07:16 solidsnack Do I need to `import salt`?
07:17 babilen mosen: It would show the module with sync_modules too IIRC
07:17 mosen babilen: ah yeah couldnt remember because i generally use all when developing somerthing
07:17 babilen likewise :)
07:17 mosen solidsnack: no need to import anything
07:17 mosen although salt.utils has some exceptions and stuff that are useful
07:18 babilen solidsnack: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.saltutil.html#salt.modules.saltutil.refresh_modules might be worth a try
07:18 kerberos is someone familiar with augeas? could you look at my problem with simple state: http://pastie.org/private/qn9qsonzgdt92nkwgnk8a
07:18 mike25de joined #salt
07:19 c10b10 joined #salt
07:22 alub joined #salt
07:23 rhodgin joined #salt
07:23 slav0nic joined #salt
07:23 slav0nic joined #salt
07:31 JayFK joined #salt
07:32 kawa2014 joined #salt
07:38 solidsnack It was syntax errors and stuff.
07:38 solidsnack The master logs didn't warn me :(
07:40 mosen try -l debug ?
07:44 solidsnack I mean, the log file.
07:44 solidsnack It's set to debug in the conf file.
07:44 yomilk joined #salt
07:44 mosen oh right
07:44 mosen im not sure what it does when it catches ImportError
07:45 babilen Modules with exceptions on import are simply disabled
07:46 c10b10 joined #salt
07:47 wvds-nl joined #salt
07:52 blacked joined #salt
07:59 otter768 joined #salt
08:00 faust joined #salt
08:00 blacked joined #salt
08:02 bluenemo joined #salt
08:07 kermit joined #salt
08:12 yomilk joined #salt
08:12 Xevian joined #salt
08:14 jakubm mourning.
08:16 CeBe joined #salt
08:16 chiui joined #salt
08:20 aquassaut joined #salt
08:20 ktosiek joined #salt
08:21 cberndt joined #salt
08:27 thayne joined #salt
08:27 kermit joined #salt
08:30 evilrob_ joined #salt
08:31 pf_moore joined #salt
08:34 Cidan joined #salt
08:35 bdols joined #salt
08:36 blacked joined #salt
08:36 pppingme joined #salt
08:45 mike25de hi guys... i have an older version of salt. The issue is that at some point  my salt-minion version is upgraded to the latest version which messes up my installations. When i install salt-minion  i can specify the version, but later somehow the version is changed to the latest available. How can i prevent that?
08:45 mike25de thanks in advance
08:46 babilen That really depends on how you install your minion and how it is upgraded
08:46 j-saturne joined #salt
08:46 babilen You are probably quite aware of that, but you want your master to have the same or a higher version than your minions
08:47 al joined #salt
08:48 mike25de babilen: exactly... master is one version, but the minion gets a newer one at some point. I use centos os
08:49 CedNantes joined #salt
08:49 mike25de as far as i know... i do not update the salt-minion
08:49 babilen Well, it certainly doesn't update itself
08:49 mike25de and when i kickstart a new server i use the correct version :)
08:50 mike25de babilen: does salt run an yum upgrade at some point?
08:50 CedNantes hello
08:50 mike25de i presume it does
08:50 babilen Then check your logs (I am sure that CentOS has, much like Debian, very detailed logs about package upgrades)
08:50 mike25de thanks man
08:50 mike25de will do that
08:51 babilen You *can* upgrade a minion using pkg.upgrade, but that is not run by default in any way. If it is run then because *you* (or somebody else) explicitly included that or ran it manually
08:51 mike25de babilen:  thanks man!
08:54 CedNantes Here i am again :p I'm actually creating VM on a VCenter using salt with salt.cloud module. Virtual machines creation works so far, but i can't seem to get the minion to install on the new machine...
08:55 CedNantes I tried something like this : https://www.refheap.com/99908
08:56 CedNantes ssh user name and password is not working as i thought it would.
08:56 Terminus- joined #salt
08:56 CedNantes anyone using salt with vmware ?
09:01 fredvd joined #salt
09:01 phx joined #salt
09:03 malinoff joined #salt
09:04 markm joined #salt
09:05 CedNantes joined #salt
09:16 hebz0rl joined #salt
09:16 kermit joined #salt
09:19 kermit joined #salt
09:24 rhodgin joined #salt
09:25 ashb mike25de: using the bootstrap script we do `bootstrap-salt.sh git v2014.1.4`
09:26 mike25de ashb i see that :) my problem seems to be... due to a yum update that one of my colleagues run
09:26 mike25de i will add to my /etc/yum.conf    exclude=salt* so the salt package which is installed remains the same
09:26 ashb ah. yeah
09:27 ashb We don't have that problem as the bootstrap installs via git so not a package (thought it takes *forever* to do :()
09:27 malinoff mike25de, it is better to pin packages than exclude them
09:28 mike25de malinoff: what do you mena?
09:28 mike25de mean*
09:28 malinoff mike25de, http://yum.baseurl.org/wiki/Faq#Q.4:HowcanIgetyumtokeeppackagefooatacertainversioninafashionsimilartopinningprovidedbyapt
09:28 c10b10 joined #salt
09:29 mike25de ah the versionlock
09:29 mike25de i remember that malinoff
09:29 mike25de GREAT malinoff thanks a lot
09:29 monkey66 joined #salt
09:31 safa joined #salt
09:34 denys joined #salt
09:36 j-saturne joined #salt
09:40 peters-tx joined #salt
09:45 theag3nt joined #salt
09:46 CeBe1 joined #salt
09:47 Hell_Fire joined #salt
09:52 refnode joined #salt
09:59 fredvd joined #salt
10:00 ITChap joined #salt
10:03 giantlock joined #salt
10:04 __ale__ joined #salt
10:06 c10b10_ joined #salt
10:09 fredvd joined #salt
10:14 _ale1_ joined #salt
10:17 jespada joined #salt
10:18 theag3nt joined #salt
10:25 rhodgin joined #salt
10:29 ndrei joined #salt
10:30 yidhra joined #salt
10:31 catpig joined #salt
10:33 JDog joined #salt
10:34 JDog Anyone use the virtualenv state?
10:34 c10b10_ is it normal for salt-master to have so many processes: https://www.dropbox.com/s/339tjl4s103x8vy/Screenshot%202015-04-22%2013.34.10.png?dl=0 ?
10:34 bhosmer joined #salt
10:36 mosen joined #salt
10:37 huddy joined #salt
10:40 c10b10_ answer to my question: https://github.com/saltstack/salt/issues/5376
10:42 c10b10_ does anybody have a ppa for the latest pygit2 for ubuntu 14.04?
10:43 * c10 = c10b10_
10:57 jakubm is anyone using external_auth with pam and groups and would be happy to share their config?
10:58 jakubm I'm trying to follow the http://docs.saltstack.com/en/latest/topics/eauth/index.html document but it doesn't seem to work when specifying group
10:58 jakubm it works with users but not groups
11:00 jrluis joined #salt
11:06 evle joined #salt
11:11 _ale1_ joined #salt
11:13 Cidan joined #salt
11:16 rdas joined #salt
11:17 Morbus joined #salt
11:28 favadi joined #salt
11:29 jerematic joined #salt
11:30 ndrei joined #salt
11:31 echo joined #salt
11:33 refnode joined #salt
11:34 jakubm is everyone running salt command as root?
11:34 mage_ nop
11:36 mage_ salt master runs under a dedicated user and I use client_acl
11:40 jakubm would that work with salt-api?
11:41 Romlok " Command 'git pull ' failed. Stderr: '' "
11:41 Romlok so much for force, force_checkout and force_reset
11:43 Romlok apparently Salt doesn't play nice when a tracked repo has had forced updates
11:44 Romlok I wondered where it was coming up with all these commit hashes
11:47 ndrei joined #salt
11:56 j-saturne joined #salt
11:56 j-saturne joined #salt
12:00 otter768 joined #salt
12:02 joehh1 mage_: how do you deal with that from a packaging perspective?
12:02 joehh1 ie which os are you and how do you manage/deploy that
12:02 joehh1 ?
12:02 mage_ I use FreeBSD
12:04 mage_ joehh1: note that the minions run as root, only the master runs under a dedicated user
12:06 ekristen joined #salt
12:09 isodude_ joined #salt
12:10 chiui joined #salt
12:11 tmclaugh[work] joined #salt
12:14 joehh1 is that the default for freebsd or is it something you have added?
12:21 mage_ it's just adding an user and adapt the conf file
12:21 mage_ it's not the default
12:24 mpanetta joined #salt
12:24 markm joined #salt
12:24 rypeck joined #salt
12:25 andrew_v joined #salt
12:26 Auroch joined #salt
12:27 chiui joined #salt
12:28 joehh1 did much else need to change - I've been thinking about doing it for the debian/ubuntu packages, but
12:28 joehh1 don't want to break everyones installs...
12:30 cmcmacken joined #salt
12:34 cpowell joined #salt
12:36 zircote joined #salt
12:37 dendazen joined #salt
12:39 yuhl_work_ joined #salt
12:43 bhosmer joined #salt
12:52 redzaku joined #salt
12:55 ndrei joined #salt
12:58 ekle joined #salt
12:58 TyrfingMjolnir joined #salt
12:59 ekle hi, if i run cmd.run as a schedule the field retcode is missing in the returner. if i run it manually the field is there. any ideas ?
13:00 JDiPierro joined #salt
13:00 MAbeeTT_ joined #salt
13:03 overyander salt 2014.7.1 on windows shows a python27.dll file in the install dir. what version of python should i be using on the master? I think I'm running into this issue https://github.com/saltstack/salt/issues/18567 and want to make sure that my python-crypto versions are the same. My master is using python-crypto version 2.6.1-1
13:04 tmh1999 joined #salt
13:06 Timoteo joined #salt
13:07 subsignal joined #salt
13:09 TooLmaN joined #salt
13:11 CF032043 joined #salt
13:12 dyasny joined #salt
13:14 Tecnico1931 joined #salt
13:21 racooper joined #salt
13:23 jonlangemak joined #salt
13:26 amcorreia joined #salt
13:26 zwi joined #salt
13:27 jdesilet joined #salt
13:27 lothiraldan joined #salt
13:27 rhodgin joined #salt
13:33 kermit joined #salt
13:33 fusionx86 joined #salt
13:33 kermit joined #salt
13:34 tmh1999 joined #salt
13:34 overyander salt 2014.7.1 on windows shows a python27.dll file in the install dir. what version of python should i be using on the master? I think I'm running into this issue https://github.com/saltstack/salt/issues/18567 and want to make sure that my python-crypto versions are the same. My master is using python-crypto version 2.6.1-1
13:34 mapu joined #salt
13:35 tmh1999 joined #salt
13:37 cwyse_ joined #salt
13:37 MAbeeTT joined #salt
13:38 zekoZeko isn't pillar.get('asterisk', {})['sip'] same as pillar.get('asterisk:sip', {}) ?
13:38 zekoZeko the second does not work for me...
13:39 zekoZeko and it will fail when 'asterisk' does not exist i guess...
13:39 zekoZeko the first one will fail i mean
13:41 xintron joined #salt
13:41 faust zekoZeko: pillar.get('asterisk', {'sip':{}})['sip']
13:42 xintron I have a state where I generate a config file (and restart a service based on changes to the file). If I run state.sls <state> test=True; I see that the file is "new" and will be created, but is there any way to see what the generated file would look like?
13:42 faust zekoZeko: where did you find that strange syntax?
13:43 xintron I'm using jinja template so I want to verify the file before running it live (and having the service restart)
13:43 ze- salt['pillar.get']('asterisk:sip', {})
13:43 zekoZeko you see a diff with state.sls (as well as hightstate)
13:43 zekoZeko faust: on my own i guess. trying to get stuff to work :)
13:43 ze- the function uses the : split, the dict itself (pillar.get()) does not.
13:43 faust oh it saltic
13:43 faust it's*
13:43 Grokzen joined #salt
13:43 zekoZeko let me try
13:44 ze- zekoZeko: explained here: http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html
13:47 iggy xintron: salt-call -l debug should show the rendered jinja
13:48 xintron iggy, ok, so if I run it on the minion it would work
13:48 Tyrm joined #salt
13:48 xintron (tried with salt -l debug but didn't see anything)
13:48 iggy _should_
13:49 xintron :)
13:49 xintron Doesn't seem to work if it's a completely new file
13:50 timoguin joined #salt
13:50 Brew joined #salt
13:58 jonlangemak Whats the best way to debug Jinja in a state?  I’ve read about the ‘show_full_context’ flag but Im not clear on how to implment that in a state.
13:59 jonlangemak Is there a way for the state to output the variables it pulls from the grains I use in the template so I can see what they are?
14:01 zircote joined #salt
14:01 fredvd joined #salt
14:01 otter768 joined #salt
14:04 _JZ_ joined #salt
14:04 lothiraldan joined #salt
14:04 thayne joined #salt
14:08 j-saturne joined #salt
14:09 j-saturne joined #salt
14:10 fyb3r joined #salt
14:11 favadi joined #salt
14:11 iggy that would be what show_full_context() does
14:13 kaptk2 joined #salt
14:14 jmdcalks left #salt
14:15 jmdcal joined #salt
14:15 jonlangemak iggy: Could you give me an example of how to add that to my state file?  Im not clear on how to implement it
14:18 echo joined #salt
14:22 tmh_ joined #salt
14:27 yidhra joined #salt
14:28 rhodgin joined #salt
14:28 tmh_ joined #salt
14:28 j-saturne joined #salt
14:29 j-saturne joined #salt
14:31 kawa2014 joined #salt
14:32 zircote joined #salt
14:33 theag3nt joined #salt
14:35 joehh1 overyander: I would recommend waiting a few hours till the west coast of the US is up and about
14:37 iggy jonlangemak: {{ show_full_context() }}
14:39 jonlangemak iggy: Yeah, I tried that and when I ran the state it just puked out a bunch of garbage.  I must be using it wrong..
14:40 iggy joeto: the s/s3/s3fs/ is a well known docs bug that nobody has bothered to fix (feel free to open an issue, send a PR, etc.); fileserver.update should do a sync, if not, it's a bug; you can't change the sync interval... it's tied to the salt scheduler timer for some ridiculous reason
14:41 iggy jonlangemak: nah.... that's pretty much what it does
14:41 zwi joined #salt
14:41 jonlangemak ah ok.  So I should be using that with very small states then?
14:41 iggy the context will be mostly the same either way
14:42 joeto iggy: thank you very much :) clear now :)
14:47 iggy less than 8 hour turnaround for answers... that's better than most companies you pay money to
14:50 fusionx86 joined #salt
14:51 elfixit joined #salt
14:54 debian112 joined #salt
14:55 Xevian joined #salt
14:56 Nazzy joined #salt
14:58 isodude_ joined #salt
14:59 redzaku joined #salt
14:59 zircote joined #salt
15:01 rhodgin joined #salt
15:01 cro joined #salt
15:04 fredvd joined #salt
15:04 zwi joined #salt
15:06 scbunn joined #salt
15:11 XenophonF iggy: the s/s3/s3fs/ bug is in the docstring of the fileserver module
15:11 * Gareth tosses iggy a scooby snack
15:11 XenophonF I'll file a PR or pull request if no one else has yet.
15:12 vstoniest joined #salt
15:13 desposo joined #salt
15:15 dave_den joined #salt
15:17 echo joined #salt
15:17 ekle how can i make cmd.run fail, if the return code is not 0 ?
15:20 jakubm|away http://docs.saltstack.com/en/latest/ref/states/all/salt.states.cmd.html
15:21 zircote joined #salt
15:21 cro joined #salt
15:21 jakubm|away ekle:
15:24 ekle salt-call --metadata cmd.run bad
15:24 jonlangemak joined #salt
15:24 Gareth ekle: Hey.  Thanks for the help with that schedule issue (#22571).  If you're able to test that PR referenced against 2014.7, that would be great.
15:25 ekle @jakubm|away ^^^this returns success:True. But there is no command called "bad" therefore this should fail ?
15:27 I3olle joined #salt
15:28 ALLmightySPIFF joined #salt
15:29 ALLmightySPIFF joined #salt
15:30 favadi left #salt
15:30 ekle @Gareth: i will look at it tomorrow
15:30 theag3nt joined #salt
15:31 ALLmightySPIFF joined #salt
15:31 jakubm|away ekle: cmd.retcode maybe then? not sure - sorry - thought that the doc may help you
15:33 ekle i will try it, but there isn't much docu about it
15:33 iggy babilen: fixup those 2 things and I'll snag it
15:34 murrdoc joined #salt
15:35 Guest70 joined #salt
15:35 hasues joined #salt
15:38 jmdcal left #salt
15:38 echo joined #salt
15:38 hasues left #salt
15:40 Grokzen joined #salt
15:42 thayne joined #salt
15:43 bhosmer joined #salt
15:43 SeeDickCode joined #salt
15:46 zircote joined #salt
15:47 bhosmer joined #salt
15:48 overyander i'm reading a registry key in an if statement. how can i check to see if the key is a value greater than 4? right now, i'm checking to see if the value == something. is it as simple as using >= 4 instead of == ?
15:49 zekoZeko This is my problem, is there a better way to go about it?
15:49 zekoZeko https://gist.github.com/borutmrak/333049c7e43cd7d7aab8
15:49 lothiraldan joined #salt
15:50 iggy overyander: yes (assuming it's read as an int)
15:51 overyander thanks iggy
15:52 iggy zekoZeko: for parent you probably want to make it a list... I'm not sure what you have currently is proper yaml
15:52 cpowell joined #salt
15:52 zekoZeko iggy: it works, but I think it can be made much prettier
15:53 zekoZeko iggy: this is bothering me, I don't know when to use lists and when dicts in pillars
15:53 pdayton joined #salt
15:53 iggy it really just depends what you're doing
15:53 iggy if you need key: value mappings, go with dicts, otherwise it's easier to loop over lists
15:53 murrdoc when u want to use the value as a key/value use a dict
15:54 murrdoc other wise #ssceapproved already said it nvm
15:55 iggy and yes, that is valid yaml, it's just kind of weird to see it written like that (normally you'd just see parent: "!" on the same line
15:55 CheKoLyN joined #salt
15:56 zekoZeko iggy: i guess I could use a list of dicts for my extensions, don't know if it would make much difference. Besides it's IMO better to use dicts for things that should be unique. dunno, not really much of a programmer.
15:57 iggy I'm a firm believer of "use whatever works best for you"
15:58 funzo joined #salt
15:58 zekoZeko now I just have to wrap my head around the salt methods and what/how they return :)
15:58 nzero zekoZeko: not sure uniqueness is a good standard for determining when to use dicts. would you rather have a list of animals = [ cat, dog, horse], or a dict of animals = [ cat: cat, dog: dog, horse: horse ]. im exaggerating here, but you can see the dict doesnt add anything of real value
15:59 kusams joined #salt
16:00 iggy zekoZeko: if you change it to {% for user, args in salt['pillar.get']('asterisk:sip:users').iteritems() %} (or something similar, forget the exact syntax) you don't have to do all the checking (pillar.get will return an empty dict and you'll just have a loop of 0)
16:00 echo joined #salt
16:00 zekoZeko nzero: it does in my case, i'm using it for other data on the keys.
16:00 zekoZeko iggy: this looks much better, thanks.
16:01 ajw0100 joined #salt
16:01 iggy and my personal preference is to indent the jinja tags if they are nested, but that's kind of a personal call
16:02 gamedna joined #salt
16:02 nmistry joined #salt
16:02 speedlight joined #salt
16:02 otter768 joined #salt
16:03 zekoZeko i agree, but I had trouble with whitespace then
16:03 overyander does highsate automatically refresh the winrepo packages making it pointless to run pkg.refresh_db manually?
16:04 smcquay joined #salt
16:05 iggy zekoZeko: use more -'s ;)
16:07 ndrei joined #salt
16:08 zekoZeko iggy: then I lose newlines! :) Too much stuff to learn at once. At least I got around to fixing formulas and not just using salt to install packages/files :)
16:09 spookah joined #salt
16:09 iggy zekoZeko: {% for exts in args.get('localexts', [user,]) %}
16:09 bluenemo joined #salt
16:09 dalexander joined #salt
16:09 iggy for ext in that is
16:12 Tyrm_ joined #salt
16:14 zekoZeko that took away a few lines, thanks :)
16:17 drico joined #salt
16:17 troyready joined #salt
16:17 drico Hi, how can I see the result of a generated sls for debugging purposes ?
16:17 iggy protip: put code in `'s (or ```'s for blocks) to avoid having salt['pillar.get'] turn into a link
16:18 iggy drico: salt-call -l debug will show the rendered jinja
16:18 writtenoff joined #salt
16:18 theologian joined #salt
16:19 drico iggy, thanks, but in this case that's a formula and that will defer for each minion
16:20 drico I get a  'Unable to manage file: none of the specified sources were found'
16:20 drico but I cannot see what path it generates
16:20 iggy that's the only way to see the rendered jinja unfortunately
16:22 signull joined #salt
16:22 echo joined #salt
16:22 jalbretsen joined #salt
16:24 SeeDickCode joined #salt
16:25 drico I can see all my variable but no rendered jinja that's what puzzles me
16:26 desposo joined #salt
16:26 drico oh ok I get it
16:26 KyleG joined #salt
16:26 KyleG joined #salt
16:28 zer0def uh, there was a salt state that executed a function from a salt execution module - anyone wants to give a reminder?
16:28 twisty7867 joined #salt
16:28 twisty7867 hi there. I am trying to use a masterless minion and pass some pillar data in from the command line. it seems like it gets ignored. is this supported?
16:29 zer0def nevermind, it's "module"
16:32 zer0def twisty7867: did you attach that pillar data to your targetted machine via pillar's topfile?
16:33 zer0def (i might've understood you wrong and you're passing pillar values through cli)
16:33 twisty7867 yes, passing through CLI. for example:
16:33 zer0def hold up, let me read up then
16:34 signull left #salt
16:34 signull joined #salt
16:34 zer0def twisty7867: you probably meant this, correct?: http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html#setting-pillar-data-on-the-command-line
16:35 redzaku joined #salt
16:35 twisty7867 yes, exactly
16:35 cpowell joined #salt
16:35 twisty7867 I have tried a variety of permutations and it just seems like it gets ignored. both when using the Vagrant salt provisioner as well as when running salt-call manually from an EC2 bootstrap
16:36 zekoZeko iggy: how would I go about simplifying this? I could just condense this into only allowing a single "allow" options which is cleaner and more readable anyway... https://gist.github.com/borutmrak/333049c7e43cd7d7aab8#comment-1438487
16:36 andrew_v joined #salt
16:37 twisty7867 in particular, what I am doing is passing in an "EnvName" variable that causes another pillar to load a specific config file. probably not a best practice, but I am trying to minimally invasively migrate from bash-based provisioning to salt
16:39 MatthewsFace joined #salt
16:40 SeeDickCode joined #salt
16:40 druonysus joined #salt
16:40 monkey661 joined #salt
16:41 zer0def twisty7867: works with the 'state' execution module
16:41 iggy twisty7867: an example of what you're trying wouldn
16:41 iggy 't hurt
16:42 j-saturne joined #salt
16:42 iggy zekoZeko: not really sure what you're trying to do there, but that doesn't look terribly disgusting
16:43 MatthewsFace joined #salt
16:43 echo joined #salt
16:44 twisty7867 sure. I pass in this on the command line, via Vagrant: https://gist.github.com/twisty7867/2039061f4877897c9945 and the value of EnvName is not present when this pillar is subsequently loaded: https://gist.github.com/twisty7867/94c22db39df0bbcd718a
16:44 teepark salt.states.file is surprisingly missing a clear way to remove an existing file -- is that by design?
16:44 dalexander joined #salt
16:45 twisty7867 same thing happens in alternate scenario where I create a user-data script for an EC2 instance via CloudFormation, but I can't run that at the moment since I have to use IRC from a public network
16:45 cmcmacken joined #salt
16:45 teepark I'm looking to change my nginx configuration, which will involve removing one /etc/nginx/conf.d/*.conf and editing another
16:46 twisty7867 teepark: it's not: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.absent
16:46 zer0def teepark: file.absent?
16:46 teepark oh damn how did I miss that
16:46 twisty7867 :)
16:46 zer0def teepark: also, if that's a one-shot thing, there's probably an execution function for it
16:46 teepark I looked at "missing", which says it doesn't remove it, just reports back false
16:47 Guest70 joined #salt
16:47 teepark thanks
16:47 zekoZeko teepark: file.missing
16:47 zekoZeko it should remove it
16:48 teepark zekoZeko: no, it doesn't (at least it's documented as not removing it), this was the source of my confusion
16:48 zer0def teepark: also: salt '*' file.remove(<path>) - http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.file.html
16:48 iggy twisty7867: if I'm reading that correctly (unlikely as I don't use vagrant), you are passing the pillar wrong
16:49 zer0def well, passed the argument wrong, but eh.
16:49 zer0def iggy, twisty7867: wouldn't the surrounding 'cmdline' be redundant for he's trying to accomplish?
16:50 twisty7867 I initially tried to pass just EnvName
16:50 iggy I don't know... I want to see the salt-call cmd that's failing
16:50 iggy I'm not learning vagrant to help someone out
16:50 twisty7867 which also didn't work. then I read that you pass an entire pillar, so I tried enclosing it that way
16:50 twisty7867 fair enough. can you read CloudFormation instead? :)
16:50 twisty7867 https://gist.github.com/twisty7867/3a683f1dee82c17c345d
16:52 zer0def twisty7867: from what i understand while doing quick translantion from ruby to yaml, {"EnvName" => "asdf"} oughta do the trick
16:53 zer0def twisty7867: try using what you have right now and refer to cmdline:EnvName?
16:53 twisty7867 so I thought also. I tried that at first. Let me try it again and see what happens... I spent yesterday afternoon bashing my head convinced the next tiny change would make it work and so the results are a bit muddled in my mind.
16:54 iggy uhhh... yeah, that's not really doing it for me either
16:55 zer0def well, salt['pillar.get']('cmdline:EnvName', 'vagrantx'), to be exact
16:55 bash124512 joined #salt
16:56 iggy it doesn't look obviously wrong if that helps
16:58 jespada joined #salt
16:59 twisty7867 so before I noticed your suggestion about cmdline:EnvName, I removed that and ran it again. here's what I get: https://gist.github.com/twisty7867/46c817675139ec9ec82f - if I remove the "x" from that default it works fine
17:00 twisty7867 (meaning that those values are in fact in the deploy.properties file, it's just not getting read because of the lack of EnvName pillar)
17:01 walker_ joined #salt
17:03 zer0def twisty7867: you mean you removed cmdline or... ?
17:03 zer0def yes, i get easily confused.
17:04 twisty7867 yes, I did remove cmdline.
17:04 twisty7867 hey, helpful + easily confused > unhelpful
17:05 zer0def so it works when your default is 'vagrant'?
17:05 zer0def want.
17:05 zer0def wat.*
17:05 echo joined #salt
17:06 twisty7867 yes, it works when the default is vagrant (on vagrant at least, obvs that doesn't work in my test enviro on AWS which has a different config folder)
17:07 zer0def point being is that only removing the "cmdline" parent object should've done the trick, so unless something mis-cached, my brain's having a microimplosion
17:07 twisty7867 well, I can fix the caching issue, it's just a VM. I will destroy it and create it again :)
17:08 SpeedFuse joined #salt
17:08 zer0def hey, that's the best i've got so far, so if that proves reliable over a few more tests, then you could be set
17:11 twisty7867 no dice, same result. do I need something in my pillar top to refer to the command line pillars?
17:11 zer0def nothing that i'm aware of
17:12 murrdoc joined #salt
17:12 zer0def i'd blame vagrant, been having a bit of headaches 'cause of them already :D
17:17 mdn15 joined #salt
17:18 stanchan joined #salt
17:19 twisty7867 I wouldn't be averse to blaming them except that I first discovered this when deploying to AWS
17:19 murrdoc joined #salt
17:20 twisty7867 so I ran the provisioning again with log level set to garbage
17:20 twisty7867 and nowhere other than the command line does EnvName appear
17:22 ajw0100 joined #salt
17:22 jespada joined #salt
17:24 JDiPierro joined #salt
17:27 fxhp joined #salt
17:27 echo joined #salt
17:27 cmcmacken joined #salt
17:29 shaggy_surfer joined #salt
17:30 ipmb joined #salt
17:31 ipmb Will Salt reliably "merge" nested dictionaries in a pillar?
17:31 cmcmacken joined #salt
17:32 ipmb for example, if I define "app:env:key1" and "app:env:key2", am I guaranteed the pillar['app']['env'] dict will have both key1 and key2?
17:33 lumtnman joined #salt
17:34 iggy ipmb: I wouldn't rely on it, but it mostly works
17:35 ipmb I've found it works reliably for top-level dictionaries
17:41 FeatherKing joined #salt
17:41 iggy hah... I guess not many people use the postgres-formula on !debian
17:44 faust left #salt
17:46 timoguin joined #salt
17:47 evidence iggy: created a ticket on the master.d conf loading business, not sure if you noticed anything yesterday - https://github.com/saltstack/salt/issues/22956
17:47 bhosmer joined #salt
17:48 druonysus joined #salt
17:48 druonysus joined #salt
17:48 tmclaugh[work] joined #salt
17:48 echo joined #salt
17:50 anotherZero joined #salt
17:51 krelo joined #salt
17:54 iggy I'm interested to see what they say
17:58 monkey66 joined #salt
18:02 murrdoc joined #salt
18:02 twisty7867 tried this again on EC2 just to get Vagrant out of the equation. still no joy: https://gist.github.com/twisty7867/ea821423c59bb8a8ad86
18:03 otter768 joined #salt
18:06 bemehow joined #salt
18:06 mapu joined #salt
18:10 echo joined #salt
18:12 babilen iggy: bloody hell, that's what you get for rebasing and making the commits beautiful .. :D
18:12 babilen *sigh*
18:13 mdn15 Hi. I just started using salt.  Is there a way I can call state.sls to execute say B.sls within say A.sls?
18:14 manfred include:
18:14 manfred - B
18:14 manfred mdn15:  http://docs.saltstack.com/en/latest/ref/states/include.html
18:16 mdn15 i've tried that.  However, order is important.  When I include B.sls at the bottom of A.sls, it B.sls is run first.
18:17 twisty7867 - require:       - sls: A
18:17 iggy why don't you explain better what you are trying to do (maybe include some pseudo code, what you've got now, etc)
18:18 twisty7867 you might be better off setting the dependencies on the individual states in the long run.
18:19 mdn15 sure.  So I want to use A.sls to install linux-image and linux-headers.  once the packages are installed. I want to call B.sls which handles updating grub and possibly applying other defaults to /etc/default/grub
18:19 mdn15 I know this can be done by calling multiple states individually, but I cant seem to chain the sls files
18:21 debian112 joined #salt
18:21 dalexander joined #salt
18:21 mdn15 by.. salt '*' state.sls A.sls; salt '*' state.sls B.sls
18:23 mdn15 I have a test case where I need to install and boot many different kernel versions (driver testing) and was hoping this could be accomplished with salt
18:23 denys joined #salt
18:23 penguinpowernz joined #salt
18:24 manfred that shouldn't be the case, by default it should run them in the order you specify
18:24 manfred based on where you include
18:24 manfred one second
18:24 mdn15 so I have the following...
18:25 mdn15 kpgks:
18:25 mdn15 pkg.installed:
18:25 mdn15 - linux-image ..... etc (packages)
18:25 mdn15 then
18:25 mdn15 include:
18:25 mdn15 - .update grub.
18:26 iggy A include: has to be the first line in a file
18:26 mdn15 the sls called update-grub.sls (eg B.sls)  is always running first
18:26 iggy B use requisites
18:26 iggy I think you are thinking about this wrong
18:27 iggy if you don't want to put related state stanzas in the same sls file and don't want them run, then put A and B in your top file in order
18:28 Chuck_ joined #salt
18:28 juanito joined #salt
18:29 Vynce joined #salt
18:29 mdn15 hm.  either that or I can keep one .sls that handles the pkg deps and updating grub but use grains to specify the kernel version
18:29 bemehow_ joined #salt
18:29 iggy or pillar (as you can set that on the command line, it'll further ease testing)
18:30 manfred mdn15:  https://github.com/saltstack/salt/issues/5255
18:30 manfred might have never happened for includes
18:30 Chuck_ Hello, Im trying to install software from a binary installer using a salt state. I can get the installer going but it has silent install flags. Does know where I can get information on doing this? Windows was simple but with Linux I cant seem to find any info on it.
18:31 mdn15 thanks iggy, manfred, and twisty7867.  Ill take a look into pillars and grains into more detail as well as look at the links posted.  This will get me going.
18:32 echo joined #salt
18:32 manfred Chuck_:  probably best to just use cmd.run or archive.extracted, or something else, and have an unless: statement that checks if a specific file from the binary blob exists
18:32 manfred but as with linux, it is always preferable to have an actual package for the desired distribution
18:33 Chuck_ yes, thats what I am using, during the install it requires input/install flags, how can i specify these?
18:33 stanchan joined #salt
18:33 murrdoc joined #salt
18:33 Chuck_ for windows you can specify - install flags:, what about for linux?
18:34 manfred are you running a binary file to install the software?
18:34 Chuck_ yes
18:34 manfred you should just be able to pass the full command as that name: variable for a cmd.run state
18:34 manfred install pkg:
18:34 manfred cmd.run:
18:34 manfred name: /path/to/binary —flags
18:35 Chuck_ great, ill try it out. thanks for the help.
18:39 c10 joined #salt
18:39 hemphill joined #salt
18:40 eriko joined #salt
18:40 debian112 joined #salt
18:42 bhosmer__ joined #salt
18:43 debian112 left #salt
18:44 debian112 joined #salt
18:48 ryuhei joined #salt
18:49 thedodd joined #salt
18:53 hal58th_ joined #salt
18:53 hal58th_1 joined #salt
18:53 echo joined #salt
18:54 scbunn joined #salt
19:00 samnmax joined #salt
19:01 JDiPierr_ joined #salt
19:03 pviktori___ joined #salt
19:05 vexati0n SO... when using salt-syndic, every CLI command on the topmost master waits a ridiculous amount of time to hear from syndic masters before returning, even if the command is aimed directly at a single minion and that minion has already replied.
19:05 vexati0n is there any way to make it not do that...
19:06 debian112 left #salt
19:06 iggy did you try all the stuff we told you to try yesterday?
19:07 vexati0n well, I left the connection open before I saw any replies
19:07 vexati0n ssh+irssi=convenient but you miss things ...
19:07 LtLefse +screen :)
19:07 vexati0n eh. well byobu but yeah.
19:10 Guest70 Channel logs are available at http://irclog.perlgeek.de/salt/
19:10 pviktori_ joined #salt
19:11 vexati0n looked in irclogs .. suggestion was to use the -t option, but that has no effect on CLI commands. it still waits the full timeout as specified in the config file before returning.
19:12 vexati0n besides, if the minion takes longer than my arbitrary -t option to reply, i still want that reply. Salt should realize it's only targeting a specific minion, and if it hears from that minion, it should return immediately instead of waiting for more replies.
19:14 solidsnack joined #salt
19:15 viq joined #salt
19:15 echo joined #salt
19:15 solidsnack It seems that Salt can not do hierarchical modules in _modules/...
19:16 solidsnack Is this by design? It seems bad, when you think about vendoring stuff.
19:16 solidsnack I'd love to be able to put all my company's modules in `com.example.<module>`, for example.
19:17 echo joined #salt
19:18 murrdoc joined #salt
19:22 cornfeedhobo joined #salt
19:23 cornfeedhobo hello, this is the room for salt stack, correct?L
19:23 TheNumb correct
19:25 manfred solidsnack:  do you mean like putting them in /srv/_modules/com/example/<module> ?
19:26 solidsnack Right.
19:26 ajw0100 joined #salt
19:26 manfred you can't do that with regular modules either
19:26 solidsnack In Python?
19:26 solidsnack Yes I can.
19:26 manfred not in salt
19:26 manfred salt modules*
19:26 solidsnack Okay.
19:26 manfred it is in site-packages/salt/modules/<thing>.py
19:26 manfred you can't have sub directories in there either
19:27 solidsnack But is that an implementation limitation, or a wise decision that I am misunderstanding?
19:27 manfred i don't know if there is a specific reason for it
19:28 solidsnack Hmm, okay. Well, maybe I can come back to it later.
19:29 solidsnack In `top.sls`, is there a way to mask out servers? Like, `'* except for this one: '`
19:29 ipmb solidsnack: look at compound matching
19:29 manfred yes
19:29 manfred http://docs.saltstack.com/en/latest/topics/targeting/compound.html
19:30 manfred * and not <thing>
19:31 chiui joined #salt
19:31 solidsnack Cool
19:31 ndrei joined #salt
19:32 solidsnack I don't want to install Nginx and all that stuff on the Salt server :)
19:33 JDiPierro joined #salt
19:34 MaliutaLap joined #salt
19:34 MaliutaLap left #salt
19:38 mrtrosen joined #salt
19:40 c10 joined #salt
19:40 murrdoc joined #salt
19:40 c10 joined #salt
19:40 samnmax hello :-)  does anybody here know how to make http://docs.saltstack.com/en/latest/topics/cloud/config.html#pillar-configuration  work?  The paragraph on that page is minimal and I can't get it to work.
19:41 samnmax if I run "salt minion cloud.profile ubuntu-nova minion-id" all I get is "profile ubuntu-nova is not defined"
19:41 babilen What have you tried?
19:42 samnmax I've replicated my /etc/salt/cloud.*.d/* files into a pillar file just as described on that page.
19:42 samnmax with different provider and profile names, of course
19:43 manfred samnmax:  did you have the novaclient or libcloud installed on the minion?
19:44 manfred samnmax: I actually wrote the code to implement that, the best way to troubleshoot it is run with salt-call -l debug <stuff> while logged into the minion
19:45 samnmax the master is it's own minion
19:45 manfred https://github.com/saltstack/salt/blob/develop/salt/cloud/__init__.py#L175-187
19:45 manfred ahh, so just run salt-call -l debug cloud.profile ubuntu-nova minion-id
19:46 samnmax ok, thanks...
19:46 debian112 joined #salt
19:47 manfred if you sanatize your pillars, and paste it to gist or something, I can take a look
19:47 samnmax huh it works through salt-call
19:47 Guest70 joined #salt
19:47 manfred it is very possible that your pillars just hadn't synced yet
19:48 manfred salt \* saltutil.refresh_pillar
19:48 manfred should get them to refresh for the minion if you have just saved the file
19:48 manfred otherwise, it only refreshes every minute iirc. or by default
19:49 manfred or whenever the event is in the event bus… i don't remember
19:51 Vynce joined #salt
19:51 Vynce1 joined #salt
19:52 Vynce joined #salt
19:52 samnmax my /srv/pillar/cloud.sls: https://gist.github.com/pliniker/c157c42918e3112978a4
19:53 manfred does it work with regular salt minion cloud.profile ubuntu <name> now?
19:53 samnmax well, I guess refresh_pillar fixed it.  I'd thought sync_all included refresh_pillar
19:53 solidsnack joined #salt
19:53 manfred i think sync is for syncing the _modules or _grains stuff
19:54 samnmax thanks for your help!
19:54 murrdoc joined #salt
19:54 manfred yeah, looks like it doesn't touch pillars
19:55 manfred https://github.com/saltstack/salt/blob/develop/salt/modules/saltutil.py#L434-440
19:55 manfred and refresh_modules doesn't touch pillars either https://github.com/saltstack/salt/blob/develop/salt/modules/saltutil.py#L466-494
19:55 samnmax good to know.
19:58 wolfpackmars2 joined #salt
19:58 monkey66 left #salt
20:04 otter768 joined #salt
20:05 solidsnack What is the right way to approach this use case: "When users push code to a branch in a GitHub repository, Salt should cause the code to be deployed."
20:06 solidsnack Should one use Reactor? SDB? Is there a way to have Salt check on things intermittently?
20:08 bhosmer joined #salt
20:08 Ryan_Lane tmclaugh[work]: hey did you know that the ASG can manage its own LC?
20:08 Ryan_Lane was looking through your repo
20:09 manfred solidsnack:  git webhooks + salt-api/webhook + reactor
20:09 manfred solidsnack:  https://github.com/gtmanfred/blog-sls
20:09 manfred solidsnack:  https://github.com/gtmanfred/blog-sls/blob/master/reactor/blog.gtmanfred.com.sls#L1
20:09 tmclaugh[work] Ryan_Lane: did not realize that.
20:10 manfred solidsnack:  http://salt-api.readthedocs.org/en/latest/ref/netapis/all/saltapi.netapi.rest_cherrypy.html#saltapi.netapi.rest_cherrypy.app.Webhook
20:10 und1sk0 iggy: yesterday you mentioned that salt revs <= 2014.1.10 had "disappearing minion" bugs, that current stable fixes most and as far as you know 2015.2.0 fixes them all, correct?
20:10 Ryan_Lane it'll create the LC and will keep it up to date if you make changes
20:10 StDiluted joined #salt
20:10 Ryan_Lane (really it creates a new LC, associates it with the ASG, then deletes the old one)
20:10 tmclaugh[work] I’m looking for a better of managing the LC so that you don’t need to bump lc_version
20:10 manfred solidsnack:  sorry, this is the more recent link for webhook http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html#salt.netapi.rest_cherrypy.app.Webhook
20:10 Ryan_Lane which means you still need to terminate-roll your nodes in the ASG for it to apply, but it at least handles the LC versioning :)
20:11 druonysuse joined #salt
20:11 druonysuse joined #salt
20:11 tmclaugh[work] We haven’t gotten to figuring out how to roll out old hosts after an LC/ASG change
20:11 Ryan_Lane btw, a fun way to terminate roll the hosts is to detact the current instances
20:11 Ryan_Lane the ASG will create a new set of nodes in the ASG
20:12 Ryan_Lane once they're good, delete the detacted nodes
20:12 Ryan_Lane temporarily you'll have 2x the number of nodes
20:12 tmclaugh[work] I actually need to do something like that in the next day or two.  I need to replace my twemproxy hosts
20:13 Ryan_Lane we rolled basically every node we have in 1-2 days using that method
20:14 tmclaugh[work] I brought that up here but they said they were not ready for that.  Other things to handle first
20:14 tmclaugh[work] How do I have the ASG manage the LC?
20:14 tmclaugh[work] just brought up my work tree.
20:14 Ryan_Lane tmclaugh[work]: see this post: http://ryandlane.com/blog/2015/04/02/saltconf15-masterless-saltstack-at-scale-talk-and-slides/
20:14 Ryan_Lane specifically the slides: http://ryandlane.com/blog/wp-content/uploads/2015/04/Masterless-SaltStack-Orchestration-and-Config-Management-SaltConf.pdf
20:15 tmclaugh[work] is that you hulahooping?
20:15 Ryan_Lane hahaha. yeah
20:16 tmclaugh[work] slide 21
20:16 Ryan_Lane neat, right?
20:16 tmclaugh[work] much easier
20:16 Ryan_Lane just wait till you can see what you can do with cloudwatch alarms
20:16 Ryan_Lane and autoscale policies
20:17 tmclaugh[work] btw, noticed that everytime I run the SG formula it reapplies and Salt indicates a changed state
20:17 Ryan_Lane hm. via the code in your repo?
20:17 tmclaugh[work] yeah
20:17 Ryan_Lane that's a bug, or a poorly formatted rule (which should get caught by the state)
20:18 Ryan_Lane this is for all secgroups?
20:18 beneggett joined #salt
20:18 furball365 joined #salt
20:19 blacked joined #salt
20:19 chiui joined #salt
20:19 Ryan_Lane your rules look fine...
20:19 spookah joined #salt
20:19 tmclaugh[work] give me a sec, going to try sutff out now
20:20 aquassaut joined #salt
20:20 Ryan_Lane I wonder if it's an issue with pillar injection
20:20 Ryan_Lane a rules_from_pillars argument would be nice
20:20 Ryan_Lane like we have for IAM and some other places
20:22 I3olle joined #salt
20:22 Ryan_Lane tmclaugh[work]: I think I see your problem
20:23 Ryan_Lane I'm not sure you can inject the pillars that way
20:24 tmclaugh[work] I think before I moved rules to pillars I had the same issue
20:24 Ryan_Lane tmclaugh[work]: which version of salt are you using?
20:24 Ryan_Lane we may be using a secgroup module that has fixes only in 2015.2
20:24 tmclaugh[work] [tom@tomcat-jana jana-salt]$ salt --version
20:24 tmclaugh[work] salt 2014.7.4 (Helium)
20:24 tmclaugh[work] upgrade time
20:24 Ryan_Lane tmclaugh[work]: we override our boto modules in our own repos
20:25 Ryan_Lane so that we can run newer versions. we try to ensure they're backwards compatible, even in dev
20:26 Ryan_Lane we're also using 2014.7, but we store the modules in our own repo and override the ones in core
20:27 bhosmer joined #salt
20:31 baweaver joined #salt
20:33 cmcmacken joined #salt
20:34 tmclaugh[work] Ryan_Lane: Interesting idea down the road but not ready for that just yet
20:34 blacked joined #salt
20:35 solidsnack joined #salt
20:39 viq joined #salt
20:40 tmclaugh[work] Ryan_Lane: thanks for the LC tip.  Just updated and folks will be happy about that
20:43 Guest89 joined #salt
20:43 blacked joined #salt
20:46 solidsnack joined #salt
20:48 Tyrm joined #salt
20:49 murrdoc joined #salt
20:55 bhosmer joined #salt
20:56 hal58th joined #salt
20:57 hal58th__ joined #salt
21:00 monkey66 joined #salt
21:03 bemehow joined #salt
21:10 walker_ joined #salt
21:15 scbunn joined #salt
21:16 pravka joined #salt
21:18 blacked joined #salt
21:19 bhosmer__ joined #salt
21:21 giantlock joined #salt
21:22 benegget_ joined #salt
21:23 Vynce joined #salt
21:24 iggy und1sk0: I never tried 2014.7 personally, but it should have some fixes... we went from 2014.1 -> 2015.2 directly and all of our minions communication problems are gone
21:26 iggy vexati0n: my suggestion was to make sure you don't have keys for minions that don't exist...did you do that?
21:26 blacked joined #salt
21:28 ajw0100 joined #salt
21:30 bluenemo joined #salt
21:41 spookah joined #salt
21:43 speedlight joined #salt
21:46 baweaver joined #salt
21:48 relidy basepi: "We are please[d] to announce the 2014.7.5 release of Salt!"
21:49 speedlight joined #salt
21:49 speedlight joined #salt
21:49 basepi =)
21:49 * relidy snickers quietly in the corner.
21:49 Topic for #salt is now Welcome to #salt | 2014.7.5 is the latest | Please use https://gist.github.com for code, don't paste directly into the channel | Please be patient when asking questions as we are volunteers and may not have immediate answers | Channel logs are available at http://irclog.perlgeek.de/salt/
21:49 basepi Hate those dang typos
21:49 relidy Always happens on the ones that go to a lot of people, too.
21:51 iggy so about that 2015.2...
21:51 SpeedFuse joined #salt
21:51 basepi iggy: SOON
21:51 basepi ;)
21:52 basepi Seriously, though, it should be really soon. =)
21:53 iggy fwiw, aside from the cmd.run surprise, it's been running quite well here (in production for almost a month)
21:53 druonysuse joined #salt
21:55 refnode joined #salt
21:55 refnode hi all
21:56 refnode just saw in the code of state.file.copy that it's only a copy for local files
21:57 solidsnack joined #salt
21:57 refnode what's the best way for just a one time copy of an external url? file.managed is a problem because my source file changes over time
21:58 iggy you're trying to avoid setting a hash?
21:59 refnode iggy, no I just like to avoid to copy the source whenever the hash changes
21:59 iggy ENOPARSE
22:00 yomilk joined #salt
22:02 murrdoc joined #salt
22:03 refnode iggy, following on of your old conversations >> my question doesn't make any sense?
22:03 andrej for playing/testing I have installed anaconda in my own useraccount on the salt-master. how do I make anaconda "salt enabled", that is, get the salt api (which already exists on the master via .deb) into anaconda?
22:05 murrdoc joined #salt
22:05 otter768 joined #salt
22:05 iggy refnode: I read that as: you want to avoid copying the source whenever the hash changes
22:06 iggy which makes no sense... that's when you'd want to copy it
22:06 iggy refnode: but how about this... just use cmd.run+wget
22:07 refnode exact, I just want to copy a file once and thought to use file.copy but that doesn't work with remote files
22:07 tmclaugh[work] So I built my tree on a feature I understand is non deterministic…  That’s bad.
22:07 tmclaugh[work] http://docs.saltstack.com/en/latest/topics/pillar/index.html#pillar-namespace-merges
22:07 tmclaugh[work] “Remember: conflicting keys will be overwritten in a non-deterministic manner!"
22:07 refnode iggy, at least another option and filing a bug against file.copy
22:07 iggy file.copy isn't going to change
22:08 tmclaugh[work] I’m trying to figire out a way around that and still accomplish my goal
22:08 iggy and I doubt the salt devs are going to make it easy to download a file without some sort of hash/etc... that's asking for trouble
22:09 tmclaugh[work] I provide a set of sane default values an EC2 ASG night need but I want to be able to override them on a per service basis
22:09 refnode if there's a source attribute I think many expect that the source attribute works _equal_ on every file state
22:12 iggy then those people haven't read the docs
22:13 iggy "If the source file exists on the system, copy it to the named file."
22:13 iggy that's fairly clear
22:17 jhauser joined #salt
22:18 blacked joined #salt
22:18 speedlight joined #salt
22:18 speedlight joined #salt
22:21 murrdoc yo
22:21 murrdoc minions cant see the master
22:21 Nazca joined #salt
22:23 solidsnack murrdoc: Are there any error messages?
22:23 shaggy_surfer joined #salt
22:23 ajw0100 joined #salt
22:24 solidsnack So what kind of functions can be run in Jinja templates?
22:24 iggy solidsnack: depends... a good bit of python is available
22:25 solidsnack Like I want to have: `{% for user in local.something.get_users %} ...` and you can guess the rest.
22:25 solidsnack I really meant "What kind of module..." -- like a state module, a module module, a runner module?
22:25 iggy salt.modules.*
22:26 solidsnack Are they references that way?
22:26 iggy salt['module.function']()
22:26 solidsnack s/references/referenced/
22:26 solidsnack Got it.
22:27 echo joined #salt
22:27 tzero joined #salt
22:28 Guest89 joined #salt
22:31 yomilk joined #salt
22:40 beneggett joined #salt
22:40 jkleckner joined #salt
22:41 cberndt joined #salt
22:52 kunersdorf joined #salt
22:52 kunersdorf should I remove all salt-2014.7.2 if I want to upgrade to 2015rc2?
22:52 murrdoc joined #salt
22:56 mosen joined #salt
22:56 iggy I just installed 2015.2 without removing anything
22:57 kunersdorf curling the bootstrap then installing with -M?
22:59 Singularo joined #salt
23:02 iggy I did the minions first, but that's because I was going from 2014.1 and I didn't think they'd talk to the (much) newer master
23:03 kunersdorf does the master upgrade hammer all the minions keys it has accepted?
23:03 murrdoc nope
23:03 murrdoc only flips binaries and config files
23:04 murrdoc partly the reason why you should use the config.d directory on master and minion
23:04 iggy the only time I think you have to do anything with keys is if you switch to raet
23:04 murrdoc so apt-get upgrades go through smooth like
23:04 kunersdorf kk, ty fellas
23:06 iggy any postgres users? Anything you'd like to see added to the formula while I'm banging on it
23:06 iggy ?
23:09 johngrasty joined #salt
23:10 pipeep Does the command state's creates argument not take cwd into account?
23:10 pipeep s/command/cmd
23:13 TheNumb joined #salt
23:14 iggy I think it requires an absolute path (and doesn't take cwd into account)
23:15 bhosmer_ joined #salt
23:16 pipeep iggy, I can confirm it's what it looks like when I glance at the code
23:17 pipeep stupid salt, making me type.
23:18 scoates joined #salt
23:19 _2_ellieB joined #salt
23:19 _2_ellieB hi
23:19 iggy it kind of makes sense if you think about it... the check happens before the cmd is run (when the cwd is actually set)
23:19 iggy but yeah, could probably be made more clear in the docs
23:19 _2_ellieB I'm a female and I'm 15
23:19 iggy I'd open an issue to clarify the docs
23:20 iggy i.e. FBI agent
23:20 mosen wheres the ban hammer
23:20 kunersdorf weird, me too
23:20 mosen is 2015.2 the first release with dockerng ?
23:21 iggy mosen: it's in devel, not 2015.2
23:21 iggy (I checked... I was about to throw a fit that they keep backporting stuff instead of getting the damned thing out the door)
23:22 mosen ahh right
23:22 Ymage joined #salt
23:25 murrdoc joined #salt
23:35 theologian joined #salt
23:36 murrdoc joined #salt
23:38 dendazen joined #salt
23:47 baweaver joined #salt
23:51 druonysuse joined #salt
23:51 druonysuse joined #salt

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