Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-12-29

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

All times shown according to UTC.

Time Nick Message
00:13 dcmorton joined #salt
00:16 glyf joined #salt
00:26 qing joined #salt
00:36 glyf joined #salt
00:36 bhosmer joined #salt
00:47 elmar555 joined #salt
01:01 davet joined #salt
01:07 diegows joined #salt
01:12 aqua^mac joined #salt
01:18 Eugene So I'm seeing a fair bit of memory usage(and occasional CPU spikes) by salt-master, with only 6 minions.
01:18 Eugene Memory histograph: http://i.imgur.com/azsGm6c.png
01:19 Eugene CPU histograph: http://i.imgur.com/HOZkram.png
01:20 Eugene And htop during a spike http://i.imgur.com/cbRTCsi.png
01:22 Eugene It's not a concern quite yet, but it does make me go "hrmm"
01:23 Eugene Perhaps tweak something like worker_threads in my master config?
01:33 nyx_ joined #salt
01:40 acabrera joined #salt
01:52 twellspring joined #salt
02:03 twellspring I am looking to implement Salt at my new job ( used Ansible at previous gig).  I am trying to figure out how to do a rolling upgrade   1. remove app server from ELB  2.  upgrade packages & restart services  3.  put app server back into ELB.    Can you give me any pointers on how to do this in salt?
02:12 gamingrobot_ joined #salt
02:12 pdayton joined #salt
02:20 freimer I believe there is a -b or --batch option to run batches of upgrades or "highstate" on minions.  This will prevent all of the minions from being upgraded at the same time, potentially causing an outage...
02:24 freimer http://docs.saltstack.com/en/latest/topics/targeting/batch.html
02:25 freimer An alternative, and recommendation I would think, would be to just throw away your ELB instance and have it auto-scale back, sending a SNS message to the Salt master to add the new instance and configure it appropriately...
02:25 freimer There is an ec2-autoscale reactor for that, which I was able to get working in dev.
02:26 freimer https://github.com/saltstack-formulas/ec2-autoscale-reactor
02:26 freimer You will need a valid certificate for your Salt Master for SNS to send message to...
02:37 nyx_ joined #salt
02:53 nethershaw joined #salt
03:05 bhosmer joined #salt
03:11 Mso150 joined #salt
03:33 TomWork joined #salt
03:59 rypeck joined #salt
04:22 _JZ_ joined #salt
04:40 kermit joined #salt
04:41 TyrfingMjolnir joined #salt
04:58 pdayton joined #salt
04:58 kaiserpathos joined #salt
05:07 cmr joined #salt
05:08 malinoff joined #salt
05:09 twellspring joined #salt
05:11 cmr I've been enviously eyeing salt and vagrant for a while now, and with a recent disk failure I'm happy to have the justification to finally use them for dev work.
05:15 jcockhren cmr: repeatable, dev environments. usually it's faster to declare the provisioning of a box using salt for me, ymmmv
05:15 jcockhren ymmv*
05:16 cmr jcockhren: instead of going through vagrant?
05:16 cmr (or other such software)
05:22 cmr Hm, I see http://docs.saltstack.com/en/latest/topics/virt/index.html
05:22 cmr Looks useful
05:31 acabrera joined #salt
05:33 jcockhren cmr:  I meant using salt with vagrant
05:33 jcockhren vagrant can use salt as a provisioner
05:34 cmr jcockhren: ah, yes, that is what I have started doing.
05:42 twellspring freimer:  That was not exactly what I was looking for, but I just found the prereq operator, which looks like what I want.  If the package version is going to change, have a prereq to remove from load balancer and then onchanges to add it back to the load balancer.
05:43 glyf joined #salt
05:53 Furao joined #salt
06:04 catpigger joined #salt
06:20 monkey66 joined #salt
07:08 gfa i want to do an if inside an state, the thing to compare is a value in a grain made it by a list, it is possible to do it?
07:13 linjan joined #salt
07:13 ttrumm joined #salt
07:13 Furao gfa?
07:13 Furao you want to know if a value is in a list?
07:14 gfa i want to do something if the value is on the list
07:14 Furao {% if grains[‘bleh’] is in (‘val1’, ‘val2’, ‘val3’) %}
07:16 gfa i want the other way around, i have a grain that contains a list, if val1 is on the list i want to do something
07:16 Furao {% if ‘val1’ in grains[‘bleh’] %}
07:16 Furao like {% if ‘1.2.3.4’ in grains[‘ipv4’] %}
07:17 gfa Furao: it worked, thank you
07:18 Furao in jinja it’s just python you can do almost the same python code
07:18 gfa i always complain about jinja, and say next complex state i will do it in pyobjects, but then all complex state starts as small state in jinja...
07:19 Furao >>> grains = {'ipv4': ['192.168.1.2', '10.0.0.3']}
07:19 Furao >>> '192.168.1.2' in grains['ipv4']
07:19 Furao True
07:19 malinoff gfa, use mako
07:19 stoogenmeyer_ joined #salt
07:20 gfa i tought about it, i found it uglier and i preffer to become fluent in python than maki
07:20 gfa s/maki/mako/
07:21 malinoff well, mako is still a template engine which may be understood by a non-pythonistas, but it allows you to write some python if you need right in the template without rewriting the entire sls in an other language
07:25 cberndt joined #salt
07:25 Sunstar joined #salt
07:27 JlRd joined #salt
07:30 flyboy joined #salt
07:38 linjan joined #salt
07:46 netw_ joined #salt
07:56 jchen joined #salt
07:57 Mindfartio joined #salt
07:57 stoogenmeyer__ joined #salt
07:57 NikolaiToryzin joined #salt
07:58 badon_ joined #salt
07:58 palantir joined #salt
07:58 Cottser|away joined #salt
07:59 Xiao joined #salt
08:00 Yoda-BZH` joined #salt
08:01 Yoda-BZH joined #salt
08:01 djinni` joined #salt
08:02 gyre007 joined #salt
08:02 malinoff joined #salt
08:03 Karunamon joined #salt
08:03 crazysim joined #salt
08:03 freelock joined #salt
08:03 shoma joined #salt
08:05 ryuhei joined #salt
08:05 brianfeister joined #salt
08:06 TrafficMan joined #salt
08:06 paha joined #salt
08:14 TheThing joined #salt
08:16 gfa joined #salt
08:18 gfa joined #salt
08:19 jagardaniel joined #salt
08:33 stooj joined #salt
08:41 glyf joined #salt
08:56 trikke joined #salt
08:57 trikke joined #salt
08:57 dkrae joined #salt
08:57 trikke joined #salt
08:58 davidone joined #salt
09:04 heaumer hi; i have a /srv/salt/_modules/main.py and a /srv/salt/_modules/test/bla.py; both synced to minions. main.py does an "import test.bla" which fails: http://paste.awesom.eu/T7UX
09:04 heaumer does somebody have an idea about it?
09:05 heaumer http://paste.awesom.eu/lTTk, http://paste.awesom.eu/hAcQ
09:09 Mso150 joined #salt
09:10 Furao keep _modules and _states flat
09:11 Furao _modules/test_bla.py
09:11 slafs joined #salt
09:11 slafs left #salt
09:13 delinquentme joined #salt
09:16 linjan joined #salt
09:22 heaumer Furao: it synced modules.main & modules.test_bla, but still: ImportError: No module named test_bla
09:22 TheThing joined #salt
09:23 Mindfart joined #salt
09:24 Puckel_ joined #salt
09:25 ether_ heaumer: maybe you should add the module directory to sys.path
09:26 trikke joined #salt
09:26 ether_ something like that in the top of your module file: sys.path.append(os.path.dirname(os.path.abspath(__file__)))
09:27 ether_ (that will add the /var/cache/salt module directory to your path, then you can do the import anyway that you want)
09:27 Furao but the thing is that _modules are eval(open(‘test_bleh.py’).read())
09:27 Furao _modules isn’t in sys.path
09:28 Furao you should use __salt__[‘test_bla.func_name’](*args, **kwargs) instaed of import
09:29 ether_ yeah, if your module is exposed, use __salt__
09:29 heaumer hm, ether_'s trick worked
09:30 heaumer ok for the exported module
09:31 ether_ but if you have a complete module in a subfolder, i don't know how to do it without this trick
09:36 heaumer the __salt__ trick? :p
09:37 ether_ the sys.path trick, __salt__ will only work if you have a flat directory as Furao said
09:38 N-Mi joined #salt
09:38 N-Mi joined #salt
09:42 heaumer ok: i tried the sys.path with flat and it worked, but it doesn't with subdirectory
09:42 heaumer let me check
09:44 zloidemon joined #salt
09:52 heaumer http://paste.awesom.eu/2Lxl, the other didn't change
09:52 heaumer and still the ImportError: No module named bla
09:52 heaumer (flat files works though)
09:54 eagles0513875 joined #salt
09:57 heaumer http://paste.awesom.eu/jnQf&hl=python works thought
09:57 ether_ yeah, that was i wanted to say
09:58 ether_ you need to add to your sys.path every folder you need to import
09:58 fla joined #salt
09:59 ether_ if you need a file in at the same level as the other salt module, use the first sys.path or __salt__ if the module is loaded by salt
09:59 ether_ else you'll need to add to your path every subfolder
09:59 ether_ sys.path.append(os.path.join(os.path.dirname(os.path.abspath(__file__)), 'submodule'))
09:59 stevednd joined #salt
10:02 jrluis joined #salt
10:05 otter768 joined #salt
10:07 heaumer ok, thanks ether_, Furao :-)
10:07 CeBe joined #salt
10:23 JlRd joined #salt
10:39 trikke joined #salt
10:54 cDR joined #salt
10:55 cDR Hi, anyone got a changelog for the upcoming Lithium release?
11:00 bhosmer_ joined #salt
11:08 babilen cDR: "git log" ;)
11:10 cDR Where is the marketing? :)
11:13 babilen cDR: There is none (at least I couldn't find release notes for 2015.2
11:13 babilen And, btw, I now *really* don't understand the versioning scheme anymore.
11:17 babilen I mean they tagged 2014.7 in July and therefore used .7 .. 2015.2 has already been tagged and should, therefore, be 2014.12, but they used 2015.2 instead which is, I presume, the expected release date. I know they will release that one in march so .. ;)
11:19 trikke joined #salt
11:21 cDR Year based versions always sound fancier
11:23 xliiv joined #salt
11:26 elfixit joined #salt
11:27 babilen No, that makes perfect sense, but they change the logic for the tagging all the time.
11:29 babilen 2014.7 was created in June 2014, but released in November (and should therefore have been 2014.11), while 2015.2 was created in December (and should therefore have been 2014.12), but was named 2015.2 because it is *expected* to be released in February
11:34 Konijntjes joined #salt
11:42 ggoZ joined #salt
11:43 hebz0rl joined #salt
11:45 aqua^mac joined #salt
11:53 trikke joined #salt
11:53 cDR Saltstack should really do more marketing, it feels wrong looking for changes, present a roadmap on the website or something to promote the next release
11:59 diegows joined #salt
12:00 bhosmer_ joined #salt
12:02 pentabular joined #salt
12:06 otter768 joined #salt
12:12 stoogenmeyer_ joined #salt
12:16 bhosmer_ joined #salt
12:16 eliasp the usual problem with tech companies… nobody is interested in the "boring" marketing work :)
12:16 elmar555 joined #salt
12:19 elmar555 Can anyone help me out, I'm trying install the mysql-5.6 on Ubuntu 14.04, using the mysql-formula. I've added my pillar and specified mysql-server-5.6 but this has no effect and it still installs 5.5 (other pillar values get carried through though)
12:21 eliasp elmar555: does "salt your-ubuntu-minion pillar.get mysql" return the correct values?
12:23 elmar555 returns nothing
12:23 eliasp did you assign the mysql pillar to your minion through a corresponding pillar top.sls?
12:24 elmar555 yes, I have
12:25 elmar555 when i do state.highstate, i get the diff of the changed values for mysql
12:26 elmar555 File /etc/mysql/my.cnf updated
12:27 eliasp do these changes reflect what you defined in your pillar?
12:27 elmar555 double checking now
12:27 elmar555 yep, they do
12:28 eliasp ok, so everything looks fine except of the installed mysql-server version (5.5 instead of 5.6)?
12:28 elmar555 yep
12:28 trikke joined #salt
12:28 babilen The pillar should still be accessible
12:28 eliasp does a manual "salt your-minion pkg.install mysql-server-5.6" work?
12:29 eliasp right… what babilen says… the fact you're not seeing the results of "pillar.get mysql" is a bit weird
12:30 babilen And since when is mysql-server-5.6 in lucid?
12:30 elmar555 running the command
12:30 elmar555 installs fine
12:31 eliasp babilen: 14.04 → trusty → http://packages.ubuntu.com/trusty/mysql-server-5.6
12:31 elmar555 yep, it's trusty
12:32 elmar555 still nothing when I run, salt '*' pillar.get mysql
12:32 jerrcs lucid? whoa.
12:32 babilen Ah, yeah ... *sigh*
12:32 eliasp elmar555: ok, so I'd say it comes down to pillar issues… once your "pillar.get mysql" returns proper values, it "should work"
12:32 elmar555 https://github.com/saltstack-formulas/mysql-formula/blob/master/pillar.example
12:32 eliasp elmar555: need to take care of some other stuff right now… maybe someone else can help you debug this
12:32 bhosmer_ joined #salt
12:32 elmar555 i copied the example, have a look at the server.sls file right now
12:33 babilen elmar555: Could you paste your pillar, the top.sls too? What does "salt 'the-minion' pillar.items" give you? (redact private information in there please)
12:33 elmar555 sorry having a look*
12:34 elmar555 so pillar.items gives me this: http://pastebin.com/Y1Uwc2Wn
12:35 bhosmer_ joined #salt
12:37 elmar555 http://pastebin.com/acAuacbh mysql pillar
12:37 babilen So it does work
12:38 babilen (oh, and consider using a less horrible pastebin such as http://refheap.com)
12:38 babilen That looks fine. I'd check the minion logs (in debug mode) for what is actually happening on the minion
12:38 elmar555 sure, sorry
12:40 elmar555 let me try first running one more time
12:41 lytchi joined #salt
12:46 hebz0rl joined #salt
12:51 elmar555 i am going to give this another go tomorrow, thanks for your help babilen and eliasp
12:51 bhosmer_ joined #salt
12:53 Furao joined #salt
13:00 pentabular joined #salt
13:06 jaimed joined #salt
13:09 stoogenmeyer__ joined #salt
13:10 agend joined #salt
13:11 SheetiS joined #salt
13:18 glyf joined #salt
13:19 jrluis joined #salt
13:24 yomilk joined #salt
13:27 ndrei joined #salt
13:29 lothiraldan joined #salt
13:30 delinquentme joined #salt
13:31 trikke joined #salt
13:33 aqua^mac joined #salt
13:37 jrluis joined #salt
13:39 DaveQB joined #salt
13:40 thehaven joined #salt
13:51 glyf joined #salt
13:58 lothiraldan_ joined #salt
14:02 sgregory_ joined #salt
14:07 otter768 joined #salt
14:10 netw joined #salt
14:14 sgregory_ joined #salt
14:16 paha joined #salt
14:17 ryuhei joined #salt
14:17 lothiraldan_ joined #salt
14:19 sgregory_ joined #salt
14:25 sgregory_ joined #salt
14:26 sgregory_ joined #salt
14:27 mpanetta joined #salt
14:27 thawes joined #salt
14:27 gunhu joined #salt
14:28 gunhu Hi
14:28 jeffspeff joined #salt
14:31 younqcass joined #salt
14:33 mpanetta_ joined #salt
14:34 sgregory_ joined #salt
14:34 ujjain joined #salt
14:37 yomilk joined #salt
14:37 perfectsine joined #salt
14:39 sgregory_ joined #salt
14:40 sgregory_ joined #salt
14:40 linjan joined #salt
14:43 acabrera joined #salt
14:47 murrdoc joined #salt
14:47 mpanetta_ joined #salt
14:47 aquinas joined #salt
14:48 sgregory_ joined #salt
14:54 lothiraldan_ joined #salt
14:54 sgregory_ joined #salt
14:55 nitti joined #salt
14:58 ajolo joined #salt
14:59 sgregory_ joined #salt
15:03 murrdoc joined #salt
15:04 SheetiS joined #salt
15:05 sgregory_ joined #salt
15:08 KennethWilke joined #salt
15:09 schlueter joined #salt
15:10 lothiraldan_ joined #salt
15:12 analogbyte iggy: du you remember me and my issues with minions repeating highstates over and over again? my minions are looping the highstate again, so it has not been some reactor issue... any more suggestions?
15:13 analogbyte as before, it's just reconnecting to the master all the time, running a highstate every time
15:14 davet joined #salt
15:14 murrdoc what do you have in 'startup_states' in /etc/salt/minion
15:15 sgregory_ joined #salt
15:17 andrew_v joined #salt
15:18 analogbyte murrdoc: nothing
15:18 TheThing_ joined #salt
15:18 murrdoc interesting
15:18 analogbyte murrdoc: my reactor section on the master is also empty
15:18 analogbyte as in salt-call pillar.items empty
15:19 murrdoc and the minion files have empty startup_states too ?
15:19 analogbyte murrdoc: even if there was, the logs from those highstates show no reasone for that minion to reconnect....
15:19 analogbyte like a service restart or whatever
15:20 analogbyte so far, it has been 5 different minions from a pool of some 85 total
15:20 analogbyte never at the same time up to now...
15:20 sgregory_ joined #salt
15:21 sgregory_ joined #salt
15:21 murrdoc thats not good
15:21 xliiv joined #salt
15:22 murrdoc can u shut down the reactor
15:22 murrdoc or has it gone Nucular
15:22 murrdoc :D sorry too easy
15:22 analogbyte murrdoc: :D
15:22 analogbyte I think it is completely of
15:22 analogbyte f
15:22 aqua^mac joined #salt
15:22 analogbyte also, no startup states:
15:23 murrdoc and mnions cant run commands on other minions
15:24 analogbyte nope, I did no config on that... this particular minion can callsome runners, but the other couldn't, so thats probably no issu
15:24 babilen analogbyte: I'd also take a look with the eventlisten script
15:24 analogbyte I'm writing a bug report atm, I'm fed up with this occuring all the time...
15:25 analogbyte babilen: I will, but I think all events show up in the masters debug log... so it's just the typical reconnect thing
15:25 analogbyte also, can this even be an issue with no reactor enabled?
15:25 iggy I don't think you can disable the reactor completely
15:26 analogbyte iggy: yeah, but the config is completely empty
15:26 iggy the reactor can be set in multiple spots
15:27 sgregory_ joined #salt
15:27 analogbyte I even removed the reactor stuff from my repo instead of disabling it only... also, any file.managed regarding reactor is now absent
15:27 analogbyte iggy: yes, but nothing appears in the pillar, so there is nothing loaded
15:27 analogbyte to my knowledge, any loaded config will appear in the masters pillar
15:31 pdayton joined #salt
15:32 iggy hopefully your bug gets looked at
15:32 iggy what's the #?
15:33 TheThing joined #salt
15:37 analogbyte none yet, still putting stuff together
15:37 toastedpenguin joined #salt
15:43 jtanner joined #salt
15:44 acabrera joined #salt
15:44 sgregory_ joined #salt
15:45 TheThing joined #salt
15:46 kermit joined #salt
15:47 dude051 joined #salt
15:49 analogbyte iggy: it's #19276
15:50 sgregory_ joined #salt
15:56 glyf joined #salt
15:58 sgregory_ joined #salt
16:00 pentabular joined #salt
16:03 sgregory_ joined #salt
16:07 otter768 joined #salt
16:08 conan_the_destro joined #salt
16:11 Ozack1 joined #salt
16:12 Konijntjes joined #salt
16:16 sgregory_ joined #salt
16:16 jngd joined #salt
16:27 nullptr joined #salt
16:27 jeremyr joined #salt
16:33 sgregory_ joined #salt
16:35 freimer joined #salt
16:35 andrej_ joined #salt
16:36 arnoldB joined #salt
16:36 Ssquidly joined #salt
16:37 __alex joined #salt
16:40 theologian joined #salt
16:42 sgregory_ joined #salt
16:43 Furao joined #salt
16:48 theo joined #salt
16:48 UtahDave joined #salt
16:50 ekristen joined #salt
16:55 seanz joined #salt
16:57 sgregory_ joined #salt
16:59 giannello joined #salt
17:02 ekristen joined #salt
17:02 sgregory_ joined #salt
17:11 aqua^mac joined #salt
17:11 spookah joined #salt
17:12 KyleG joined #salt
17:12 KyleG joined #salt
17:13 djn joined #salt
17:16 enclyp joined #salt
17:23 dude051 joined #salt
17:35 rypeck joined #salt
17:35 forrest joined #salt
17:39 Gareth morning morning
17:41 randomuser joined #salt
17:42 cleme1mp joined #salt
17:42 * randomuser is looking at things to manage a bunch of windows workstations (and sundry servers of varying OSen) - just idling now, but will probably develop stupid questions soon
17:42 brianfeister joined #salt
17:43 Gareth anyone running the lastest 2014.7 from Git?
17:43 UtahDave morning gareth
17:43 Gareth UtahDave: hey :) hows it going?
17:43 UtahDave pretty good!
17:46 stephas joined #salt
17:46 cleme1mp joined #salt
17:47 cleme1mp joined #salt
17:49 nullptr apologies for the basic question, but new to salt and curious about the distinction between states and modules...
17:49 nullptr ...for example, on a win32 machine there exists user.present and user.setpassword -- the former from states/user.py and the latter from modules/win_useradd.py
17:51 nullptr or, something like win_firewall.py exists in both states and modules ... what [high level] dictates where code should land? i find myself grepping them both as a flat namespace when trying tounderstand something at the moment.
17:51 eliasp nullptr: a module can be seen as "backend for states doing the ugly groundwork", while states are the caking on top which interact with the states you defined in your SLS and translate your definitions into module calls to let them do the ugly work
17:52 iggy you normally will use states in your sls files and modules on the command line (i.e. salt '*' pkg.list_upgrades)
17:52 bdols joined #salt
17:53 iggy http://docs.saltstack.com/en/latest/salt-modindex.html is a helpful page
17:54 nullptr that makes sense -- win_firewall having 'disabled' in states vs. 'disable' in modules fits that model
17:59 sgregory_ joined #salt
18:02 Gareth UtahDave: Have you heard any reports of issues with 2014.7 starting up because of import errors?
18:02 UtahDave Hm. I haven't yet, but that doesn't mean something didn't pop up.  I'm guessing you're seeing some import errors?
18:02 Gareth I am :)
18:02 UtahDave lemme see if I can cause that.  So the tip of the 2014.7 branch?
18:03 Gareth yeah.  Just updated this morning.
18:03 iggy we had import errors when we went from 2014.1 to 2014.7 and didn't restart the service properly
18:04 Gareth I think this might be different.  services aren't running, completely cleared out Salt and reinstalled from git source.
18:05 sgregor__ joined #salt
18:05 UtahDave Gareth: salt-master or salt-minion?
18:05 Gareth UtahDave: both.
18:05 Gareth same import error on both
18:05 Gareth ImportError: No module named cli.caller
18:06 UtahDave hm. worked for me just now.   did you clear out all pyc files, by chance?
18:06 Gareth yeah.  cleared out everything.
18:06 UtahDave root@boucha:~# salt-master --version
18:06 UtahDave salt-master 2014.7.0-998-gcd1239a (Helium)
18:06 UtahDave is that the version you're on?
18:07 dave080991 joined #salt
18:07 Gareth I can't run that, same issue as starting up the maste.r
18:07 Gareth master too.
18:08 UtahDave Hm. path issue maybe?
18:08 otter768 joined #salt
18:08 Gareth pastebin: http://pastebin.com/XriH4Ewd
18:10 anotherZero joined #salt
18:11 forrest Does anyone know someone that works at Nexicom?
18:11 forrest Their fedora mirror is busted, and it's hosing the bootstrap script
18:11 forrest Their network director hasn't responded to my email either
18:11 robawt there's a hard dependency for it in the script?
18:12 steveoliver left #salt
18:12 forrest robawt: No, but it's getting marked as the best mirror
18:13 randomuser forrest, tell #fedora-admin
18:13 forrest randomuser: Cool will do
18:13 randomuser forrest, or better yet, file a ticket at https://fedorahosted.org/fedora-infrastructure/
18:14 cpt-oblivious_ joined #salt
18:15 forrest randomuser: Will do after I talk to them in the IRC. I even tried contacting the guys at nexicom without luck.
18:15 forrest randomuser: thanks
18:15 randomuser np
18:16 agend joined #salt
18:16 robawt forrest: ah bummer
18:18 forrest robawt: Yep it sucks, reoccurring issue as well it seems like from what I saw trolling some of the mailing lists.
18:18 nikogonz1 joined #salt
18:18 forrest Funny thing is the guy getting redirected there lives down the street from the university of waterloo :P
18:18 enclyp_ joined #salt
18:18 dave080991 anyone know how i can get salt to return all the nodes that are in my roster?
18:18 iggy dave080991: salt-run manage.up ?
18:19 wolog_ joined #salt
18:19 winterblack joined #salt
18:20 slafs joined #salt
18:20 slafs left #salt
18:21 slafs joined #salt
18:21 slafs left #salt
18:23 jeremyb joined #salt
18:26 scarcry joined #salt
18:28 hasues joined #salt
18:28 jayne_ joined #salt
18:29 lazybear joined #salt
18:29 Jimlad joined #salt
18:30 dstufft joined #salt
18:31 acabrera joined #salt
18:31 stevednd joined #salt
18:32 forrest thanks again randomuser, hopefully removing that from the list fixes it, and it doesn't get added back in since they don't seem to be able to keep their infrastructure up.
18:32 lempa joined #salt
18:33 torment joined #salt
18:33 forrest Been a while since I dealt with such a bad company in terms of contact, no way to talk to their admins, no twitter to contact them quickly, nothing.
18:34 rap424 joined #salt
18:34 dave080991 iggy: permission error
18:34 dave080991 salt-call --config-dir=/home/dave/salt manage.up
18:34 dave080991 [WARNING ] Although 'dmidecode' was found in path, the current user cannot execute it. Grains output might not be accurate.
18:34 dave080991 Function manage.up is not available
18:35 ndrei joined #salt
18:35 iggy I have a more "normal" salt setup where everything runs as root
18:35 iggy (via sudo)
18:36 steveoliver joined #salt
18:39 dave080991 i am using salt-ssh as a non-root user. what i am trying to do is push local code (using "git push") to all of my nodes (instead of sending a command like "git fetch; git pull -u" on the nodes themselves). anyone know if it's possible to do this with salt-ssh?
18:39 gngsk joined #salt
18:42 brianfeister joined #salt
18:42 sgregory_ joined #salt
18:45 Mso150 joined #salt
18:46 _JZ_ joined #salt
18:47 stoogenmeyer__ joined #salt
18:50 sgregory_ joined #salt
18:53 dave080991 i guess i could parse /home/dave/salt/roster and loop through the roster and run the git push command to each node
18:53 mohae joined #salt
18:56 Ryan_Lane joined #salt
18:58 snave joined #salt
18:59 pentabular joined #salt
19:00 aqua^mac joined #salt
19:00 Jimlad joined #salt
19:02 Gareth UtahDave: looks like it was something weird with my checked out version of 2014.7, deleted it and re-checked it out and it's all good now.
19:04 stephas joined #salt
19:05 jalbretsen joined #salt
19:05 jeremyr1 joined #salt
19:06 aron_kexp joined #salt
19:07 Jimlad joined #salt
19:09 jeremyr joined #salt
19:11 Konijntjes joined #salt
19:13 Jimlad joined #salt
19:17 dave080991 i hate chef
19:18 robawt haha
19:18 eliasp Gareth: "git reset --hard upstream/2014.7" might do this for you the next time
19:19 bhosmer_ joined #salt
19:19 Jimlad joined #salt
19:20 wendall911 joined #salt
19:21 CeBe1 joined #salt
19:21 nethershaw joined #salt
19:22 sgregory_ joined #salt
19:23 sgregory_ joined #salt
19:23 Gareth eliasp: Good tip.  Thanks.
19:25 delinquentme joined #salt
19:26 Jimlad joined #salt
19:29 aw110f joined #salt
19:31 Jimlad joined #salt
19:31 sgregory_ joined #salt
19:34 bhosmer_ joined #salt
19:36 Jimlad joined #salt
19:36 stephas joined #salt
19:37 sgregory_ joined #salt
19:37 Morbus joined #salt
19:42 Jimlad joined #salt
19:42 sgregory_ joined #salt
19:47 Jimlad joined #salt
19:48 sgregory_ joined #salt
19:54 Jimlad joined #salt
19:58 sgregory_ joined #salt
19:58 Jimlad joined #salt
20:02 sgregory_ joined #salt
20:03 Jimlad joined #salt
20:05 fishdust joined #salt
20:05 wnkz__ joined #salt
20:08 Jimlad joined #salt
20:08 Shaxxie joined #salt
20:08 sgregory_ joined #salt
20:09 Shaxxie hai again
20:09 otter768 joined #salt
20:09 Shaxxie fuck
20:09 Shaxxie this isn't i2p salt
20:12 geekatcmu Is there an easy way to apply a state IFF a specific other state has been applied?  I.e. add firewall rules for this service, but only if firewall rules are already asserted for this host?
20:12 druonysus joined #salt
20:12 Jimlad joined #salt
20:13 geekatcmu e.g., I'd want to have firewall rules allowing access to port 80 for a web server, but such rules shouldn't happen if the host isn't firewalled to begin with, like a server sitting inside the secure network.
20:13 sgregory_ joined #salt
20:14 geekatcmu (yes, I know, it's better to always have firewall rules, but that's a different fight/argument and not germane to my question)
20:16 eliasp geekatcmu: how do you define: "if the host isn't firewalled to begin with" ? does the firewall-ing happen via other salt states or through other external mechanisms?
20:16 geekatcmu that's a good question
20:16 geekatcmu We *could* have "firewalled" as external pillar data.
20:17 eliasp well, then it's relatively easy…
20:17 geekatcmu But while I'm littering firewall rules through various states, I want to have some flexibility there.
20:17 geekatcmu And it would be really convenient if I could say - if: firewall
20:18 eliasp just use Jinja conditionals {% if pillar['firewalled'] %} other state {% endif %}
20:18 Jimlad joined #salt
20:18 geekatcmu That makes sense, too.
20:19 UtahDave Gareth: sorry, I got pulled away and just checked my backlog.  glad you got that sorted out.
20:19 sgregory_ joined #salt
20:22 keerleb joined #salt
20:24 cberndt joined #salt
20:24 sgregory_ joined #salt
20:25 Jimlad joined #salt
20:28 dotz joined #salt
20:29 jrluis joined #salt
20:30 sgregor__ joined #salt
20:30 dotz Guys, what is the proper approach to parametrizing salt? For example, I have a state "checkout downloaded", that makes sure mercurial is installed and updates a checkout somewhere. I'd like to be able to parametrize it (turn it into some kind of function) using hg repo URL and branch name, preferably from pillar. Should I use jinja and {% include %} tag or are there any other options?
20:31 shoma joined #salt
20:32 forrest dotz: You can use something like version: {% salt['pillar.get']('mercurial:version', 'x.x.x') %}
20:32 iggy dotz: be a little more clear about what you're trying to achieve... not really sure you need any kind of include
20:34 Jimlad joined #salt
20:34 dotz iggy: Let's imagine I have a state checkout.updated that updates a mercurial checkout, using branch and URL parameters. I want to be able to use this one state in 2 or more projects, so this state can't use a pillar variable name, because this variable name will be different for every project.
20:34 dotz iggy: so I wonder, should I use jinja2's include or macro or does salt have anything for such situations?
20:34 aranhoide joined #salt
20:35 sgregory_ joined #salt
20:37 aw110f joined #salt
20:37 aranhoide I have this weird condition where if I run `salt-call state.highstate` from a minion everything works fine, but if I do `salt the-minion-id state.highstate` from the salt master the pip.installed states will error with 'State pip.installed found in sls boto is unavailable' (where boto is just the package name)
20:37 forrest aranhoide: Is pip installed on the machine?
20:38 aranhoide I have pip installed from pip, and highstate won't touch it either when run locally or remotely
20:38 Jimlad joined #salt
20:38 aranhoide forrest: yes, I originally installed it from apt-get, then `pip install --upgrade pip`, then uninstalled the apt-get package.  if I run python I can correctly import it
20:39 forrest aranhoide: on the minion itself, not the master? Sorry for not specifying
20:39 aranhoide on both
20:40 aranhoide pip --version says 6.0.3
20:40 aranhoide in both master and minion
20:40 forrest aranhoide: I'd start by running `salt the-minion-id state.highstate -l debug`
20:40 forrest see if that provides anything more
20:40 Cottser|away joined #salt
20:40 aranhoide I'll do that, thanks!
20:41 sgregory_ joined #salt
20:41 iggy dotz: why can't you use pillars for that data?
20:42 dotz iggy: I can. One project has pillar data in "project1" key, second has those in "project2". How do I parametrize the pillar variable name for a state?
20:42 dotz This is what I am asking about.
20:43 sinenitore joined #salt
20:43 iggy don't
20:43 iggy just call the key project
20:43 Jimlad joined #salt
20:44 dotz iggy: OK.
20:44 dotz iggy: except that I need two different project.s
20:45 dotz iggy: what do I do, call salt -I ?
20:45 glyf joined #salt
20:47 iggy why? Are you trying to do multiple checkouts on each node?
20:48 dotz iggy: yes.
20:48 dotz iggy: I want to share the same state (checkout_updated) between two or more projects.
20:49 sgregory_ joined #salt
20:49 dotz iggy: either this, or cp -R and duplicate whole tree of my salt states.
20:49 dotz ... just to replace some strings there.
20:49 aqua^mac joined #salt
20:49 Jimlad joined #salt
20:49 iggy make the "project" key a list and loop over all the entries
20:51 dotz iggy: I thought about this. Seems a bit overkill, but on the other hand, looks like salt supports this approach best.
20:51 numkem joined #salt
20:52 iggy I think that's probably the most commonly used way to solve this
20:54 iggy I have seen macro's used occasionally... but they aren't very common (and I personally think they are difficult to read in most cases)
20:54 sgregory_ joined #salt
20:54 dotz iggy: I agree.
20:54 Jimlad joined #salt
20:55 Ryan_Lane https://bootstrap.saltstack.org/ still doesn't work?
20:55 Ryan_Lane if I buy an SSL cert for saltstack inc, will you use it?
20:56 iggy has it ever worked?
20:56 Ryan_Lane I'm doing a book review that uses 'curl --insecure -L http://bootstrap.saltstack.org -o install-salt.sh'
20:56 Ryan_Lane that makes me want to stab
20:57 iggy isn't that just a proxy to the github page?
20:57 dotz Ryan_Lane: wget | sudo sh is insecure by definition.
20:57 UtahDave Ryan_Lane: that should work. Let me ask what's going on
20:57 iggy I mean, it'd be nice I guess, but it's not exactly adding any security
20:57 Ryan_Lane dotz: agreed, but if it's being recommended, at the very minimum use https
20:57 Ryan_Lane using http lets people MITM the redirect
20:58 Ryan_Lane which would let them install anything they wante
20:58 iggy saltstack.com works
20:58 diegows joined #salt
21:00 dotz Ryan_Lane: why?
21:00 dotz Ryan_Lane: what does it change?
21:01 dotz Ryan_Lane: it is as wise as running an unsigned binary from the web on Windows with AV disabled.
21:01 Ryan_Lane using https at least makes it impossible (or very difficult) to MITM
21:01 UtahDave Ryan_Lane: I was told to use https://bootstrap.saltstack.com
21:01 Jimlad joined #salt
21:01 dotz Ryan_Lane: it is easier than you think.
21:01 Ryan_Lane UtahDave: hm. weird. I tried it earlier and it gave me an error
21:02 dotz ... mitmproxy in Python.
21:02 dotz Full docs on proxying SSL.
21:02 sgregory_ joined #salt
21:02 Mso150 joined #salt
21:02 Ryan_Lane dotz: MITM for curl/wget is difficult
21:02 UtahDave dotz: but that only works if you've accepted the mitmproxy's certs, right?
21:02 Ryan_Lane UtahDave: yep
21:02 Ryan_Lane if it was easy, we'd all be screwed
21:03 iggy bootstrap...com works, bootstrap...org doesn't
21:03 iggy so sounds like someone needs to change their book
21:03 dotz There were cases in the past.. some OSS project's servers were compromised. And there were cases with SSL problem.s
21:04 numkem I keep reading the docs, github and some really weird blog posts about and I can't figure out why trying to use the docker modules for doing a docker pull doesn't work... Just ends up with 'state docker.pulled found in sls is unavailable'
21:04 Ryan_Lane iggy: ah. gotcha. I'll put that in the review
21:04 dotz I'd rather login manually and apt-get everything than run wget | sudo sh
21:04 dotz numkem: salt-call state.sls docker.pulled maybe ?
21:05 UtahDave numkem: restart the salt-minion daemon after installing the docker packages
21:06 Ryan_Lane UtahDave: saltstack should get a multi-san wildcard cert
21:07 Ryan_Lane you can get *.saltstack.com with a SAN of saltstack.com, *.saltstack.org, saltstack.org
21:07 Jimlad joined #salt
21:07 iggy those are actually tricky to get
21:07 Ryan_Lane digicert will gladly do it
21:07 iggy at least digicert doesn't (like to) do that
21:07 Ryan_Lane you get two wildcard certs
21:07 LeProvokateur joined #salt
21:07 numkem dotz, UtahDave: I've restarted the minion service and same error... How can I make it more verbose?
21:07 sgregor__ joined #salt
21:07 Ryan_Lane then you ask them to generate a combined
21:07 UtahDave Hm, interesting. I know we have a wildcard cert, but not sure about with a SAN.  will find out
21:08 dotz numkem: run salt-master with -l debug, but that will spew a lot of info
21:08 dotz numkem: or salt-call -l info, works too.
21:08 Ryan_Lane so, you get a *.saltstack.org wildcard (which will have a saltstack.org SAN) and a *.saltstack.com (which will have a saltstack.com SAN), then ask them to combine them
21:08 UtahDave numkem: you probably don't have all the dependencies required for the docker module to work.  what's the output of    salt '<your minion>' test.version    ?
21:09 UtahDave that's cool, Ryan_Lane. I'll see about having our infra people get that set up.
21:09 ajolo joined #salt
21:09 numkem at least digicert doesn't (like to) do that 1.dev.atk:
21:09 numkem 0.17.5
21:09 numkem what the... I didnt copy that
21:10 Ryan_Lane :D
21:10 numkem anyway 0.17.5
21:10 iggy I copied it for you
21:10 aw110f_ joined #salt
21:10 whiteinge Ryan_Lane: we (tried to) phase out all occurrences of the .org a while back. everything should point at a .com (sub-)domain now.
21:10 Ryan_Lane gotcha
21:10 numkem i might be playing with fire but salt-master comes from epel on centos 6.6 and minion is ubuntu 14.04
21:11 UtahDave numkem: I don't think the docker stuff is in 0.17.5.
21:12 numkem interestig... thats the machine i built through foreman...
21:12 Jimlad joined #salt
21:13 numkem what do you know... the script used by salt-cloud is using a ppa
21:16 numkem and now its working, thanks a lot for everything, sorry to bother
21:16 Jimlad joined #salt
21:20 sgregory_ joined #salt
21:20 numkem Salt is the best thing since sliced... Slat?
21:21 numkem ill show myself the door
21:21 numkem especially with a typo...
21:22 whiteinge :)
21:22 Jimlad joined #salt
21:24 numkem I'm trying to wrap my head around deploying new nodes with the minion. I got it working with foreman in a short time through the salt plugin but I feel like there must be a cleaner way.
21:25 numkem What do you guys use? cobbler?
21:25 aranhoide forrest: -l debug didn't ring any bells either
21:26 sgregory_ joined #salt
21:26 aranhoide btw `salt --version` prints "salt 2014.1.10 (Hydrogen)"
21:27 aranhoide (re-asking since there seem to be more active people at this time): I have this weird condition where if I run `salt-call state.highstate` from a minion everything works fine, but if I do `salt the-minion-id state.highstate` from the salt master the pip.installed states will error with 'State pip.installed found in sls boto is unavailable' (where boto is just the package name)
21:27 ndrei joined #salt
21:28 aranhoide pip 6.0.3 is installed in both master and minions
21:28 Jimlad joined #salt
21:29 UtahDave numkem: I haven't used the new foreman stuff yet, but I use salt-cloud extensively.
21:29 UtahDave where did you find that typo, numkem?
21:30 numkem in the poor joke I tried to do
21:32 UtahDave oh, sorry. I'm slow sometimes.  :)
21:32 numkem I'm gonna use proxmox and since I want to use docker, I have to use KVM VMs instead of the supported openvz through the provider
21:32 scarcry joined #salt
21:32 numkem So I think my only option would be to do the VMs manually than boot them through pxe and install
21:35 Ryan_Lane numkem: I was considering using salt-api that the minion triggers when it starts
21:35 Jimlad joined #salt
21:36 Ryan_Lane salt-cloud is a good option, if you use it
21:37 iggy there's the saltify provider
21:37 numkem to be honest I only read about salt through the week-end and than started using it today so I will have to do some reading about salt-api
21:38 singularo joined #salt
21:39 iggy yeah, I've been using it for a year now and still find new features every week or so
21:40 Jimlad joined #salt
21:40 Ryan_Lane interesting. didn't know about the saltify project.
21:41 Ryan_Lane I really want to avoid ssh, though
21:41 iggy yeah, it all kind of depends on what your setup is
21:42 iggy if you're using a cloud service, you can usually do it in an image or via startup scripts that a number of cloud providers support
21:43 iggy if you are all pure hardware, do it in your kickstart/pxe install, etc.
21:43 sgregory_ joined #salt
21:43 iggy I lucked out, we use gce
21:44 Ryan_Lane I'm using cloud providers, but you can't handle the key management in the startup scripts
21:44 Ryan_Lane I install salt itself that way
21:44 Ryan_Lane I'm using masterless right now anyway, so it's not a big deal
21:44 numkem im stuck on metal and old raid-less poweredge 1950...
21:45 Jimlad joined #salt
21:45 * iggy doesn't admit how he handles key mgmt
21:46 sgregory_ joined #salt
21:47 Mso150 joined #salt
21:50 Jimlad joined #salt
21:50 mapu joined #salt
21:51 whiteinge fwiw, salt-api recently got a helpful addition for key management when bootstrapping: http://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html#salt.netapi.rest_cherrypy.app.Keys.POST
21:53 whiteinge (current implementation is a little simplistic. features/feedback welcome.)
21:58 iggy is that in 2014.7 or just devel?
21:58 iggy nvm
22:00 Jimlad joined #salt
22:03 murrdoc joined #salt
22:05 Jimlad joined #salt
22:06 ggoZ joined #salt
22:06 zarcos joined #salt
22:07 whiteinge It would be nice to avoid having to pass salt-api creds there. (Even for a single-purposed bootstrap-only user.) Something like a one-time-password, maybe. Not sure.
22:08 iggy seems like you could probably rig up something with a different eauth plugin?
22:10 Jimlad joined #salt
22:10 otter768 joined #salt
22:12 meylor joined #salt
22:14 Jimlad_ joined #salt
22:18 murrdoc joined #salt
22:20 aranhoide I just installed 2014.7.0 (to see whether that would fix another problem) and when I try and run any salt command I get "pkg_resources.DistributionNotFound: requests>=1.0.0", although I have latest requests library installed through pip (Ubuntu 14.10)
22:20 Jimlad joined #salt
22:21 aranhoide The latest salt-specific line in the traceback is the first one:   File "/usr/local/bin/salt", line 5, in <module>
22:21 aranhoide from pkg_resources import load_entry_point
22:22 quantumriff joined #salt
22:23 iggy aranhoide: is that pip for python2?
22:23 aranhoide iggy: yes, 2.7.3
22:23 aranhoide pip 6.0.3 from /usr/local/lib/python2.7/dist-packages/pip-6.0.3-py2.7.egg (python 2.7)
22:24 quantumriff I need to make up a script, that will backup a base directory, delete files older than X days, etc, and push it to all minions.  Except that I have a few servers, where the base directory won't match the pattern, or I may want different numbers for X days old.
22:24 dstufft aranhoide: what version of setuptools
22:24 iggy does your system python know to look in /usr/local for modules?
22:24 quantumriff would I be best off writing the script as a jinja template, then using pillar data to override it?
22:24 quantumriff or am I going about it the wrong way?
22:25 Jimlad joined #salt
22:25 aranhoide iggy: yes, root@cloudmaster:~# python -c "import pip; print pip.__file__"
22:25 aranhoide /usr/local/lib/python2.7/dist-packages/pip-6.0.3-py2.7.egg/pip/__init__.pyc
22:25 aranhoide dstuff: setuptools version 0.6
22:26 aranhoide dstufft: ^ (sorry about the misspelling)
22:26 dstufft aranhoide: is requests installed via pip or via apt-get
22:26 aranhoide pip
22:26 iggy you want to test the requests import, not the pip import
22:27 dstufft aranhoide: probably you installed from a wheel file then, and the old setuptools doesn't understand the metadata provided by wheel files, so it doesn't see anything installed as a wheel as installed
22:27 dstufft probably
22:27 diegows joined #salt
22:27 dstufft you can work around it by either upgrading setuptools or reinstalling requests with --no-use-wheel to turn off the wheels
22:28 aranhoide stufft: upgrading setuptools did it, thanks!!
22:28 aranhoide dstufft ^
22:28 aranhoide thanks iggy, as it turns out, the requests module imported fine too
22:29 iggy glad you got it sorted out
22:29 aranhoide this might be related to my original problem too; I'll try and test Hydrogen with an updated setuptools
22:30 meylor is there a way to pass and argument for the maps.conf file? such as dev, test etc?
22:30 Jimlad joined #salt
22:37 enclyp joined #salt
22:38 aqua^mac joined #salt
22:39 mgw joined #salt
22:40 mgw so, I'm working on an etcd formula for etcd 2.0 -- I want it to be flexible in such a way that the same formula could be used to deploy multiple instances of etcd on the same system
22:41 mgw so I need multiple etcd profiles in pillar
22:41 mgw What is the latest convention on that sort of thing?
22:41 mgw etcd.xxx:
22:41 mgw and etcd.yyy:
22:41 mgw ?
22:41 iggy I don't know that there are any formulas that do that
22:42 aranhoide has the syntax for pillars in jinja templates changed from 2014.1.10 to 2014.7.0?  that is, should {{ pillar['my_key'] }} still work?
22:42 babilen etcd: $SOMEID: - ... $SOEMOTHERID: - .... mabe?
22:42 iggy aranhoide: if my_key is set... but you're probably better off using pillar.get with a default value
22:44 aranhoide I get a weirder error I think: data failed to compile ---- Rendering SLS 'base:salt_minion' failed: Jinja variable 'dict object' has no attribute 'salt_version'
22:44 aranhoide is this the error I should get if the key was just missing?
22:44 aranhoide I'll try get though..
22:45 babilen aranhoide: Is "my_key" == "salt_version" ?
22:45 aranhoide babilen: yes
22:45 mgw babilen, I thought abou that -- but it should default to a logical default profile
22:45 mgw so I was thinking etcd: would be the default
22:46 babilen aranhoide: And have you defined salt_version in your pillar (at root level) ?
22:46 mgw and putting other profiles inside the default profile would be a bit odd
22:46 aranhoide babilen: I have it defined for this particular minion, yes.  I'm not sure what you mean by "at root level"
22:47 babilen mgw: Sorry, I don't quite understand what you mean by that, but the idea is essentially inspired by the user formula (and other formulas that follow that pattern)
22:47 mgw Maybe my use case is too specific to try to generalize
22:47 babilen aranhoide: That it is not, say, "salt:salt_version" or so. And "salt $that_minion pillar.get salt_version" returns without complaining?
22:47 mgw In my case I need two totally parallel instances of etcd
22:48 mgw one with the default datadir, init file, ports, etc
22:48 mgw and one with customized ones
22:48 babilen mgw: Yeah (just like you can have two users on a system) -- why don't you define each independently in your pillar and then simply loop over them ?
22:48 mgw But I want to use the same formula for both
22:49 aranhoide babilen: yes, it does return without complaining... that said, using .get() got rid of the error
22:49 quantumriff can I use pillars inside pillars?
22:49 mgw actually, now that I think this through.... I want one formula to be able to provide parameters to the etcd formula
22:49 babilen mgw: Ah, I get what you are after now. You essentially want to write a "normal" etcd formula, but *also* use that formula to install yet another instance.
22:49 babilen quantumriff: no
22:50 mgw babilen: correct
22:50 quantumriff ie, client: 'acme' basedir: '/opt/app{{ client }}'
22:50 quantumriff bummer
22:50 mgw and I want that other instance to have its port, datadir, etcd dictated by the formula including the etcd formula
22:51 mgw i added something long ago regarding vars and includes
22:51 aranhoide babilen: erm... but pillar.get returns the wrong value (the one I had set before upgrading to 2014.7.0)... so maybe something changed about how you specify pillars
22:51 babilen mgw: Well, that wouldn't work as most formulas assume that you want to install a service only *once* or explicitly support installing/creating multiple instances. But why don't you go with my idea ... ?
22:51 mgw but I don't even remember exactly what it was
22:51 mgw I added it to salt core that is
22:51 aranhoide I mean, if I call `salt the-minion-id pillar.get salt_version`
22:51 babilen mgw: You could have: etcd: default_install: [] other_totally_different_one: - foo: bar ...
22:51 mgw as far as pillar goes, true
22:52 aranhoide I get 2014.1.10, while I expect 2014.7.0
22:52 mgw but now that I think about, i don't want totaly_different_one to be defined in pillar at all
22:52 * babilen chuckles
22:52 mgw I want to pass the params to the formula in the include
22:52 babilen why?
22:52 babilen (do I want to know?)
22:52 mgw lol
22:53 mgw the non-standard instance is a part of another service
22:53 mgw in the same way lxc and libvirt firee up dnsmasq instances
22:54 mgw so i might not even use the default formula and do it all in the formula for that other (in-house) service
22:54 babilen And define values in the pillar for *that* service
22:54 babilen Yeah, that would be one approach if you want to tie them together
22:55 mgw yeah, i'll do that
22:55 aranhoide OK, restarting both the master and minion services seems to have fixed this (I thought I had done this, but apparently I didn't; sorry for the noise)
22:55 mgw I'll use etcd.install formula
22:55 mgw but it won't configure anything
22:55 babilen But then you could also just depend on the standard formula and add support for multiple instances and simply define it in pillars
22:55 mgw the extra instance will need a custom init script anyway, not the package installed one
22:56 mgw as it will need to point to the non-standard /etc/default
22:56 babilen I mean the main discussion boils down to: Formulas require me to use top-level keys while I would like to describe semantically larger "services" in a single pillar. As I cannot reference pillars from pillars how would I go about this?
22:56 babilen (similar for states)
22:56 mgw I actually can do intra-pillar lookups, but not very well
22:57 babilen I am under the impression as if you should just add a YOURSERVICE.etcd state and forget about the formula in that case though
22:57 mgw yes, that's what I'm going to do
22:57 babilen Salt needs support for static "pre-pillars"
22:57 mgw and MYSERVICE formula will include just the install part of the etcd formula
22:57 iggy set context 1 {% from file import foo with context %} ... do stuff
22:57 iggy then set context2 and repeat
22:59 aw110f_ joined #salt
23:06 foulou joined #salt
23:15 ckao joined #salt
23:18 quantumriff one last pillar question:  if I set the value to a string, can I use default like this (ie, if its not set for this minion?)
23:18 quantumriff basedir: {{ salt['pillar.get']('basedir', '')|default('/app???')}}
23:19 quantumriff also, is that valid to return the ???'s, or will salt want me to escape them?
23:19 mgw quantumriff: why not just put the default in pillar.get's args?
23:20 quantumriff I don't know that much about pillar.get, and am finding a bit too much information
23:20 mgw unless you think pillar.get will have a 'basedir' key that is None or empty
23:20 quantumriff is that the second paramter?
23:20 mgw yes
23:20 mgw where you have the empty str
23:20 quantumriff well, crap.. that makes it easier :)
23:20 mgw basedir: {{ salt['pillar.get']('basedir', '/app???')}}
23:20 quantumriff excellent!
23:20 mgw I don't think the ??? will cause you any trouble
23:21 quantumriff thank you very much for your help
23:21 mgw np
23:21 mgw http://docs.saltstack.com/en/latest/ref/states/vars.html#pillar
23:22 Corey UtahDave: I blame you personally for the existance of a global failhard.
23:22 geekatcmu You know what my least favorite salt error is?
23:22 UtahDave lol, I think that existed before me, my man!   :)
23:22 geekatcmu State 'firewall_iptables_pkg' in SLS 'firewall' is not formed as a list
23:25 Corey UtahDave: My client uses it globally, and it's been masking problems in production for months.
23:30 UtahDave huh, that's interesting.  Wouldn't it cause problems to show up when running a highstate?
23:31 brianfeister joined #salt
23:32 Corey UtahDave: It does, but they were under the misapprehension that "Oh, x succeeded and only one failure, we'll get to that soon!"
23:32 Corey It was masking all kinds of fun.
23:32 UtahDave Ah, I see.
23:33 iggy "we'll get to that soon" never turns out well
23:33 Corey UtahDave: And since Salt executes in a deterministic order, the things that never executed were the same set each time.
23:36 mgw I knew there was something bad about salt executing deterministically
23:38 iggy if you're going to use failhard, you should probably have an idea about what all is supposed to be executing on all your nodes
23:39 iggy or at the very least, put something at the end of your top file that runs on everything and if you don't see that in the output, you know you've got problems
23:39 Corey iggy: Exactly.
23:40 UtahDave well, shouldn't they have figured out why their state was failing?
23:40 Corey mgw: All config management systems do that. Most of them will continue past failure EXCEPT with the global failhard.
23:40 Corey UtahDave: You'd like to hope!
23:40 iggy 18:33 < iggy> "we'll get to that soon" never turns out well
23:40 Corey In this case, "managing ipmid" is an exercise in frustration if /dev/ipmi0 isn't around.
23:40 otter768 joined #salt
23:41 Corey Fixed with a {% set ipmi = salt['file.file_exists']('/dev/ipmi0') %}
23:41 Corey Then test for both ipmi being true and the virtual grain reading as "physical".
23:41 Corey ("Well isn't the virtual test overkill?" "You'd be shocked what I've found here.")
23:42 iggy kvm at least can emulate a virtual ipmi device
23:43 iggy and yeah, it probably makes no sense to try to manage that interface
23:43 UtahDave sounds like you've been having fun, Corey!  ;)
23:43 UtahDave I probably owe you another beer.  :)
23:43 * iggy makes note not to work where Corey works
23:45 catpig joined #salt
23:50 UtahDave heh
23:53 paha joined #salt
23:56 hasues joined #salt
23:56 hasues left #salt
23:57 bhosmer__ joined #salt

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