Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-05-26

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

All times shown according to UTC.

Time Nick Message
00:02 murrdoc mosen:  https://github.com/saltstack-formulas/template-formula/pull/6
00:05 mosen nice
00:11 Corey MTecknology: High Wets.
00:11 Corey West*
00:17 mrbigglesworth joined #salt
00:27 dalexander joined #salt
00:32 monkey66 joined #salt
00:33 dalexander joined #salt
00:34 scoates joined #salt
00:40 iwishiwerearobot joined #salt
00:45 minaguib joined #salt
00:52 mosen joined #salt
00:54 subsignal joined #salt
00:55 MTecknology Corey: thanks! :)
00:57 Matthews_ joined #salt
01:02 mrbigglesworth joined #salt
01:03 julez joined #salt
01:07 MatthewsFace joined #salt
01:10 MaliutaLap joined #salt
01:11 MaliutaLap left #salt
01:12 tkharju joined #salt
01:17 Matthews_ joined #salt
01:23 mgw joined #salt
01:33 mrbigglesworth joined #salt
01:35 tkharju joined #salt
01:36 beauby joined #salt
01:39 modafinil left #salt
01:46 otter768 joined #salt
01:46 edrocks joined #salt
01:48 ilbot3 joined #salt
01:48 Topic for #salt is now Welcome to #salt | 2015.5.0 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/
01:51 tkharju joined #salt
01:57 litwol iggy: plz link to how to pass file.managed defaults template var /objectt/
02:02 dimeshake joined #salt
02:05 MatthewsFace joined #salt
02:08 beauby joined #salt
02:15 bash124512 joined #salt
02:24 iggy litwol: not near a computer, but context is wjat you want
02:28 evle joined #salt
02:29 iwishiwerearobot joined #salt
02:45 kermit joined #salt
02:48 beauby joined #salt
02:50 favadi joined #salt
02:55 murrdoc joined #salt
03:09 beauby joined #salt
03:19 gyre007 joined #salt
03:19 gazarsgo joined #salt
03:20 Aidin joined #salt
03:21 cberndt joined #salt
03:35 Zachary_DuBois joined #salt
03:46 otter768 joined #salt
03:48 power8ce joined #salt
03:58 TyrfingMjolnir joined #salt
04:05 iromli joined #salt
04:10 murrdoc joined #salt
04:15 mosen wb murrdoc
04:15 cheus_ joined #salt
04:16 raygunsix joined #salt
04:17 rhodgin joined #salt
04:18 iwishiwerearobot joined #salt
04:23 rhodgin joined #salt
04:32 mosen joined #salt
04:34 golodhrim|work joined #salt
04:41 julez joined #salt
04:49 ramteid joined #salt
04:49 ndrei joined #salt
04:50 noway__ joined #salt
05:00 ndrei joined #salt
05:01 markm_ joined #salt
05:05 ndrei joined #salt
05:06 mrbigglesworth joined #salt
05:13 ajw0100 joined #salt
05:16 ndrei joined #salt
05:19 dimeshake joined #salt
05:22 ndrei joined #salt
05:25 catpigger joined #salt
05:34 slav0nic joined #salt
05:35 ajw0100 joined #salt
05:41 mrbigglesworth joined #salt
05:41 malinoff joined #salt
05:43 phenelo joined #salt
05:47 otter768 joined #salt
05:51 MetaNova_ joined #salt
05:52 MetaNova_ Sorry for my ignorance, but after spending an hour or so trolling documentation and search engine results, I am unable to find a way to have salt "enforce" or "manage" states like Puppet. With Puppet, the clients check in periodically to make sure they are in the right state. How do I enable this in Salt?
05:55 phx you need that wossname module
05:55 phx which periodically runs stuff, like a highstate
05:55 phx and it's not the clients who check it, but the salt-master process issues a highstate
05:56 maat joined #salt
05:56 MetaNova_ Hmm.
05:56 MetaNova_ Do you have a link to that?
05:56 MetaNova_ A quick search didn't reveal anything helpful.
05:56 stoogenmeyer__ joined #salt
05:57 maat Folks, is there a way to for every new minion to call "state.apply" or "highstate" automatically ?
05:58 phx http://docs.saltstack.com/en/latest/topics/jobs/
05:58 phx both of you, scheduling jobs
05:59 MetaNova_ Ah, so I just set up a job that calls state.apply
05:59 phx yup
05:59 MetaNova_ At whatever time interval I choose
05:59 phx yup
05:59 MetaNova_ Easy enough, thanks for the help!
05:59 phx yw
05:59 maat Legend mate!
05:59 maat Cheers
06:03 joeto joined #salt
06:04 phx MetaNova_, just be aware, if someone applies a hotfix to some prod issue on the spot, then this will revert those changes as well
06:04 phx there are certain circumstances when a periodic state enforcement is a bad idea
06:06 iwishiwerearobot joined #salt
06:07 colttt joined #salt
06:07 mrbigglesworth joined #salt
06:10 subsignal joined #salt
06:12 MetaNova_ So adding this to my master config should work?
06:12 MetaNova_ schedule:   applystate:     function: state.apply     minutes: 30
06:12 MetaNova_ Excuse the formatting
06:15 rdas joined #salt
06:16 MetaNova_ I have to turn in for tonight, I'll check the chat log in the morning
06:16 mike25de joined #salt
06:16 flyboy joined #salt
06:23 monkey661 joined #salt
06:27 impi joined #salt
06:40 djpain joined #salt
06:45 favadi joined #salt
06:45 soren joined #salt
06:46 KermitTheFragger joined #salt
06:48 dopesong joined #salt
06:52 saffe joined #salt
06:53 TheHelmsMan joined #salt
06:55 stephanbuys joined #salt
06:56 slbo joined #salt
06:59 TheHelmsMan1 joined #salt
07:01 iwishiwerearobot joined #salt
07:02 kawa2014 joined #salt
07:02 impi joined #salt
07:06 saffe joined #salt
07:06 eseyman joined #salt
07:09 lietu joined #salt
07:12 monkey66 joined #salt
07:15 aCodinMan joined #salt
07:19 aCodinMan Hi, I have a question about salt states. Is it possible to have them re-rendered after calling the state ? I have two salt states which I would like to run together. The second one takes uses a grain set in the first one.
07:19 david_an11 joined #salt
07:20 iromli joined #salt
07:20 markm_ joined #salt
07:22 froztbyte if I wanted to gather metrics about salt highstate runs, is that a thing somewhere?
07:22 CeBe joined #salt
07:22 apergos joined #salt
07:22 froztbyte primary points I'm thinking of are, perhaps: counts of total/successes/failures, runtime
07:22 agend joined #salt
07:23 Auroch joined #salt
07:24 MatthewsFace joined #salt
07:25 mosen froztbyte: I think there's something like that.. in any case you could set up returners to go into a db
07:27 mosen or even elasticsearch it looks like
07:28 Grokzen joined #salt
07:35 froztbyte well, it's all already going back to the master
07:35 froztbyte so I can't think that setting up /more/ stuff should be strictly necessary
07:36 froztbyte I'll dig around a bit
07:36 mosen sure the job information is stored there
07:36 froztbyte I know a specific state has runtime information, and run/fail info
07:36 mosen via salt-run you can list and lookup job results
07:36 froztbyte so it should probably be possible
07:36 mosen im not sure how you will collate the information
07:36 froztbyte mosen: I'd much prefer something that can just consume a constant datastream :)
07:37 froztbyte streaming >> commandruns
07:37 froztbyte maybe this means some elbow grease is required, we'll see
07:37 mosen froztbyte: i thought maybe that the carbon returner would be ideal because then you could plug it into a time series database
07:37 mosen anyways, up to you!
07:37 mosen bbl
07:38 CeBe1 joined #salt
07:47 otter768 joined #salt
07:48 julez joined #salt
07:58 TheHelmsMan joined #salt
08:04 fredvd joined #salt
08:04 joeto1 joined #salt
08:07 Flusher joined #salt
08:08 PI-Lloyd joined #salt
08:09 iromli left #salt
08:15 linjan joined #salt
08:16 viq joined #salt
08:20 mage_ is RAET considered stable ? and is it a good idea to use it ?
08:21 julez joined #salt
08:23 N-Mi joined #salt
08:23 saffe joined #salt
08:25 coder_ joined #salt
08:25 coder_ test
08:29 s_kunk joined #salt
08:32 dkrae joined #salt
08:34 s_kunk joined #salt
08:38 froztbyte man, state extends are great
08:40 yawniek joined #salt
08:43 jhauser joined #salt
08:47 c10b10 joined #salt
08:59 Hazelesque so, woop, we now have Salt in production, side by side with CFEngine 3
08:59 Hazelesque currently using the former only for remote execution and data gathering
08:59 Hazelesque but woop nonetheless
09:01 xnaveira hi, I've this custom grain in my /serv/salt/_grains directory in the salt server. if I issue a saltutil.sync_all before the highstate everything fine but if i don't i get an error saying that the grain doesn't exist??
09:04 bones050 joined #salt
09:14 refnode joined #salt
09:16 illern joined #salt
09:16 david_an111 joined #salt
09:16 stoogenmeyer_ joined #salt
09:17 mage_ what is the difference between state.sls and state.apply ?
09:18 saffe joined #salt
09:20 joeto joined #salt
09:22 keimlink joined #salt
09:22 Sweet-P joined #salt
09:26 favadi1 joined #salt
09:27 keimlink joined #salt
09:30 denys joined #salt
09:33 c10b10_ joined #salt
09:41 froztbyte mmmm, crap
09:43 froztbyte so I'm trying to write some things out as json, and it appears like the jinja json renderer is giving me invalid output
09:44 froztbyte https://gist.github.com/froztbyte/84567bc895121152f16e has a full example
09:44 aCodinMan joined #salt
09:46 elfixit joined #salt
09:48 otter768 joined #salt
09:51 CeBe1 joined #salt
09:53 lietu joined #salt
09:55 c10b10_ is there any amazon s3 state?
10:03 yawniek joined #salt
10:06 favadi joined #salt
10:07 CeBe1 joined #salt
10:19 spiksius joined #salt
10:24 froztbyte wow, this bug is really nasty
10:24 * froztbyte opens an issue
10:27 slav0nic joined #salt
10:27 slav0nic joined #salt
10:28 laax joined #salt
10:30 ksj hi, anyone got any recommendations for handling port numbers and ip tables? currently I have them in pillar, which works great for templating config files, but I want to keep track of which ports should be open on which machines (i.e. what services are running). Should I write data to pillar every time a config file gets written with an open port? or should there be an "open port on firewall" as part of the
10:30 ksj state configuring the service?
10:32 dariusjs joined #salt
10:33 ksj I would prefer to have it as a "function" in the state file - i.e. just a line that says "ensure port x is open on firewall", but I can't see how to do that
10:34 viq Hazelesque: and you intend to move from CFEngine to Salt, or will you keep both?
10:34 froztbyte ksj: I'm dropping grains for that kind of thing
10:34 Hazelesque viq: unsure.
10:35 froztbyte ksj: and then I'd have a firewall state which reads the relevant grain and iterates over it in template
10:35 zerthimon joined #salt
10:35 Hazelesque viq: personally, I think I'd like us to switch to Salt, but I've not used it "in anger" for desired-state configuration management yet.
10:36 Hazelesque and, atm I don't have the political capital to jfdi -- so I'd need to "sell" my boss on it -- but I'm working on building up the capital
10:36 froztbyte iggy: if I can maybe ambush you: https://github.com/saltstack/salt/issues/24132
10:36 Hazelesque my plan atm is to prove just how amazingly useful Salt is for remote execution, targeting/host specialization, data collection
10:37 froztbyte oh, whiteinge is on IRC
10:37 froztbyte thatch45 isn't though
10:37 froztbyte anyway, anyone else maybe: ^
10:37 froztbyte I've found a very weird bug with file.managed -contents
10:37 froztbyte Hazelesque: just phase stuff in slowly
10:38 Hazelesque and then maybe move some of our config stuff over, esp. stuff involving Python virtualenvs, or stuff that would benefit from better templating (Nginx confs etc)
10:38 froztbyte and spend some thought on how you'd solve a given problem in salt
10:38 Hazelesque froztbyte: yeah, that's far more doable
10:38 Hazelesque indeed
10:38 froztbyte so that when $x needs to be done, you already have the answer
10:38 Hazelesque yeah
10:38 giantlock joined #salt
10:38 viq Hazelesque: cool, thanks
10:39 Hazelesque froztbyte: indeed, the question right now is more /whether/ we start moving in that direction, rather than how fast -- and indeed I think moving it piecemeal is much more realistic
10:39 dariusjs im running into issues with installing windows packages using the state fiel, salt * pkg.install works though, anyone has it working with state files ?
10:39 Hazelesque viq: I saw a video of an interesting talk that Limelight Networks gave at SaltConf 15
10:39 viq Hazelesque: for purely remote execution I think mcollective could be better, I made a bit of a comparison at https://github.com/viq/mcollective-salt-vagrant
10:39 Hazelesque viq: they're migrating from a mixture of CFEngine 2(!) and Chef, to Salt.
10:39 Hazelesque viq: Salt has the advantage, for us, that we're a "Python shop"
10:40 Hazelesque so stuff being written in Python is a big win.
10:40 viq Hazelesque: and cfengine does have some interesting points going for it, like lower resource usage and still enforcing states when master is not reachable. But yeah, I do like salt
10:41 Hazelesque oh, what's the reason that salt can't enforce states when the master is unreachable?
10:41 viq Hazelesque: it doesn't cache them anywhere
10:41 Hazelesque (like I say, we're not using "states" yet -- but execution and data gathering etc is massively useful)
10:41 Hazelesque like, not having to do a box walk for simple shit saves a lot of time.
10:42 viq Hazelesque: how many machines do you have connected to salt?
10:42 Hazelesque well, it's not a huge estate, about 150 machines spread across dev/test/UK prod/US prod
10:42 Hazelesque s/machines/virtual &/
10:42 * viq nods
10:43 Hazelesque what about you?
10:43 TyrfingMjolnir joined #salt
10:43 dariusjs well it sounds like they want to have salt run as a scheduler ... its not something ive done yet
10:43 Hazelesque that's another question I meant to ask
10:43 dariusjs with a scheduler should i say
10:43 Hazelesque people running Salt and CFEngine side by side
10:43 Hazelesque do you use cf-execd to run cf-agent, or have salt kick it off?
10:44 Hazelesque because it would be nice to be able to kick off a cf-agent run manually, remotely, sometimes
10:44 viq Hazelesque: previous job ~150 total, connected to two master because internal vs external, we had some scaling issues. Currently, just my private stuff, so in single digits, but I am pushing for salt to be considered
10:45 viq Hazelesque: cmd.run ;)
10:45 Hazelesque but CFEngine's locking is a bit weird
10:45 ksj froztbyte: yeah, I was thinking about grains, but the thing is I don't want to have to manually keep track of all the ports that should be open. i.e., ideally, if I change a "role" grain on one machine to make it a memcached instance, when the memcached state runs, it should make sure the correct port is open, rather than having a separate "iptables" state
10:45 Hazelesque viq: yes, I know about cmd.run :P
10:45 Hazelesque my point is that, currenty
10:45 Hazelesque we have to stop cf-execd, wait for any running cf-agent to quit, then run "cf-agent -K" manually (the -K skips "locking")
10:45 Hazelesque their concept of locking is, as far as I can tell, batshit.
10:45 Hazelesque s/their/CFEngine's/
10:46 viq CFEngine is being used here, but I don't know nearly enough about it to comment
10:47 Hazelesque it does per-promise locking, and so if you accidentally run two cf-agent instances at once, then you can end up, say, running the "second half" of your policy side by side with the "first half"
10:47 Hazelesque in theory, you can fix that with dependencies
10:47 Hazelesque but
10:47 ksj I'm not explaining myself well. basically, we don't use any standard ports, and we have a LOT of different ports that should be open depending on three things - the "role" of the machine (i.e. services running), the venture (we have different sites) and the environment (live, staging etc). depending on the venture and the environment, the portnumber for a memcached instance will be different
10:47 Hazelesque if you're using "single file copy" magic in CFengine, then like 90% of your files promises will (deliberately) fail
10:48 Hazelesque which makes the dependency, and compliance percentages, basically useless
10:49 ksj so at the minute, in e.g. the memcached state, I collate the correct port number to listen on based on pillar data for venture, environment and service. I'd therefore like to somehow store that data so we know what ports are open, and an iptables/pf state could just go through and open up what's necessary
10:49 viq ksj: you could assign grains based on other grains, and/or keep jinja maps and assign variables based on "Stuff"
10:49 viq ooh, pf *smells BSD* :D
10:50 ksj viq: I've run into bugs with pushing grains already
10:50 lietu joined #salt
10:50 viq ksj: oh?
10:51 ksj and yeah, we're not using pf at the minute, but I'm gently hinting to people how superior bsd is....so hopefully we'll move some things at some point
10:51 dariusjs anyone windowsy on? are you able to do a pkg.installed in state files for windows hosts?
10:51 ksj viq: yeah, I filed a bug report. I thi9nk it's been fixed now
10:51 ksj but not in the current debian (ugh) version
10:51 ksj and no, we're not allowed to run from git....
10:52 ksj I might have a look and see if mine can do it
10:53 julez joined #salt
10:53 viq ksj: out of curiousity, which BSD?
10:54 ksj viq: I use openbsd exclusively personally, but I'd be happy to learn freebsd
10:54 viq :D
10:54 ksj linux is broken. hopelessly broken
10:55 losh joined #salt
10:56 viq I prefer OpenBSD too, though linux does allow me to do more in places
10:57 MatthewsFace joined #salt
10:57 Hazelesque but, yeah, uh
10:57 Hazelesque anyone used salt-syndic in anger for a non-trivial deployment size?
10:57 Hazelesque experiences? good? bad? ugly?
10:58 KoFFiE ksj: that's a pretty harsh statement? ^^
10:58 Hazelesque ksj: does Netcraft confirm it? :P
10:58 ksj viq: yeah, unfortunately linux is unavoidable, but working with it when you're used to the saneness of bsd is painful
10:59 ksj didn't mean to start a flamewar.....way too many of them going on
10:59 KoFFiE not that I'm a fan of the direction linux is going (more specifically, systemd)
10:59 Hazelesque KoFFiE: yeah
10:59 Hazelesque someone should port Solaris' SMF to linux... ;)
10:59 * Hazelesque hides
10:59 ksj KoFFiE: I wasn't even thinking of systemd. more dbus and udev. systemd actually works pretty well compared to them
11:00 viq Hazelesque: tricky, as you don't get responces reliably, and both syndic and master need access to states, but I played a bit with it (well, evaluated to get a feel for it)
11:00 bluenemo joined #salt
11:00 bluenemo joined #salt
11:00 KoFFiE well systemd and dbus/udev are pretty much the same these days
11:00 viq ksj: I'm quite happy with archlinux ;)
11:00 ksj viq: I'm an arch guy too
11:00 impi joined #salt
11:00 viq :b
11:01 ksj but still....it's painful compared to openbsd. I can't tell you how many hours I've wasted trying to get basic networking to work
11:02 ksj the arch wiki makes my eyes bleed. in openbsd, I just read the ifconfig man page carefully, and bam, I could configure any network interface.
11:03 KoFFiE well, *bsd cli interfaces tend to be clearer/more human friendly in general
11:03 KoFFiE from what I've seen at least
11:04 KoFFiE been a long time since I toyed with bsd stuff (except for pfsense - but that doesn't really count in my book)
11:04 ksj KoFFiE: yep. they're carefully designed and most importantly, well documented
11:05 ksj give openbsd a go. the learning curve is steep, but you can learn everything you need from manuals
11:05 viq ksj: out of curiousity, what do you do with OpenBSD?
11:05 ksj I learned it by setting up an alix box as a router
11:05 ksj viq: desktop (multiple), router, fileserver, network music player
11:06 evle joined #salt
11:06 viq ksj: also, with PF - maybe per-service anchor files would be an idea?
11:06 ksj what do you mean?
11:07 mage_ what's the best practice to use python modules in a jinja/sls template (like os.path.join for example) ?
11:07 pelzi__ yes, configuring networking in linux is a royal pain
11:07 viq As part of service you could have a ready file with PF config, and depending on env etc you'd include a different path to the source file. On host, put them in a dir, and include all of them into PF
11:08 mage_ you can use anchor in pf too
11:09 ksj viq: oh, you're talking about in salt? yeah, that would work well.
11:09 Hazelesque viq: ah, hm (re: syndic flakiness)
11:09 ksj but alas....we're not using pf
11:10 ksj I do dearly wish someone would write a pf to iptables/nftables conversion tool
11:10 Hazelesque btw
11:10 Hazelesque another question
11:10 Hazelesque with CFEngine, we use "classes" to specialise hosts
11:11 Hazelesque and I've been moving some of that magic from CFEngine policy into a python script that speaks "cfengine module protocol" -- allowing it to set cfengine classes and variables and stuff, from within the python script
11:11 bastiaan joined #salt
11:12 KoFFiE ksj: installing some bsd has been on my 'I should try this again' list for a couple of years... just have to find the time
11:12 mage_ FreeBSD is an awesome OS
11:12 Hazelesque if I want to do something similar with salt (ideally from the same data source), particularly to allow targeting remote execution, should I be using custom grains, syndic, or something else?
11:13 Hazelesque er
11:13 mage_ Hazelesque: can't you use a role ?
11:13 Hazelesque custom grains, **pillars**, or something else?
11:13 Hazelesque mage_: are "roles" a first class concept in Salt?
11:13 ksj KoFFiE: get a copy of michael lucas book and dive in. it's refreshing how everything works
11:13 mage_ no, it's in the minion config
11:13 Hazelesque mage_: afaict, they're just conveniently-named grains?
11:14 mage_ Hazelesque: yep
11:14 Hazelesque at the moment, we extract stuff from the hostname + some rules
11:14 Hazelesque like, raxlon-frankspies-testapp001 would be a "franks pies" app server, in the test environment, in rackspace LON region
11:15 Hazelesque (*N.B. frankspies is not a real client name)
11:15 mage_ you can use whatever you want in fact
11:16 Hazelesque ideally, I'd like these to be cached locally but pulled from some kind of central metadata server
11:16 supersheep joined #salt
11:17 Hazelesque so, idk, maybe a local file containing a list of them -- initially dropped on the server using cloud-init or something, and then pulled down from pillars -- and then something that injects them into salt grains and cfengine classes?
11:18 Hazelesque or is that way overcomplicating it? I just want to be able to control them (and change them at short notice!) from a centralised, authoritative source
11:19 viq ksj: kinda maybe fwbuilder?
11:25 bougie joined #salt
11:25 bougie hi
11:26 bougie we can't use merge keyword on salt['pillar.get'] if we are using salt-ssh ?
11:26 bougie TypeError: get() got an unexpected keyword argument 'merge'
11:26 bougie {% set rawmap = salt['pillar.get']('unbound', rawmap, merge=True) %}    <======================
11:27 bones050 joined #salt
11:28 refnode joined #salt
11:29 rhodgin joined #salt
11:29 donmichelangelo joined #salt
11:30 bones050_ joined #salt
11:33 gfa joined #salt
11:33 nyx_ joined #salt
11:34 bones050 joined #salt
11:34 monkey66 joined #salt
11:37 CeBe1 joined #salt
11:37 gfa joined #salt
11:38 gfa joined #salt
11:40 jpaetzel joined #salt
11:40 saifi joined #salt
11:45 julez joined #salt
11:49 otter768 joined #salt
11:53 froztbyte ksj: the way I see it, either you leak firewall abstraction (and redo a lot of work all over) into your various states, or you make them export resources (grains, in this case) which one "collector" state can just run over and deal with
11:53 mdupont joined #salt
11:53 froztbyte ksj: I agonized over this quite a bit for my sensu stuff (quite a similar usecase), and just have that one collector state (possibly `iptables` applied to all machines?) works fantastically
11:55 Berty_ joined #salt
12:03 impi joined #salt
12:19 julez joined #salt
12:22 Nazca joined #salt
12:28 huddy joined #salt
12:33 otter768 joined #salt
12:34 denys joined #salt
12:38 murrdoc joined #salt
12:39 murrdoc babilen:  ifixed it https://github.com/saltstack-formulas/template-formula/pull/6
12:43 glyf joined #salt
12:44 iggy froztbyte: no idea
12:44 hasues joined #salt
12:44 bougie it seems that salt-ssh is not very production ready...
12:44 hasues left #salt
12:44 froztbyte iggy: :(
12:44 iggy bougie: what version?
12:44 bougie 2014.7.5
12:45 TyrfingMjolnir joined #salt
12:45 bougie installed via pkg on a freebsd 10.1
12:45 Aidin joined #salt
12:46 iggy well, I know some people have had issues with 2014.7.5, did you try 2014.7.6?
12:47 glyf joined #salt
12:47 babilen murrdoc: ta!
12:48 dariusjs I think I've figured out my winrepo issue https://github.com/saltstack/salt/issues/24134
12:49 tkharju joined #salt
12:49 bougie ok, I don't understand why I was in 2014.7.5...
12:50 bougie an upgrade to 2015.5.1 via pkg and it works
12:50 iggy mage_: state.apply is new, and I wouldn't use raet unless you have a good reason to (yet)
12:50 bougie thanks for the idea iggy !
12:52 julez joined #salt
12:53 iggy bougie: yeah, salt is still moving a pretty impressive rate, it's best to stay up to date for now (or use SSE which I think moves a bit slower)
12:53 yuhl_work___ joined #salt
12:53 jespada joined #salt
12:57 subsignal joined #salt
12:57 vstoniest joined #salt
13:00 jeremyr joined #salt
13:00 _mel_ joined #salt
13:00 subsigna_ joined #salt
13:01 Aidin joined #salt
13:01 bhosmer joined #salt
13:02 jeanneret joined #salt
13:04 jeanneret Hi I'm not sure that I have all understand but I want to put an intermediate server in a client. Is that right its syndic for that usage? And on my router I need open the 4505 and 4506?
13:04 ndrei joined #salt
13:05 ralphr joined #salt
13:06 Aidin joined #salt
13:07 Berty__ joined #salt
13:07 c10 joined #salt
13:08 racooper joined #salt
13:08 yawniek joined #salt
13:11 murrdoc joined #salt
13:12 amcorreia joined #salt
13:13 rdutch joined #salt
13:13 Twiglet Is there a way to get salt to error out if the pillar you're calling does not exist?
13:13 Twiglet Not a big fan of the essentially silet failures
13:14 bhosmer joined #salt
13:14 murrdoc check for it in a state file
13:15 murrdoc and use the 'test' states to error out with a failhard
13:15 Twiglet Ah I guess that would work
13:15 Twiglet didn't think of that, cheers
13:15 linjan joined #salt
13:16 jdesilet joined #salt
13:20 primechuck joined #salt
13:22 viq jeanneret: yes, but be aware, that if you want to use states then the syndic needs to have access to them as well
13:22 iggy a render error always fails too
13:23 viq Either via a local copy, or via access to same git repo
13:23 Tecnico1931 joined #salt
13:23 iggy but check + test.* is probably better
13:25 primechuck joined #salt
13:27 lietu- joined #salt
13:28 permalac joined #salt
13:28 pf_moore joined #salt
13:29 litwol iggy: ty. i simply replaced "defaults" with "context" and it "just worked"
13:29 litwol iggy: i still struggle finding in documentation where this fine distinction is stated.
13:30 litwol iggy: could you point me to the text? i'm bothered by just not seeing the /meaning/ communicated to me from the docs
13:30 litwol I used this as my example: https://gist.github.com/renoirb/7272880
13:30 iggy I don't know
13:30 iggy never used defaults
13:30 litwol the only thing that /hinted/ i should try this is passing "args" into context.
13:31 litwol i assumed "args" means multiple arguments.. ie non flat single valued variable.
13:31 iggy I honestly don't generally pass context, I put all that stuff in map.jinja and import that directly into my templates
13:32 mpanetta joined #salt
13:32 * litwol nods.
13:32 litwol that's the most common example i see
13:33 iggy I honestly hate having to backtrack through 5 different files to find where something is being set
13:33 litwol in my case i have a pillar which describes hosted sites. i loop over that list and pass /client/ and /site/ objects into the template.
13:33 mrbigglesworth joined #salt
13:33 litwol which is to say, my state which owns the template doesn't know which client&site combo to render, has no logic to fetch the correct info.
13:33 zer0def quick question - is there a way to define a state which would choose a random host from a list to execute a particular state?
13:34 zer0def in this case, it's an op on a shared resource that should be done just one
13:34 zer0def s/just one/just once/
13:36 litwol zer0def: not sure how to do that /inside a state/. but you could certainly do that from command line.
13:36 emaninpa joined #salt
13:36 litwol zer0def: salt-run manage.status gives you all hosts which are up and running.
13:36 primechuck Anyone else have issues on 2015.5.0 with highstate not refreshing grains?
13:36 litwol zer0def: you can then use awk&grep and sort -r to get yourself single hostname from all
13:37 litwol zer0def: then pass that hostname to further salt '[your host]' execution.
13:37 zer0def litwol: that i do know, just was looking for something within salt
13:37 murrdoc zer0def: touch a file on the shared resource
13:37 dyasny joined #salt
13:37 murrdoc when the state is successful
13:37 zer0def murrdoc: and when the shared resource is a database?
13:37 murrdoc and then check for it before running the state
13:37 iggy that wouldn't work
13:37 murrdoc make a simple two column, one row db
13:37 murrdoc acquire lock, do work, remove lock
13:38 murrdoc if hte state cant acquire lock … move on
13:38 viq or etcd, or consul, or....
13:38 elfixit joined #salt
13:38 murrdoc etcd dunno
13:38 murrdoc consul has the concept of 'locked resource'
13:38 iggy all hosts will try to run the state at once, you'd have to do the "acquire lock" _before_ you started the state
13:38 murrdoc thats what i said
13:38 mage_ any idea how could I execute a pip install -U pip after creating a virtualenv with the virtualenv state ?
13:39 mage_ ... but before processing the requirements file
13:39 iggy you said when it was successful
13:39 litwol zer0def: you could find a way to fetch list of connected hosts from a state... or you can just create static hosts list somewhere...
13:39 faliarin joined #salt
13:39 litwol zer0def: use that list inside jinja template (you can do that even inside top.sls) to fetch one hosts.
13:39 cpowell joined #salt
13:40 litwol zer0def: then build your top.sls with "base:\n\t'[single host]':\n\t\t...."
13:40 litwol just made that up
13:40 zer0def litwol: i think murrdoc's solution is cleaner
13:40 litwol not sure if will work.
13:40 murrdoc but it will
13:40 murrdoc it is known
13:40 murrdoc #notssceapprovedatall
13:40 murrdoc :)
13:40 murrdoc brb
13:40 zer0def :)
13:41 _mel_ joined #salt
13:41 litwol a little mind dump:
13:41 cpowell joined #salt
13:42 litwol right now i am looking to find a pattern where flow of information is bi-directional
13:42 litwol for example
13:42 litwol top.sls imports a formula/state which gets data from a pillar
13:42 litwol flow of info here is pillar -> state
13:43 litwol then the state loops over pillar and dynamically loads additional formulas/states based on what is defined in the pillar
13:44 rhodgin joined #salt
13:44 saffe joined #salt
13:44 litwol now the flow is 1pillar -> (2state -> (3state))
13:44 jhauser joined #salt
13:44 jespada joined #salt
13:44 somebody joined #salt
13:44 litwol making one formula proxy information for another state.
13:45 litwol and as iggy mentioned it may become very complicated to figure out where information/variables are being set if this chain of proxies grows more
13:45 lothiraldan joined #salt
13:47 SneakyPh1l joined #salt
13:47 SneakyPh1l I'm having an issue with trying to run `salt-key --list all`. I get "data failed to compile"
13:48 litwol SneakyPh1l: i've had similar issue. resolved by restarting minions
13:49 litwol salt \* service.restart salt-minion
13:49 julez joined #salt
13:50 iggy salt-key doesn't talk to the minion, I don't think it talks to the master either
13:50 iggy I'd guess something bad in the master config file
13:51 mgw joined #salt
13:52 ksj in the state topfile, is it possible to run states with set variables? that is, I'd like to run the same state file multiple times, but looping over a list of grains and modifying a variable each time
13:52 rdutch Maybe you typed it right ion the CLI, but it should be salt-key -L or salt-key —list-all
13:53 litwol good to know
13:54 bhosmer joined #salt
13:55 SneakyPh1l litwol: restarted the minions and I get the same thing. rdutch: it's salt-key --list-all for my version of salt. iggy: I'm using the same master config as I always have been but this just popped up
13:57 lietu joined #salt
13:58 litwol sry i dont know much more. my info is anecdotal. i ran into this problem when updating salt minion to new 2015 version while master remained 2014
13:58 litwol that was a mistake..
13:58 litwol perhaps not "this problem", but similar with compile errors
13:59 lothiraldan joined #salt
14:00 djpain joined #salt
14:01 mapu joined #salt
14:04 andrew_v joined #salt
14:04 rdutch As far as I know it is best practice to update master 1st before updating minions
14:05 SneakyPh1l correct, that is what I had done
14:09 jasonkeene joined #salt
14:10 jasonkeene are there any best practicies for automating accepting minion keys?
14:10 rvankleeck joined #salt
14:10 rvankleeck question regarding urllib3
14:11 rvankleeck I have urllib3 1.9 installed via pip, and when I installed the minion, it installed urllib3-1.5-7 via rpm
14:11 rvankleeck if I remove the RPM, will the minion still work?
14:11 rvankleeck or is there something I need to do to make it use the pip version?
14:12 rdutch jasonkeene: I would look at reactor for that, where you could define one which will accept the key based on certain conditions
14:12 iggy rvankleeck: should, but your pkg manager will probably just reinstall it
14:13 rvankleeck iggy, thanks. I'll look into adding it to excludes somewhere
14:14 litwol jasonkeene: yes
14:14 litwol jasonkeene: you can /pre-accept/ keys.
14:14 litwol generate keys. add them into minions before deployment. add them on master with the same name as minion host
14:14 litwol that's the solution i've come across on google.
14:15 babilen Or automatically accept them (either unchecked or with a reactor as explained -- http://docs.saltstack.com/en/latest/ref/configuration/master.html#auto-accept + http://docs.saltstack.com/en/latest/topics/reactor/#a-complete-example )
14:16 babilen jasonkeene: ^
14:16 ksj anyone? the reason for wanting to set variables in the top file is that I need the same variable spread throughout lots of files, but I can't use pillar because the variables need to be dynamically generated.
14:16 babilen ksj: The top file simply targets SLS files / state collections to minions. Everything else should happen in there (your looping for example)
14:17 litwol auto accept sounds dangerous. even for behind firewall designs. what if business reuqirement changes and your behind-firewall minion now gets to live outside firewall... or you have to launch new minions outside firewall..
14:17 babilen And AFAIK there is no way to do what you want to do
14:17 litwol deploying pre-accepted keys sounds more secure than auto accepting keys.
14:17 babilen litwol: There surely are security implications, but that doesn't mean that it is not a perfect solution for some setups.
14:18 babilen People have to decide what is most appropriate for them
14:18 jasonkeene I was going to have the keys generated/added beforehand because that makes sense to me but i’ll read up on the reactor thing as well.. thanks!
14:18 ksj babilen: thanks. a little disappointing though :-(
14:21 murrdoc joined #salt
14:22 ksj so if you wanted to set a variable that changed depending on grains, and that would be used in a state file, as well as in multiple jinja templates, you would write the whole for "grain in grains['blah']" loop out in each file?
14:23 litwol ksj: have you come across salt formulas with file inside them named 'map.jinja' ?
14:24 ksj litwol: ...yeah...it's scary
14:24 ksj I neve got my head around jinja maps
14:24 ksj maybe it's time...
14:24 litwol https://github.com/saltstack-formulas/salt-formula/blob/master/salt/map.jinja
14:25 murrdoc its tooooo complex
14:25 litwol it basically does hwat you are asking. have a default value.. or override it based on grains or pillars.
14:25 litwol it is not complex at all. don't ruin your own expectation.
14:26 litwol typically map.jinja sets up dictionaries of values based on grain['os']
14:26 litwol you can do the same with just about any other grain.
14:26 murrdoc let me clarify
14:26 murrdoc https://github.com/saltstack-formulas/salt-formula/blob/master/salt/map.jinja is more complex
14:26 murrdoc then
14:26 murrdoc https://github.com/saltstack-formulas/sysstat-formula/blob/master/sysstat/map.jinja + https://github.com/saltstack-formulas/sysstat-formula/blob/master/sysstat/defaults.yml
14:26 murrdoc actually i am going to upgrade that salt formula meow
14:26 litwol oh yeah
14:27 iggy how are you going to upgrade it?
14:27 litwol defaults+map is a new pattern seem to be emerging (At least i've only seen it fewer times recently than the traditional map.jinja'
14:27 murrdoc add a defaults + map
14:27 iggy it has a defaults.yaml
14:28 murrdoc k then i ll clean the map
14:28 murrdoc cos its unnecessary
14:28 iggy I tried to do the os_map too, but people kept adding shit to it
14:28 mohae joined #salt
14:28 murrdoc u are a nice guy
14:28 murrdoc its your one true failing
14:29 litwol lol
14:29 * murrdoc whips out cleaver
14:29 iggy I hear that all the time
14:29 litwol plz don't change :)
14:30 s_kunk joined #salt
14:30 s_kunk joined #salt
14:31 Tyrm joined #salt
14:32 Berty_ joined #salt
14:33 ponpanderer joined #salt
14:33 ponpanderer hello
14:34 murrdoc https://github.com/saltstack-formulas/salt-formula/blob/master/salt/map.jinja#L71
14:34 mage_ is it possible in salt to do a "if fail then ... then re-execute" ..?
14:34 murrdoc pillar here is salt ?
14:34 murrdoc not salt:lookup ?
14:34 ponpanderer for bug fix contributions what's the oldest supported branch at this point in time....2014.1?
14:34 murrdoc mage_:  google saltstack requisites, and check out unless on the page
14:34 mage_ thanks
14:34 otter768 joined #salt
14:36 TheHelmsMan joined #salt
14:36 litwol murrdoc: line 67 calls for salt:lookup. 71 for just 'salt'
14:37 litwol looks to me like salt:lookup is meant to override the distro_map, while 'salt' is meant to override what's in defaults.yaml
14:37 amcorreia joined #salt
14:38 murrdoc thats stupid
14:38 * murrdoc is salty today
14:39 murrdoc but good point
14:39 murrdoc i ll fix my pull
14:40 litwol i think it is ... umm... too complex having to deal with different data-sources
14:40 litwol having everything under single 'salt' is better
14:40 iwishiwerearobot joined #salt
14:40 litwol even if 'salt:lookup' vs 'salt:defaults' or w/e
14:40 murrdoc but changing that would mean need to update all formulas
14:40 murrdoc consistency and all that
14:40 litwol where's your cleaver now?
14:40 * murrdoc whips out duct tape
14:40 litwol ;)
14:41 murrdoc its real job time
14:41 murrdoc in 15 minute
14:42 Tyrel joined #salt
14:42 _JZ_ joined #salt
14:42 murrdoc iggy:  babilen https://github.com/saltstack-formulas/salt-formula/pull/137 merge it
14:43 Tyrel1 joined #salt
14:43 murrdoc btw
14:43 murrdoc litwol:  i agree with you
14:43 iggy yeah, I originally had salt (not salt:lookup)
14:44 murrdoc :lookup is unnecessary
14:44 iggy but _you_ made me change
14:44 murrdoc because every other formula had :lookup
14:44 murrdoc i am sorry
14:44 murrdoc but gotta be consistent
14:44 babilen Well, you want :lookup for changes in the os_map
14:45 murrdoc namespacing it under :lookup doesnt say that
14:45 murrdoc should have been salt:os_map if thats what the goal was
14:45 murrdoc #codeisdoc
14:46 RabidCicada joined #salt
14:46 babilen I like to differentiate between settings that are simply reflecting the defaults of a platform/distributions and those that users genuinely want to change. I like to have the former in FOO:lookup and that latter in FOO
14:46 murrdoc i am not disagreeing with that
14:47 murrdoc i am saying the namespacing is not obvious when u read the pillar
14:47 murrdoc and / or is not in the doc
14:47 murrdoc internally at work
14:47 kaptk2 joined #salt
14:47 murrdoc i have basically setup all pillars to be same as the defaults.yml
14:47 murrdoc but i dont have to deal with os's
14:47 murrdoc just trusty/precise
14:48 babilen yeah, who needs those anyway?
14:48 RabidCicada Is there a way to know all of the valid targets for a require statement?  I'm looking to know what I can "require".
14:48 RabidCicada I was hoping I could just "require
14:48 RabidCicada " an id and be done...but looks like I have to know pkg: or file: etc
14:49 babilen RabidCicada: Well, you should know which state module a particular state definition belongs to.
14:49 RabidCicada so...to require a pkgrepo be "installed"/managed.  Can I "require: pkgrepo.managed id"
14:50 RabidCicada I'm still a little fuzzy as to what can be the target of the require statement
14:50 iggy just pkgrepo: id
14:50 iggy it's <state module>: <id>
14:50 babilen It's the state modules not module.function:
14:50 RabidCicada AHHH....Thanks.
14:50 RabidCicada that clears it right up
14:51 iggy we welcome suggestions for improving the docs
14:51 iggy file a bug if you don't mind
14:51 RabidCicada hehe:)...I think I will totally recommend that clarification
14:53 karlthane joined #salt
14:54 litwol murrdoc: thx for validating my opinion. being new to salt this bears much positive value. thx.
14:54 ksj I've never seen this documented, but I just tried passing an arbitrary variable from a state file to a template, and it works. Is this intended behaviour? what I mean is, if I use this extensively, it's not going to get deprecated at some point?
14:55 riftman joined #salt
14:55 murrdoc litwol:  no problem
14:55 murrdoc when u right, u right
14:55 ksj e.g. under file.managed: I have "x: y". then in the template file, {{x}} will print {{y}}
14:55 iggy ksj: how? paste state
14:56 iggy ksj: deprecated
14:56 ksj iggy: that functionality is deprecated? I'm on 2015.5
14:57 ksj and I'm going to be sorely annoyed if it is deprecated as it is EXACTLY how I want to organise my state files
14:57 murrdoc well you can use context: x:y
14:57 peters-tx joined #salt
14:57 RabidCicada lol...this is fun to watch (variable passing in state->template)
14:57 iggy 2015.5 warns against it
14:57 murrdoc instead of just x: y
14:57 iggy what murrdoc said
14:57 gthank joined #salt
14:57 gthank joined #salt
14:57 murrdoc the context keyword makes it more readable as to what u are doing
14:57 babilen ksj: You were quite specific that you want to do that in the top.sls file
14:58 Brew joined #salt
14:58 babilen (which you can't)
14:58 ksj murrdoc: ok, I'll read up on context
14:59 babilen Or is this a different issue?
14:59 murrdoc there is not much to read up
14:59 ksj babilen: sure, I'd prefer to do it top.sls, but it will work the same in the state file - just a bit messier
14:59 murrdoc where u were doing file.managed: \n \t x : y
14:59 murrdoc now u ll do
14:59 ksj but much better than setting the variables in every config file
14:59 ksj i.e. a lot less boiler plate
14:59 babilen ksj: I am still unsure what "it" is and it is a bit hard to help you come up with sensible solutions, but knock yourself out
15:00 fxhp joined #salt
15:00 babilen I dislike relying on context as templates aren't self-exploratory anymore
15:01 dopesong_ joined #salt
15:01 raygunsix joined #salt
15:01 litwol hmm
15:02 danjj I'm still new to salt here, but wouldn't setting the variables in a pillar be the right way?
15:02 litwol i am dealing with exactly this for the past few days
15:02 jalbretsen joined #salt
15:02 litwol i would love to move my variables/objects into a pillar or equivalent but have not found a way yet
15:02 danjj I've tried to keep states as simple formulas and keep all 'data' in the pillars
15:02 litwol the problem i deal with is i feed my pillar into a state, then the state loops over it and feeds /subset of pillar info/ into another state.
15:02 danjj or in grains
15:03 litwol the state which is being fed data doesn't know where data is coming from and therefore cannot declare a template which hard-codes specific pillar.get or map.jinja include.
15:03 supersheep joined #salt
15:04 ksj babilen: this is what I'm doing, roughly:  http://dpaste.com/3WDE63X.txt
15:04 SneakyPh1l iggy: my problem did end up being the master file
15:04 danjj k. I had something which may be similar
15:04 litwol ksj: see this example. https://gist.github.com/renoirb/7272880 specifically the /context/ statement on line 9
15:05 iggy SneakyPh1l: oh? what exactly
15:05 ksj sorry, source in that should read salt://files/test
15:05 rm_jorge joined #salt
15:07 ksj so, do I have to put "venture" into a "context:" dictionary? because I really like the way it works at the minute
15:08 litwol ksj: try it.
15:08 SneakyPh1l iggy: I am not sure tbh, I removed my previous master file and moved master.rpmnew into place
15:08 ksj litwol: oh, it works fine as it is. but someone said it was deprecated functionality
15:08 litwol ksj: you will still get access to {{venture}} variable in your template. doing it through context is the current /convention/
15:09 litwol ksj: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.managed
15:09 litwol ksj: read about 'defaults' and 'context' on this doc page.
15:09 litwol tbh i dont understand the fine implication of what the text about these two declaration says..
15:10 litwol i just know when i've tried adding my custom variable (object) into context it was passed into template.
15:10 ksj context 'Overrides default context variables passed to the template.'. I don't want to override anything. I just want arbitrary variables passed from the state file
15:10 ksj maybe I should look at templating the pillar instead, but I wanted to keep my pillar pure yaml
15:10 ksj so it remains easy for others to view/edit
15:10 litwol ksj: have you /tried/ ?
15:11 ksj litwol: tried what?
15:11 litwol ksj: i'm saying you figured it out on your own 90% to success. the final 10% is putting your variable under 'context:' declaration.
15:11 litwol ksj: just indent your venture: {{venture}} 2 spaces right and put 'context:' above it.
15:12 ksj litwol: yeah, I know it works like that. I understand that, but people were saying it was deprecated behaviour....or possibly bending the rules
15:12 litwol ksj: like this http://dpaste.com/10VB4ZK
15:12 ksj and I want to keep as much within salt best practices as possible
15:12 litwol ksj: using /context/ is not deprecated. it is the standard now.
15:12 murrdoc context is best practices
15:13 litwol ksj: *not using context*, which is what you did, is the deprecated practice.
15:13 ksj ok, so, context can (and should be) used for passing arbitrary variables, right?
15:13 ksj because the docs said "overrides default context variables"
15:13 litwol ksj: to your credit the documentation is hurely cryptic about this. but yes you should be using context.
15:13 ksj so, I thought that was the intended behaviour, and I was abusing it by passing arbitrary variables
15:14 keimlink joined #salt
15:14 ksj litwol: ok, thanks
15:14 ksj that makes me feel safer about writing all my states like that
15:14 ksj sorry for not explaining myself well, this is a complex world and not all the vocabulary is that well defined
15:15 litwol hehe
15:15 * litwol nods
15:15 ksj ...what? god I'm tired. sometimes I think I sound like english isn't my native language
15:15 ksj computers have rotted my brain
15:16 litwol i'm just nodding my head agreeig that salt has taken upon itself to redefine many industry standard terminology/vocabulary and it causes confusion like you are having now.
15:16 danjj This has been enlightening for me
15:16 danjj Adding jinja logic in the pillar is how I've dealt with providing something that needed to be modified before being usable by the state.
15:16 danjj My logic was that I wanted all the variables calculated in the pillar.
15:16 danjj Is the 'salty' way to do that in the init.yml for the state and then pull it in as context instead of pulling it from a variable I set in the pillar?
15:17 murrdoc all data should be calculated anywhere but the template
15:17 * murrdoc puts down cleaver
15:17 jimklo joined #salt
15:17 lothiraldan joined #salt
15:18 danjj template should only be determining which minions get which lines of the file, right?
15:18 murrdoc mebbe ?
15:18 danjj not actually doing any determination of what the lines should be
15:18 litwol i think your question is touching on "where's the balance between your infrastructure being purely a state, and being complex dyanmic logic of calculations"
15:19 danjj I come from an infrastructure where each dev wrote their own horribly inbred puppet manifests
15:19 litwol i don't have a good answer to that :(. but i'm afraid /not/ drawing a separating line will result in an unmanageable mush down the line.
15:19 murrdoc yummy inbreds
15:19 litwol this morning i actually considered implementing my config as code in 2 tracks. track 1 is what manages my overall infrastructure. track 2 is what manages the pillars for track 1.
15:19 murrdoc danjj:  one thing you could do is have a base formula that has a base template
15:20 murrdoc and the path to that in a pillar/defaults.yml
15:20 litwol so i could keep my track 1 (main infra) as purely static-state declared.
15:20 murrdoc then various minions can override the path in their pillar
15:20 danjj what I think want is a state that acts as a function, pillars and grains that pull together the data for that function
15:20 litwol and i can keep my track 2 as purely dynamic computational thing which generates static pillars.
15:20 murrdoc if their file is different from the one that is in the base formula/template
15:20 danjj so the state essentially never changes
15:20 SneakyPh1l left #salt
15:20 bhosmer joined #salt
15:21 danjj murrdoc: yes, that works for me
15:21 murrdoc wfm too :D
15:21 danjj I want the state as clean and unchanging as possible
15:22 murrdoc danjj:  https://github.com/saltstack-formulas/template-formula
15:22 dfinn joined #salt
15:22 murrdoc its not a complete example but it shows how u can structure stuff
15:23 litwol the whole 'lookup' thing is redundant and hurely distracting
15:23 murrdoc yeah you dont need the lookup thing
15:23 murrdoc but if u have multiple os's ni your org
15:23 litwol pillars are a /lookup/ platfrm
15:23 murrdoc might help
15:23 danjj was following that this morning
15:23 litwol what you are doing is /overriding defaults/, not doing a lookup
15:23 danjj lurking here the last week or so has been very informative :)
15:23 litwol so... a much better one would be 'default_override:'
15:23 giantlock joined #salt
15:24 litwol yes iti s longer.. but it is readable and understandable without documentation.
15:24 ALLmightySPIFF joined #salt
15:24 schristensen joined #salt
15:24 danjj that is critical to me
15:24 litwol i think i'm going to use 'default_override' in my pillars.
15:25 danjj I <3 best practices, thanks guys
15:25 murrdoc better would be to use the type of grain override u are using
15:25 litwol by the way i haven't found an easy way yet to bridge state implementation pattern between binary distros and source distros (debian vs gentoo)
15:25 murrdoc for example if u are using os_map to override the defaults.yaml then have a key in your pillar called os_map
15:25 litwol binary distros customize packages based on.. yet another package install such as php5-*. source distro, gentoo, customizes based on /in package configuration/.
15:26 litwol on gentoo i install one pkg with 5 config settings, while on debian i install 5 packages each with 1 config.
15:26 litwol :-\
15:26 litwol writing state formulas for that "uniformly" is not soething i figured out yet.
15:26 babilen murrdoc: Well, you typically filter by os_family and ":lookup" was traditionally used (from "lookup table"). I would be happy if we were to finally arrive at one particular style for all formulas rather than the hodgepodge we have now.
15:27 murrdoc yeah
15:27 murrdoc :lookup is everywhere so i use it in my pulls
15:27 murrdoc the template formula is supposed to be our 'decision' formula
15:28 murrdoc so maybe u can propose the :lookup vs :bettername thing there
15:28 murrdoc i honestly thing if you are using an os
15:28 murrdoc that changes the os_map, submit that as a pull to the formula upstream
15:28 Tyrel1 Anyone know what type of tgt_types are allowed in orchestrate.  Is a "list" allowed?  I have tried a comma delimited list but it only takes action on the last minion listed..  I used tgt_type: list
15:29 TheHelmsMan joined #salt
15:30 litwol murrdoc: oh so if my map.jinja merges based on 'grain[os]' then the "lookup" would be FOO:os, same for s/os/os_family/ and s/os/whatever/
15:30 litwol ?
15:30 murrdoc yeah
15:30 litwol making the FOO:{override group} a non-fixed key
15:30 murrdoc yup
15:31 slav joined #salt
15:31 * litwol thinking
15:31 murrdoc or
15:31 murrdoc just dont use a :{override group}
15:31 murrdoc those to me are the two options
15:31 slav guys how can i run a state from a different environment ?? not base
15:31 murrdoc i see babilen's point
15:31 babilen What does that buy us? I mean a lot of people will have to change their pillar, just because you start filtering on something else
15:32 murrdoc readability man
15:32 murrdoc as u read the pillar.example its clear what is namespaced and why
15:32 Tyrel1 slav, use saltenv=diffenv
15:32 murrdoc <imho?
15:32 babilen And you filter on one thing only anyway so it is not that we really need multiple "override groups" in the pillar for now. (not that that couldn't be implemented)
15:32 litwol i'm with murrdoc on this. being new and trying to figure out how to override default values was hell when my first formula tackled was https://github.com/saltstack-formulas/mysql-formula/
15:32 murrdoc i actually have cases with two filters
15:32 Tyrel1 or just specify the different environment at the end.  Example:  salt * state.sls makechanges differentenv
15:32 murrdoc one for trusty/precise
15:32 slav llike salt '*' saltenv=differen... state.sls state?
15:33 litwol i had no idea if using mysql:lookup will modify /mysql my.cnf/ or modify the system package/service names
15:33 murrdoc one on a custom grain
15:33 murrdoc we can pick a rule for saltstack-formulas because of the number of people we support already
15:33 murrdoc but it should be ok to implement it without the :{override_var} locally
15:33 murrdoc is what i am saying
15:33 Tyrel1 I believe that syntax is swapped.   salt '*' state.sls statefile saltenv=different
15:34 babilen litwol: I'd argue that it is much harder for newcomers to understand the differences between different grain filters than "FOO:lookup" for overrides in os/package defaults and "FOO" for settings you typically want to change
15:34 slav hmm ok lemme check
15:34 conan_the_destro joined #salt
15:34 debian112 joined #salt
15:34 denys joined #salt
15:35 babilen murrdoc: I think that that would make sense if we were to implement/advocate overrides based on multiple grains, but with the "one grain only and mostly os_family at that" situation we have now it doesn't add much apart from *major* problems with backwards compatibility
15:35 murrdoc yeah
15:35 murrdoc we are stuck with :lookup
15:35 murrdoc i get that
15:36 SheetiS How does one utilize ext_pillar_first: True (new in salt 2015.5.0) properly?
15:36 litwol i will consider it a success if salt creates disambiguation between /system/ :lookup overrides and /installed package configs overrides.
15:37 babilen Not necessarily. I see your point as well, but I think that we need a more points in favour of that change before we can consider doing that. A proper way of combining different grains and overrides is one I can think of.
15:37 lothiraldan joined #salt
15:37 litwol which calls out for at least two :{lookup group} keys.
15:37 babilen litwol: Could you elaborate on that?
15:37 litwol sure
15:37 litwol i will use mysql-formula as example https://github.com/saltstack-formulas/mysql-formula
15:37 babilen ack
15:38 litwol see this https://github.com/saltstack-formulas/mysql-formula/blob/master/mysql/defaults.yaml
15:38 litwol it uses filtering based on grain[os]
15:38 babilen Arguably a lot of that should be in lookup
15:38 * murrdoc nodes
15:39 babilen (as it is platform specific and users are unlikely to change that_
15:39 SheetiS These days I feel I have to do a couple of merges in most of my map.jinja files.
15:39 babilen In particular paths such as pid_file: /var/run/mysqld/mysqld.pid and so on
15:39 litwol the confusing part about this defaults file is the combining of system defaults with pkg defaults
15:40 litwol for example server, client, service, python, debconf_utils, etc etc
15:40 babilen litwol: Yes, this particular defaults file is horrible
15:40 babilen (in that regard)
15:41 litwol well it is horrible
15:41 babilen I can understand why it is like that, but the "lookup" "non-lookup" distinction here is not properly implemented there
15:41 litwol and yet.. it must have followed some documentation/standards/help to arrive to this horridness
15:41 litwol which begs the question how can this be prevented for new formulas and made clear to newcomers
15:41 babilen It was rather born out of one particular configuration file generation pattern
15:42 smcquay joined #salt
15:42 litwol again i find it more important to figure out how to prevent fture formulas ending up like this rather than pointing finger at why this one is the way it is
15:43 babilen That pattern generates configuration files (my.cnf in this case) completely from data. That is awesome, but unfortunately the formula doesn't place data in the appropriate place and rather lumps it all together in the defaults
15:43 zer0def murrdoc: would you say that creating a table in a database as a sign that it's currently being 'locked', suffices in preventing more than a single machine from accessing it at a time?
15:44 stoogenmeyer__ joined #salt
15:44 murrdoc zer0def: yeah make a table, put a row on it, and then use the mysql 'lock transaction' thing
15:45 zer0def well, i meant postgres in this particular instance
15:45 babilen The problem is that it is a bit hard to decide sometimes what belongs in :lookup and what doesn't. My guts would place things such as paths (log files, configuration files, data directories, ...), package names and settings that are very specific to that platform (e.g. .d directories for the Debian family) in :lookup and other defaults such as, say, the bind address in defaults
15:45 babilen But people disagree on that
15:46 babilen litwol: One step forward would be, however, proper documentation that makes it clear that :lookup should be used for those platform defaults that users are unlikely to change
15:46 * litwol nods
15:46 murrdoc yeah that would be nice
15:47 murrdoc i had no clue how :lookup worked in salt-formula
15:47 babilen That would also mean that we don't have to preach it in here and on the mailing list all the time :D
15:47 murrdoc use the template-formula
15:47 murrdoc tell people to implement like so
15:48 babilen Well, we also have to work on the "conventions" and "best practices" bit of the documentation
15:48 lietu joined #salt
15:48 babilen And ":lookup" is being used "wrongly" in a number of places in the docs too
15:49 kunersdorf joined #salt
15:50 raygunsix joined #salt
15:51 dopesong joined #salt
15:51 rsimpkins left #salt
15:51 slav <Tyrel1> big thx! it worked
15:55 litwol babilen: documentation would be amazing. documenting the purpose of :lookup as it stands now is a must i think. great first step. second step should be disambiguation between system defaults and app-config defaults.
15:57 litwol babilen: one could also argue that formulas should have init.sls consist of include:\n\t - system_install\n\t - package_config\n\t - package_services
15:58 litwol babilen: that way each can define their own FOO:lookup map and be done with the confusion.
15:58 litwol that's all i have thought of on the matter.
15:58 Auroch joined #salt
15:58 * litwol withdraws
15:58 Tyrel1 Glad it worked slav.
15:59 rdutch left #salt
16:00 fxdgear joined #salt
16:00 baoboa joined #salt
16:01 slav one more question : how can I run more than one state from cmd without using highstate?
16:01 babilen litwol: I agree
16:01 murrdoc state.sls stateone,statetwo
16:02 bhosmer joined #salt
16:02 slav like salt '*' state.sls statefile1 statefile2   ??
16:02 murrdoc stateone,statetwo
16:02 slav ohh ok thx
16:03 Grokzen joined #salt
16:04 soren_ joined #salt
16:06 writtenoff joined #salt
16:06 litwol babilen: fyi in my custom formulas (non published) i am leaning towards franular split my_formula/*.sls. i find it more flexible and easier to use.
16:06 litwol what i did not do yet is begin to use individual overrides inside each sls to avoid foo:lookup cluttering
16:06 litwol will try that soon
16:07 desposo joined #salt
16:09 Edgan joined #salt
16:12 FeatherKing joined #salt
16:12 TheHelmsMan joined #salt
16:12 aparsons joined #salt
16:16 zerthimon joined #salt
16:17 kawa2014 joined #salt
16:21 VSpike I'm having some basic yaml/pillar issue here. https://bpaste.net/show/976ef2f57acc is the state. Here's the output https://bpaste.net/show/e6258c6722df .. pillar data at the bottom.
16:22 VSpike Can anyone spot what I'm doing wrong?
16:23 VSpike oh wait
16:24 mindscratch joined #salt
16:28 Tyrel1 Can someone tell me what tgt_types are allowed in an orchestrate file.  I would like to use a list, but it only seems to recognize the last minion in the list.
16:29 hal58th joined #salt
16:29 hal58th_ joined #salt
16:30 jdesilet joined #salt
16:30 MatthewsFace joined #salt
16:30 hal58th__ joined #salt
16:31 MatthewsFace joined #salt
16:31 murrdoc Tyrel1:  example code
16:31 murrdoc and also salt-version
16:32 KyleG joined #salt
16:32 KyleG joined #salt
16:33 ajw0100 joined #salt
16:33 Tyrel1 stop_source_jboss:   salt.state:     - tgt: 'minion1,minion2'     - tgt_type: lists     - sls: dc2m.stop_jboss
16:33 murrdoc gist man
16:34 Tyrel1 salt 2015.5.0 (Lithium)
16:34 jdesilet joined #salt
16:35 otter768 joined #salt
16:35 iggy I'd imagine it's just list
16:37 Tyrel1 Tried 'list' also and got the same results.
16:37 iggy http://docs.saltstack.com/en/latest/ref/states/top.html#other-ways-of-targeting-minions agrees with list
16:38 iggy check your match then... does "salt -L 'minion1,minion2' test.ping" work as expected?
16:39 felixhummel joined #salt
16:44 felixhummel I want to apply a chain of states (via require) only if a certain condition is met, i.e. only if postgres cluster locale is "de_DE" then kill the service, drop the cluster, create the cluster, start the service
16:45 cruatta joined #salt
16:46 felixhummel How would I go about this? if I say "unless: <locale is de_DE>" for service.dead, then only this is skipped, but I want none of them executed in this case.
16:46 cruatta joined #salt
16:46 iggy probably wrap the whole thing in jinja if
16:47 iggy I hate suggesting that, but it's probably the least insane way
16:47 felixhummel :D
16:48 felixhummel I completely forgot about this possibility, because I always try to avoid it.
16:48 murrdoc well u can use orchestrate instead
16:48 iggy good
16:48 murrdoc but das tricky
16:49 felixhummel so basically "{% if salt['cmd.run']("<locale is de_DE>") != 0 %}"
16:50 murrdoc {% if salt[locale.get_locale] == 'string' %}
16:51 litwol missing quotes or is this a valid syntax?
16:52 murrdoc its not valid syntax
16:52 murrdoc just saying there is a module for it, dont cmd.run
16:52 felixhummel murrdoc: thanks! orchestrate looks interesting, but I'll go with jinja for now. It's for a single box, so I try to keep it simple.
16:53 iggy it's not specifically the system locale, it's the DB locale
16:54 giantlock joined #salt
16:54 Tyrel1 iggy,  There was indeed a problem with one of the minions I was targeting and I didn't realize it.  Thank you for the assist.  :)
16:54 felixhummel I don't need "locale.get_locale", but would need "postgresql.get_cluster_locale" which does not exist (yet), so my cmd is "test $(sudo -Hnu postgres psql -Atc 'show lc_ctype') = de_DE.UTF-8"
16:55 Tyrel1 And it is the single value of "list" that works
16:55 aCodinMan joined #salt
16:56 wendall911 joined #salt
17:01 troyready joined #salt
17:02 theologian joined #salt
17:04 nodens hi there
17:05 felixhummel so here's what I do now: "{% set current_locale = salt['cmd.run']("sudo -Hnu postgres psql -Atc 'show lc_ctype'", cwd="/").strip() %}" and then "{% if current_locale != "de_DE.UTF-8" %}"
17:05 felixhummel thanks guys!
17:06 impi joined #salt
17:06 nodens ok, still a noob, please bear with me : is it possible to run some code with cmd.exec_code or something and have salt NOT interpret the output as a string, but as a json object ?
17:06 nodens (that's the way you do a Q&D module in ansible for instance)
17:06 felixhummel cleaner: salt['cmd.run']("psql -Atc 'show lc_ctype'", cwd="/", runas="postgres")
17:07 iggy felixhummel: user="postgres"
17:07 iggy runas is gone in 2015.5
17:07 nodens the thing is I don't have time to learn enough python to do a proper module yet, so I have some perl code that outputs json (yeah, ugly, I know)
17:07 iggy how are you trying to use this json?
17:07 felixhummel iggy: weird. I run 2015.5 and runas still works. no deprecation messages either
17:08 iggy felixhummel: ahh, only removed from pip stuff, my bad
17:09 felixhummel I see - cmdmod (execution module) vs cmd (state module)
17:09 felixhummel cmdmod still has runas, but cmd has user
17:09 felixhummel :)
17:09 nodens iggy, I'm using the output of salt in a perl script to populate an inventory
17:10 nodens iggy, so I'm not really using the json in salt
17:10 nodens just reading some data from minions
17:10 evilrob joined #salt
17:10 iggy I'm super lost
17:11 iggy if you want json output from salt, use --out=json
17:11 nodens iggy, yes, that part is OK
17:11 iggy else, try pasting some code because your description isn't clear enough
17:12 nodens I just want salt cmdmod exec module not interpreting the output of remote code as string, but as proper json (not adding the \n\t etc)
17:12 nodens clearer ?
17:13 cruatta_ joined #salt
17:14 RabidCicada so...just to clarify my earlier discussion around requisite targets...this is valid and expected for requiring a pkgrepo be required? https://gist.github.com/RabidCicada/8b978a28caff2b683dc3
17:14 felixhummel RabidCicada: looks good to me
17:15 RabidCicada nice...thanks...I'm setting up a pull request for updating the docs to use that example...since it's the corner case that screwed me up to begin with:).
17:16 RabidCicada The syntax for any requisite (require, require_in, etc) is "state module: id".
17:16 RabidCicada For example, to require a pkgrepo be managed the following would be the correct
17:16 RabidCicada code:
17:16 RabidCicada .. code-block:: yaml
17:16 RabidCicada customppa:
17:16 RabidCicada pkgrepo.managed:
17:16 RabidCicada - ppa: wolfnet/logstash
17:16 RabidCicada anotherthing:
17:16 RabidCicada - require:
17:16 RabidCicada - pkgrepo: customppa
17:16 RabidCicada yikes...sorry spam
17:17 nodens iggy, http://paste.debian.net/184223/
17:18 nodens iggy, I can post real exemples if you like
17:19 aCodinMan joined #salt
17:24 nodens (need to run, bbl, please don't hesitate to highlight me ;) )
17:26 murrdoc nodens:
17:27 felixhummel nodens: write a module. It's trivial (RTFM). Then "perl_out = salt['cmd.run'](...)" and "import json" "json.loads(perl_out)".
17:27 murrdoc hahah its trivial, rtfmnoob
17:27 murrdoc love it
17:28 felixhummel I mean the "write a module"
17:28 felixhummel the docs are great, full skeleton included.
17:28 murrdoc its irc , almost everything is said in jest, osrry if i came across srs
17:28 mpanetta Uhoh, someone that likes the docs.
17:28 * mpanetta checks the temp of hell
17:28 mpanetta :P
17:28 * murrdoc puts more ice on it
17:28 felixhummel :>
17:29 lothiraldan joined #salt
17:29 felixhummel I believe what nodens is simple: take the string from cmd.run, json.loads it, and return it in the module.
17:30 felixhummel nodens: Be sure to call "saltutil.sync_modules" after writing your module. ;)
17:30 murrdoc also nodens highglighting
17:30 murrdoc cos u said feel free to highlight me
17:30 murrdoc and i dont have context outside of that
17:31 felixhummel nodens' screen is so bright right now
17:31 murrdoc is he getting back json ?
17:31 murrdoc or does he want json
17:32 cruatta joined #salt
17:33 murrdoc https://gist.github.com/anonymous/dbe2e91b25bbc664b3eb
17:33 murrdoc there  u go
17:34 jdesilet joined #salt
17:36 cruatta_ joined #salt
17:37 CeBe1 joined #salt
17:38 ndrei joined #salt
17:38 ajw0100 joined #salt
17:39 felixhummel murrdoc: I believe that's what nodens wants.
17:39 murrdoc they should add that to the salt modules
17:39 murrdoc cos u know json ftw
17:39 murrdoc it could use some error checking
17:39 murrdoc like does the script actually exist
17:41 stoogenmeyer__ joined #salt
17:42 matthew-parlette joined #salt
17:45 forrest joined #salt
17:46 denys joined #salt
17:46 vexati0n is there any way to get salt to fallback to salt-ssh for minions that don't return?
17:48 lothiraldan_ joined #salt
17:49 c10 joined #salt
17:49 troubled joined #salt
17:49 forrest_ joined #salt
17:51 abng88 joined #salt
17:52 troubled Hello! I was wondering if anyone might be able to offser some suggestions with a reactor. The reactor I am using is meant to decommission a node's keys on shutdown in a vm/cloud environment. The problem is that if multiple nodes go down at the same time, despite the event being sent, the reactor doesn't seem to catch them all to run a command on a target machine. Is there any way to queue up all the events in a reactor or something to make this mor
17:53 linjan joined #salt
17:53 troubled Also, the decommision of the key isn't for a salt key, so wheel isn't of use to me here, it is for another application with its own key management tools
17:53 Gareth ahoy hoy
17:53 robawt ahoy hoy Gareth
17:53 * robawt highfives Gareth
17:53 abng88 Hi everyone! Is it possible to configure a minion to run masterless using a git remote backend instead of looking for states/pillars locally? The docs only mention configuring this in the master config
17:53 Gareth robawt: o/
17:54 * murrdoc nods at high fivers
17:56 robawt ha
17:59 julez joined #salt
18:03 forrest joined #salt
18:05 litwol abng88: if i'm not mistaken you can run command 'salt-call'
18:06 baweaver joined #salt
18:06 litwol ie run individual SLS etc
18:06 FeatherKing is it possible to detect the ip subnet within a state file? like run this section if one subnet, and that section if that subnet
18:06 abng88 right but can i run a salt-call using a git remote fs
18:06 abng88 configured in the minion file
18:06 murrdoc this aboe76 dude needs to hang out in irc
18:06 murrdoc too much work to email
18:07 robawt FeatherKing: check out the grains, you can get the IP for your connected devices automatically.  'salt-call -g' to see the current ones and call them from the salt state
18:07 litwol abng88: don't know how to do that within salt exclusively.. but think what runs the salt-call in the first place? in your situation it would be a cronjob or something. or manual execution.
18:07 forrest murrdoc: He does.
18:07 litwol abng88: then nothing stops you adding a manual step in the process to checkout arbitrary git repo and run specific sls from there.
18:07 forrest murrdoc: Just isn't around today.
18:07 litwol abng88: it doesn't have to be defiend in minion config as git remote fs
18:08 druonysus joined #salt
18:08 litwol just do a wrapper script to 'git checkout foo; salt-call foo/my_sls.sls'
18:08 litwol no?
18:09 abng88 yeah i was hoping i could do it without having a clone step in there
18:09 forrest abng88: gitfs works fine on a masterless minion.
18:09 abng88 but i guess that's what the master would be doing anyways
18:09 ndrei joined #salt
18:09 Pulp joined #salt
18:10 forrest abng88: oh actually maybe it doesn't, realized my code is doing something different, sorry. I'd say just try it
18:10 forrest if it works, create an issue to add to the docs.
18:10 FeatherKing robawt: i was thinking something like {% if salt['network.ipaddrs']('eth0','').match("2.3.4.0") %} then do something for the 2.3.4.0 subnet
18:10 forrest Seems weird to me that it wouldn't work.
18:10 FeatherKing robawt: but i have never tried to split within the salt state itself like this
18:11 forrest FeatherKing: {% if '2.3.4.0' in salt['network.ipaddrs']('eth0') %} something along those lines should do the job.
18:11 abng88 ok i'll just try it out. thanks litwol and forrest!
18:11 FeatherKing could 2.3.4.0 also come from like pillar data?
18:11 iggy abng88: what version of salt?
18:12 forrest yeah sorry abng88, if it does work, please create an issue so we can update it. I thought it worked, let me log onto my actual box, hang on..
18:12 baweaver joined #salt
18:13 iggy http://docs.saltstack.com/en/latest/topics/releases/2014.7.0.html#fileserver-backends-in-salt-call
18:13 abng88 2014.114
18:14 abng88 1.14
18:14 abng88 oh sweet
18:14 abng88 thank you iggy
18:14 jhauser joined #salt
18:14 murrdoc forrest:  aboe76 wants testing
18:14 murrdoc TESTING ?
18:14 murrdoc wtf is that
18:14 forrest abng88: Can you create an issue for that in the salt repo to add it to the docs please?
18:15 forrest murrdoc: testing with test kitchen? Or travis or something?
18:15 forrest I assume for formulas
18:15 iggy I'm not installing vagrant and I wouldn't make anyone else do it
18:15 iggy it's nice to have if someone wants to do it
18:15 abng88 ok
18:15 iggy but not a requirement (imo)
18:16 murrdoc it works
18:16 murrdoc i mean it should work
18:16 murrdoc cos u know i wrote it
18:16 baweaver joined #salt
18:16 iggy #sscewannabecertified
18:17 murrdoc #nocertallgut
18:17 murrdoc forrest:  where are teh 'test' instructions for salt-formula
18:17 mitsuhiko joined #salt
18:18 forrest murrdoc: what test instructions? /troll
18:18 forrest I don't really follow the mailing list that religiously
18:19 murrdoc https://github.com/saltstack-formulas/salt-formula/pull/137
18:19 murrdoc https://github.com/puneetkid you test this with pillar salt:lookup still works?
18:19 murrdoc nope, but should work, assuming functions work as designed and to my understanding. I have used similar stuff in other places.
18:19 murrdoc :D
18:20 forrest This puneetk guy, what a noob... ;)
18:20 murrdoc yes sir
18:20 forrest really we should just do a travis.yml like in the jenkins formula
18:20 murrdoc vim said it was valid jinja
18:20 murrdoc so u know
18:20 forrest does travis still not support multiple OS's?
18:21 hal58th_1 joined #salt
18:21 hal58th_2 joined #salt
18:22 hal58th_3 joined #salt
18:23 tobie__ joined #salt
18:24 tobie__ howdy
18:24 tobie__ I have a question on salt stack's django module
18:24 ndrei joined #salt
18:24 tobie__ I am pretty familiar with salt but not with django
18:25 tobie__ I wanted to know what is "settings_module"
18:25 tobie__ argument that the module expects as the first arg
18:25 tobie__ when say I try to do django.syncdb
18:25 tobie__ :)
18:26 tobie__ anyone...
18:27 forrest tobie__: Looks like syncdb is explained here: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.djangomod.html past that, I'd say check the django docs for more details.
18:28 iggy tobie__: you'll really want to be at least partially familiar with django
18:28 vexati0n is it possible to use RAET /and/ ZeroMQ on one master?
18:28 tobie__ so I have learned..
18:28 tobie__ thanks
18:28 iggy vexati0n: not yet
18:28 tobie__ again guys
18:29 iggy tobie__: settings_module is pretty central to Django, you should hit it in the first couple pages of docs and be able to get something at least partially working
18:29 vexati0n iggy: okay, thanks. can i approximate it by using multimaster, with one master on RAET and the other on ZMQ? Are things like JIDs, etc., portable between the two?
18:29 tobie__ awesome I shall
18:29 tobie__ thanks
18:29 pmcg joined #salt
18:30 FeatherKing forrest: is there a way i can see what salt['network.ipaddrs']('eth0') is evaluating as? i added the conditional in my pillar but i am not getting any values when i run pillar.items
18:30 ALLmight_ joined #salt
18:30 druonysuse joined #salt
18:30 FeatherKing forrest: {% if '2.3.' in salt['network.ipaddrs']('eth0') %} is my line
18:31 FeatherKing but it doesnt match
18:31 forrest FeatherKing: That syntax might be wrong, you might need to do a lookup if this is a pillar value
18:31 piffio joined #salt
18:31 linjan joined #salt
18:31 FeatherKing well i decided to put it in my pillar saying something like if this subnet then use these values, if that subnet use these values
18:31 forrest FeatherKing: Check out pillar.item, and pillar.get http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.pillar.html if you are storing that stuff in pillar.
18:32 forrest FeatherKing: Oh so you're actually looking at the network grain data?
18:32 FeatherKing yeah pillar.items shows nothing is applied
18:32 FeatherKing yeah so i would evaluate the ip of the machine
18:32 cpaclat joined #salt
18:32 FeatherKing determine where its located, and give it values based on its location
18:32 FeatherKing so the values are in the pillar, just trying to detect the subnet
18:32 FeatherKing but no pillar items get applied
18:33 FeatherKing maybe i am approaching the wrong way
18:34 iggy vexati0n: no clue, you should ask on the list maybe
18:34 murrdoc forrest:  setting up travis
18:34 murrdoc for salt-formula
18:34 murrdoc is a good
18:34 murrdoc idea
18:35 murrdoc o/
18:35 iggy ^
18:35 druonysus joined #salt
18:35 forrest murrdoc: Ahh, I didn't see any note regarding that. I don't think travis allows testing on multiple operating systems still though right?
18:35 ndrei joined #salt
18:35 iggy one is better than nothing
18:35 iggy just make sure it Debian
18:36 otter768 joined #salt
18:36 forrest FeatherKing: Well, do a grains.ls and look for the IP address stuff, then go a grains.get (on the command line) to pull the data for that minion, then use a comparison against the grain network address stuff.
18:37 murrdoc ubuntu > all
18:37 forrest murrdoc: lol
18:37 forrest uh huh
18:39 noobadmin joined #salt
18:40 * davisj wonders if there's a way to cache rendered pillar data on the minion. To enable something like this[1] when salt-master is unreachable. *[1] salt-call --local --file-root=/var/cache/salt/minion/files/base --pillar-root=/var/cache/salt/minion/pillar
18:40 forrest abng88: Did you create an issue in the salt repo regarding gitfs not showing up in the minion config docs? If not I'm going to create an issue.
18:41 forrest davisj: Pretty sure the rendered data is only sent when the call occurs, but I'd say just try it.
18:41 ndrei joined #salt
18:41 forrest see what is in the cache when you do a state.highstate or whatever.
18:42 forrest abng88: Ahh I see it, thanks!
18:42 davisj forrest: I did but the fact that /var/cache/salt/minion/pillar doesn't exist (outside of my imagination) seemed to prevent success.
18:43 forrest davisj: gotcha
18:43 davisj forrest: I think I could get away with in in the case were pillar data is not referenced in the states, but that's... limiting.
18:44 forrest davisj: Yeah, is there any specific use case you need this for? Maybe there is a better solution
18:44 forrest iggy: Have you seen Jacob Hammons around in the IRC today?
18:44 davisj forrest: intermittently connected minions. Remote workstations, essentially.
18:45 forrest davisj: I see, have you considered masterless minions for that situation? With their pillar pulled from S3 or some system?
18:46 davisj I briefly contemplated something like that but didn't want to have to many moving parts. I'll give it more thought.
18:46 forrest iggy: I'm noticing the docs are relatively slow to load the whole page, it doesn't render all at once via the HTML it seems, so if you do a search via cmd/ctrl-f it doesn't immediately find stuff, which is annoying
18:46 iggy haven't, no
18:47 tiadobatima hi guys... I'm getting this everytime in the first highstate run:
18:47 tiadobatima http://pastebin.com/ztuQnnF2
18:47 forrest davisj: Gotcha.
18:47 iggy but I've noticed some strangeness with docs as well
18:47 forrest iggy: in regards to how they load?
18:47 felixhummel joined #salt
18:47 noobadmin hello, everybody. I'm new here and I need a little help with something: It is possible to use asterisks as a wildcard as the name of a package in a sls file?
18:47 forrest iggy: The search issue I'm having is brutal, makes finding stuff a real problem, because you can SEE it in the search hitting the entry, but it isn't actually moving to the location because it hasn't rendered yet or whatever.
18:48 iggy some weirdly rendered stuff, I'd have to go check rtd to make sure it isn't just malformed source (vs the actual docs renderer being wonky)
18:49 iggy noobadmin: for some pkg modules, yes (yum I think, apt maybe)
18:50 jhauser joined #salt
18:50 forrest tiadobatima: malformed command perhaps? [INFO    ] Executing command ['dpkg-query', '--showformat', '${Status} ${Package} ${Version} ${Architecture}\n', '-W'] For the resource unavailable, I'm not sure, that might just be a docker thing
18:51 noobadmin_ joined #salt
18:52 tiadobatima thx forrest... will check it out on the docker formula first...  I'm here trying hard to be a hipster and they don't let me :)
18:53 forrest tiadobatima: Heh, what are you trying to achieve?
18:53 forrest querying dpkg seems kind of weird to do with salt.
18:53 tiadobatima I wasn't doing that myself... I imagine its something in the docker formula
18:54 noobadmin_ iggy: I'm trying to create a sls with pkg.installed - name: gstreamer0.10-* (for ubuntu workstations) but it doesn't behave like I spected... I doesn't expand... could this be a bug or it is intended?
18:54 iggy probably intended
18:54 forrest Hmm, https://github.com/saltstack-formulas/docker-formula/blob/efb5208aa394250c8144b00b2de163e81bdc3543/docker/init.sls#L16 is the only reference I see to dpkg in the docker formula.
18:55 tiadobatima yeah
18:55 forrest noobadmin_: is the name of the package gstreamer0.10?
18:55 druonysuse joined #salt
18:55 druonysuse joined #salt
18:55 forrest and you're just trying to install the latest? Or do you actually want multiple versions.
18:56 tiadobatima just latest
18:56 iggy probably wants all the plugin packages
18:56 iggy without having to list them out one-by-one (which yes, is a pita)
18:56 noobadmin_ forrest: like iggy says, I want to install different plugins at the same time...
18:56 noobadmin_ do you know if there is a workaround?
18:57 noobadmin_ or I have to list all of the packages one by one?
18:58 forrest noobadmin_: https://gist.github.com/gravyboat/4a81ac0d183ab2093697 is the only way I know of that would reduce the work.
19:00 noobadmin_ ok, thanks for the info!
19:02 forrest np
19:02 murrdoc nooo bad admin
19:02 murrdoc is a really bad name
19:03 noobadmin_ why? :P
19:03 murrdoc cos it sounds like something your duck would say to u
19:03 murrdoc nooo, bad admin
19:05 tiadobatima forrest... the command comes from: https://github.com/saltstack/salt/blob/develop/salt/modules/aptpkg.py#L992
19:06 hybridpollo joined #salt
19:07 forrest tiadobatima: Ahh good catch. Weird, I'm not sure then. Can you see if just running a super simple state with docker commands (not the formula) works, and if it does, file an issue with the formula, if it doesn't, can you file an issue with the salt repo if one doesn't exist?
19:08 noobadmin_ murrdoc: sorry but I don't get it =/ (english is not my first language)
19:08 forrest tiadobatima: I've been running into some docker issues this release already, so I'm not sure if they are related.
19:10 murrdoc noobadmin_:  its not mine either
19:10 murrdoc noob admin != no bad admin
19:11 impi joined #salt
19:12 tiadobatima forrest: I've submitted a few patches a few hours ago, so I'm kindda familar with the docker formula... not sure what we can on that end as they're not doing anything too complex... just some straight package installs plus few minor things
19:13 murrdoc tiadobatima:  i need to stop merging your stuff
19:13 murrdoc especially cos u broke stuff
19:13 murrdoc and fixed it
19:13 murrdoc heh
19:13 tiadobatima sorry for that murrdoc! :)
19:14 murrdoc next pull sits for a day
19:14 murrdoc or an hour
19:14 forrest tiadobatima: Yeah I just looked at it again (pretty sure I saw your PR in my notifications and murrdoc merged it)
19:14 murrdoc depending on how long i want to u on timeout
19:14 forrest what a despot
19:14 murrdoc DAS ME
19:15 tiadobatima we have to use our internal github here in the office and I got the two forks mistaken :P
19:15 noobadmin_ murrdoc: :P
19:15 murrdoc tiadobatima:  excuses !
19:15 murrdoc noobadmin_:  :)
19:16 ajw0100 joined #salt
19:16 tiadobatima does it help that I still feel bad about it? lol
19:17 tomh- joined #salt
19:18 murrdoc no
19:18 murrdoc u must buy us cookies
19:18 murrdoc (i totally dont care that u did it)
19:19 soren_ joined #salt
19:28 noobadmin_ well, It seems that I was wrong and salt do actually expand the wildcard in the name of the package
19:28 tiadobatima what kindda cookies? :D
19:29 noobadmin_ I didn't check it correctly and when I double checked it worked!
19:36 c10 joined #salt
19:39 refnode joined #salt
19:40 edrocks joined #salt
19:48 ndrei joined #salt
19:48 dragon788 joined #salt
19:50 dragon788 where can I find the 2014.7.4 or 2014.7.5 rpm for EL6 ?
19:51 manfred you will have to go looking through the archives of epel
19:52 dragon788 I tried rpmfind and rpmseek
19:52 dragon788 haven't found the actual archived rpms
19:52 murrdoc trawl their web servers
19:53 manfred dragon788:  http://koji.fedoraproject.org/koji/packageinfo?packageID=13129
19:53 manfred check the koji
19:53 ndrei joined #salt
19:54 Berty_ joined #salt
19:56 dragon788 awesome, googling was failing me hard :(
19:56 dragon788 what exactly is a koji, something like the OpenSuSE build service?
19:58 spookah joined #salt
19:59 _JZ_ joined #salt
19:59 adelcast left #salt
19:59 dragon788 found what I needed, thanks for the pointers
20:02 joeto joined #salt
20:03 murrdoc hey
20:03 murrdoc tiadobatima:  can u make the refresh thing a parameter too
20:04 murrdoc like pkg.refresh
20:05 tiadobatima murrdoc: can do! but don't we want that refreshed regardless of the platform? in this case we're always installing a new repo
20:05 adelcast joined #salt
20:06 murrdoc a new repo should automatically be refreshed
20:06 murrdoc is that not the case ?
20:07 druonysus joined #salt
20:07 druonysus joined #salt
20:09 jeremyr joined #salt
20:09 tiadobatima murrdoc: it wasn't until this pull request
20:09 ndrei joined #salt
20:09 murrdoc that means every highstate run will do an apt-get update
20:09 murrdoc thats slow
20:09 RedundancyD joined #salt
20:09 murrdoc i ll merge it
20:09 murrdoc i dont mind
20:10 tiadobatima if you're not happy, don't merge it just yet
20:10 RabidCicada there a good way to make salt pause for further input as part of debugging?  I'm trying to debug the effect of a network outage at a very particular point of a long "salt install process"
20:10 murrdoc i am happy
20:10 murrdoc now i just need to review your code
20:10 murrdoc since u booboo'ed it today
20:10 RabidCicada I'd like if it hung until a file was written or for keyboard input
20:11 tiadobatima I just dont know how to make that conditional based on if the repo was installed or not
20:11 murrdoc yeah
20:12 murrdoc i feel like pkg.latest should handle this kind of stuff
20:12 murrdoc like {% if pkg and 'version' in pkg %} then do what u have {% else %} pkg.latest {% endif %}
20:13 RabidCicada I'm running my test as a masterless install.  I'd like it to hang just before the critical test location, I'll vm snapshot it, then induce network outages when I let it continue after  the snapshot point.
20:14 murrdoc tiadobatima:  http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.latest
20:15 tiadobatima I see what do you mean murrdoc...
20:15 murrdoc up to u
20:15 tiadobatima but do you think this is enough to prevent that stack trace that I posted earlier?
20:15 baweaver joined #salt
20:16 murrdoc either ways, update the readme to reflect that the formula will install the latest docker package
20:16 murrdoc u can put a refreh:True in pkg.latest too
20:17 ndrei joined #salt
20:17 tiadobatima because regardless of the version, if the repo is not synced the list package will fail and break the highstate run
20:18 iggy if you put require_in in the pkgrepo state, it'll automatically update if requried
20:18 murrdoc yeah
20:18 murrdoc thats what it was
20:18 asdfasdfawea joined #salt
20:18 * murrdoc forgot that
20:18 tiadobatima iggy... then it wont run again?
20:19 druonysus joined #salt
20:19 iggy I'm not really sure what you guys are talkig about
20:19 * iggy slacking on formulas duties this week
20:19 tiadobatima sorry for the stupid question... just started using salt last week :P
20:20 murrdoc dont be
20:20 murrdoc u are giving back to the community already
20:20 murrdoc so questions are good
20:20 iggy was going to say, you're further along than most people after a week
20:20 tiadobatima :)
20:22 gladiatr joined #salt
20:23 tiadobatima anyways guys... should I file I bug about this stack trace: http://pastebin.com/ztuQnnF2?
20:23 tiadobatima It doesn't feel right that we get a stack trace because a package can't be found
20:26 sunkist joined #salt
20:30 iggy tiadobatima: what package missing is causing that?
20:30 TaiSHi When using mysql.database state, can you specify connection_user?
20:31 TaiSHi Because it's trying to use root but doesn't know the password. Not sure if that's the correct way
20:31 tiadobatima iggy: triggered by not having a refreshed repo in docker-formula
20:32 iggy tiadobatima: ehh, I guess a more useful error message wouldn't kill anybody, but it's a slippery slope... how much should you protect people from themselves
20:33 iggy but definitely fix the formula
20:34 DammitJim joined #salt
20:34 DammitJim how do I make my minion find the master if we are on different subnets?
20:34 ndrei joined #salt
20:34 DammitJim Do I add it to my DNS server as a new A Host?
20:35 tiadobatima yeah... just suggest catching that exception, and fail with an user friendly error msg. Still up to the user to fix his code
20:37 otter768 joined #salt
20:38 ndrei joined #salt
20:40 tiadobatima murrdoc, iggy... is this what you're referring to? https://github.com/saltstack-formulas/docker-formula/blob/master/docker/init.sls#L45
20:41 supersheep joined #salt
20:43 troubled if I have a bunch of nodes all shutdown at the same time, and each node fires off a 'node/shutdown' event before going down, is there anything you can think off that would cause a reactor from firing for 100% of the events?
20:43 tiadobatima because without the "refresh: True" entry in the pkg.installed, I get that stack trace
20:43 Tyrm joined #salt
20:43 troubled the reactor state itself is calling a custom module on another target, if that helps any
20:44 aparsons joined #salt
20:44 troubled it almost seems like things get dropped if things are all called at the same time, rather than queueing the calls up to the target, which is what I need
20:46 jrobin joined #salt
20:46 dragon788 troubled, its definitely possible that there is a stampede on the host and it can't keep up
20:47 iggy run with debug on and verify that the reactor isn't getting called, if so, file a bug
20:47 troubled dragon788: thats what it seems like. Its very tedious to troubleshoot since it takes time to switch windows and check if it worked, reboot the vm's etc. But it seems like the events do show up on the bus just fine on the saltmaster, they just don't all seem to be able to call the module on the target
20:48 dragon788 have you rebooted/restart the saltmaster recently?
20:48 troubled iggy: the debug output is very intimidating! I have to fire off at least 3 or 4 nodes to get it to miss one, and due to the state and pillar size im looking at 10k+ lines per node each test
20:48 dragon788 we had some reactor issues and it turns out a full restart fixed it, just making changes wasn't doing anything
20:49 bougie is it a way to simply associate a minion to several "groups" / whatever ON THE SALT MASTER ? Like writing custom grains, but on the master and not on each minions
20:49 troubled dragon788: I tried saltutil.sync_modules, I tried restarts, even noticed I wasn't on latest package from the repo and upgrade+restarted with no luck
20:49 iggy bougie: a #!py renderer ext_pillar maybe
20:50 iggy or a full blown ext_pillar
20:50 dragon788 bougie, sounds like you want a minion_id match in the salt/top.sls and then apply the states you want via those groups
20:50 jrobin Hello everyone, I'm running into a weird issue with reactors and I'm wondering if anyone around here has seen something like this.
20:52 troubled dragon788: do you know by chance what the design of salt is with regards to handling say a dozen simultaneous events that invoke a module would be? Just not sure if I am just expecting too much and need to redesign the reactor state file with another approach where things are more strictly controlled or something else like not using the module and calling cmd.run instead
20:53 jrobin I've set up my desired tag in /etc/salt/master.d/reactor.conf pointing to a the state I wish to run but the target is never matched when I run "salt-call event.fire_master" passing the tag as paramenter
20:53 bougie hm yes dragon788, this is probably what I want :)
20:53 dragon788 troubled, I don't know the specifics, but I believe there are some options in the master and minion configs that allow tweaking/randomizing some timeframes so that you can throttle stampedes a bit
20:55 troubled dragon788: no idea if things get batched or queued though?
20:55 Deevolution Anyone seen an issue where some minions report: "DNS lookup of 'None' failed." over and over again?
20:56 murrdoc yeah
20:56 murrdoc one of your minions has None has the salt master
20:56 Deevolution murrdoc: that was the first thing I checked, but it has no "master:" stanza in the minion config.
20:58 ndrei joined #salt
21:00 iggy there was a bug
21:00 iggy maybe filed by me
21:00 murrdoc k then idk
21:00 murrdoc maybe add an explicit master ?
21:01 iggy Deevolution: look anything like 22725?
21:01 iggy nah, nvm, different thing
21:02 iggy that's with no minion id set
21:02 jhauser joined #salt
21:03 Deevolution murrdoc: I removed the explicit master I had in order to address several multi-master oriented issues I was having...
21:03 iggy if it was multi-master, did you just comment out the list or the master: line too?
21:03 Deevolution It no longer has a "master:" stanza at all.
21:04 iggy grep -rin ^master /etc/salt
21:04 c10 joined #salt
21:04 iggy that's the only thing I can think of
21:05 Deevolution iggy:  Yep, did that, nothing there.
21:05 Deevolution I'm pretty confused where this is getting it from...
21:06 jrobin joined #salt
21:06 jrobin My expected output while running salt-master in debug mode should look like the following: "[DEBUG   ] Gathering reactors for tag foo/bar" as the documentation states, instead, I get something like this: "[DEBUG   ] Gathering reactors for tag salt/job/2015052615..."
21:07 DammitJim is it normal to have to run salt commands as sudo?
21:07 DammitJim I'm on Debian
21:08 vexati0n DammitJim: yes it's normal. salt runs as root, not as your unprivileged user. if you don't want to use sudo, you'll need to configure PAM authentication in /etc/salt/master and fix the permissions on /var/log/salt/master
21:08 DammitJim that's alright
21:09 DammitJim I guess normally, I would create my scripts and run them once with sudo
21:09 DammitJim thanks vexati0n
21:09 vexati0n err.. i guess you don't have to do pam, but you should do the ACLs
21:10 Deevolution I think the root issue was an (old) hanging salt-call state.highstate.
21:11 cpowell joined #salt
21:16 stanchan joined #salt
21:19 losh joined #salt
21:24 cpowell joined #salt
21:25 theologian joined #salt
21:28 FeatherKing joined #salt
21:29 DammitJim does one normally create a "file" repository with configuration files for the different servers?
21:29 DammitJim say I am configuring a samba server... do I create a formula to change the smb.conf file or do I copy a new smb.conf file to the minion?
21:34 cpowell joined #salt
21:35 forrest murrdoc: I'm letting you handle this one: https://github.com/saltstack-formulas/docker-formula/pull/33#issuecomment-105670828
21:36 baweaver joined #salt
21:36 murrdoc forrest:  tiadobatima is working on using pkg.latest and require_in
21:36 murrdoc he ll get us a fix soon
21:37 julez joined #salt
21:37 forrest murrdoc: Yeah I remember you guys talking about that earlier, just didn't know all the details
21:37 forrest so figured I'd let you handle it
21:39 vieira joined #salt
21:39 monkey66 left #salt
21:40 vieira anyone using salt as a substitute for nrpe?
21:40 solidsnack joined #salt
21:40 vieira to handle the remote execution of nagios checks?
21:44 amcorreia joined #salt
21:57 ALLmightySPIFF joined #salt
21:57 druonysus joined #salt
21:57 jbirdman joined #salt
22:01 troubled left #salt
22:05 c10 joined #salt
22:08 giantlock joined #salt
22:09 aCodinMa_ joined #salt
22:11 baweaver joined #salt
22:11 enriched joined #salt
22:15 druonysuse joined #salt
22:16 subsignal joined #salt
22:19 vexati0n ok, really simple question -- i have defined states. and i can apply them with salt.highstate, etc. but does Salt continually run these states to make sure they are always enforced, or do I have to manually run salt.highstate periodically?
22:20 forrest vexati0n: You need to run highstate periodically unless you set up the scheduler: http://docs.saltstack.com/en/latest/topics/jobs/schedule.html
22:22 vexati0n thanks
22:23 spookah joined #salt
22:23 vexati0n is there a method to run highstate on every minion when it first registers, in addition to scheduling the highstate for everyone?
22:24 aurynn vexati0n, yes, using the reactor
22:24 murrdoc well
22:25 murrdoc that or startup_state
22:25 murrdoc but aurynn is right-er
22:29 aurynn of course I don't have the link on *how* handy..
22:30 vexati0n i'm reading.
22:30 murrdoc its actually on the reactor homepage
22:30 murrdoc u just have to write a new netry for 'auth/accepted'
22:30 vexati0n of course i don't need to do a bunch of crazy stuff. just "if you're starting up do state.highstate"
22:30 murrdoc well then do startup_states in the minion.conf
22:31 vexati0n minion conf files are generated programmatically which means i have to talk to another person to make changes there.
22:31 murrdoc make a state to drop a file in /etc/salt/minion.conf.d/
22:32 mrbigglesworth joined #salt
22:32 murrdoc also i hate talking to people too
22:32 murrdoc so i understand
22:32 vexati0n yeah the problem is the state won't do anything until it calls state.highstate to begin with. i'm sure i can get reactor to do what i want anyway so i will just mess with that until i figure it out.
22:36 forrest iggy: That idea regarding the S3 stuff is interesting for the aptly formula. I'm glad aptly is getting some traction.
22:36 forrest since building ubuntu repos is terrible.
22:38 otter768 joined #salt
22:45 refnode joined #salt
22:46 Aidin joined #salt
22:49 sunkist1 joined #salt
22:52 viderbit joined #salt
22:55 vexati0n gah. "unable to render reactions for event" ... "due to errors (too many functions declared in state..." ... although, if i run state.highstate directly on a minion, it doesn't see "too many functions" in that file, AND in the reactor config for the master, it isn't even referencing that file!
22:58 tiadobatima hi murrdoc... I'm confused about the require_in solution with the docker-formula... I'm not seeing how I can require the repo to be refreshed when the it's installed and at the same time prevent it from refreshed in subsequent highstate runs
22:59 murrdoc tiadobatima:  that was iggys idea
22:59 murrdoc for now
22:59 murrdoc if u want
23:00 murrdoc just do pkg.latest vs pkg.installed
23:00 mosen joined #salt
23:00 murrdoc depending on whether version is specified or not
23:01 iggy a highstate is going to do a apt-get upgrade pretty much every time anyway (at least mine do)
23:02 baweaver joined #salt
23:02 tiadobatima does pkg.latest also "apt-get update" by default?
23:05 iggy yes
23:08 vexati0n is there some limit to the number of sls files i can specify in top.sls when calling state.highstate?
23:09 vexati0n mine works fine when i issue the state.highstate command to minions directly, but there is a "too many functions declared" error when called by the reactor system.
23:10 vexati0n none of the state have more than 2 sls files declared, btw.
23:13 ALLmightySPIFF joined #salt
23:14 TaiSHi Does any of you handle swap space from salt? (as in, creating a swap file, not recreating it if it exists, and such)
23:15 murrdoc i do
23:15 murrdoc but only for aws
23:16 TaiSHi murrdoc: got any examples? I might have seen a 'creates' statement but not sure
23:17 murrdoc u argentinians are so lazy
23:17 murrdoc gawd
23:17 murrdoc :D
23:17 murrdoc or was that brazillians
23:18 mosen hiya murrdoc
23:18 murrdoc ah shit TaiSHi i liked
23:18 murrdoc i did it in salt
23:18 murrdoc but i didnt commit it in
23:18 murrdoc so thats my bad
23:18 murrdoc mosen:  hey
23:18 TaiSHi murrdoc: Argentinian ¬¬
23:18 TaiSHi Brazilians suck at football
23:18 TaiSHi Mostly because we keep owning them
23:19 murrdoc except for like ronaldinho
23:19 murrdoc ronadlo
23:19 murrdoc the short number 6
23:19 TaiSHi Nah, he sucks as well
23:19 murrdoc HAHA
23:20 tiadobatima ohhhh I see iggy... when I read the docs, I assumed the refresh=None would result the repos not to be refreshed http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.latest
23:22 tiadobatima but of course this is python :D
23:24 tiadobatima this can be confusing for the less savvy in python though...
23:25 baweaver joined #salt
23:26 julez joined #salt
23:26 murrdoc salt is here to elevate your skills
23:29 tiadobatima lol
23:35 TaiSHi so murrdoc ? Gief info!
23:36 murrdoc ?
23:36 murrdoc oh i cant find it
23:36 murrdoc i didnt commit to git
23:36 TaiSHi Grep until you find it!
23:36 murrdoc the vms are gone
23:36 murrdoc aws*
23:36 sunkist1 joined #salt
23:37 murrdoc i did a cmd.run sadly
23:37 cpowell joined #salt
23:38 tiadobatima btw... I imagine it'll be quite confusing for the end user that the default refresh=None seems to behave differently on pkg.latest and pkg.installed :)
23:40 scoates joined #salt
23:49 cruatta joined #salt
23:50 refnode joined #salt
23:51 forrest iggy: You around?
23:51 aCodinMan joined #salt
23:52 forrest bah nevermind, I'm an idiot
23:53 murrdoc bot: add quote
23:53 loz-- joined #salt
23:53 c10 joined #salt
23:54 iggy forrest: just out of curiosity what was it (besides self-proclaimed idiocy)?
23:54 forrest Caching of files on my minion combined with forgetting I wasn't using gitfs
23:55 forrest thought I was missing a cache removal somewhere, when in fact I just didn't have my latest revision checked out
23:56 iggy rgr, next up on my list, ditching gitfs and using github webhooks to poke the states/pillar git.latest state
23:57 mosen you guys using gitfs for pillars too?
23:57 iggy for now
23:57 mosen ok
23:58 murrdoc make it a deb dude
23:58 iggy I mean, we will continue using git for them, it'll just be a static checkout (with the aforementioned webhook+reactor to update)
23:58 murrdoc debs > git
23:58 RabidCicada Is there a problem with gitfs for pillars?
23:58 RabidCicada I thought it was good.  But I'm not very experienced.  I like it so far...Tell me what troubles I haven't run into!
23:59 lloesche joined #salt
23:59 iggy RabidCicada: our issue is that we now have about 14 formulas+internal states+pillars... all updating every minute for virtually no reason
23:59 RabidCicada ahh....ok...so you don't like the refresh cycle *hitting* for each and every one?
23:59 seblu joined #salt

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