Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-08-10

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

All times shown according to UTC.

Time Nick Message
00:15 nitay whytewolf: sign newest problem now - https://gist.github.com/nitay/d0ebdb90b5541e5faeae
00:15 nitay trying to run salt-cloud to launch instance after adding script_args
00:17 whytewolf huh, that error is. no helpful in the slightest
00:17 nitay XenophonF: ^ any ideas appreciated
00:17 nitay :)
00:17 nitay oh wait there is sth else
00:18 nitay * ERROR: You need to allow pip based installations (-P) in order to install the python package 'tornado >= 4.0'
00:18 whytewolf nitay: ahh the new pip error because salt wants to install tornado
00:18 nitay what does this mean?
00:19 whytewolf it looks like the bootstrap script is updated. add -P to your script_args
00:19 whytewolf adding tornado shouldn't hurt anything
00:19 nitay k
00:20 yomilk joined #salt
00:20 kbyrne joined #salt
00:21 nitay looks better so far
00:22 nitay so the bootstrap script actually installs from apt?
00:22 nitay (installs salt i mean)
00:22 whytewolf if using stable, yes.-P just allows some things to be added to pip
00:23 nitay damnit, no stil error
00:23 nitay oh wait hold on my fault this time
00:28 nitay whytewolf new one - https://gist.github.com/nitay/d0ebdb90b5541e5faeae
00:28 nitay runnning with -D as well now
00:34 whytewolf okay, I need to get going. hope you find what is going on ninkotech
00:34 nitay joined #salt
00:35 whytewolf okay, I need to get going. hope you find what is going on nitay
00:35 nitay thx whytewolf
00:35 nitay still wrestling with it :/
00:35 Nazca__ joined #salt
00:38 nitay XenophonF: have u seen this before? https://gist.github.com/nitay/fdea52e454f6b1f57183
00:38 nitay trying to launch instance
00:40 XenophonF nitay: no i haven't
00:41 nitay damn, maybe i should try another approach
00:42 nitay XenophonF: was trying to launch 2014.7 to get around this issue
00:42 nitay not having much luck with taht
00:44 nitay XenophonF: any other ideas regarding issue we had?
00:44 XenophonF have you tried installing an older version of the minion manually?
00:45 XenophonF i'd personally take a hackier approach
00:45 nitay what u mean?
00:46 XenophonF don't screw with salt-bootstrap or anything - just let it install whatever version it installs
00:46 XenophonF then assuming cmd.run or pkg.installed states work, use one of those to force a downgrade
00:46 XenophonF it's not pretty
00:46 XenophonF then again neither is the bootstrap script
00:52 hasues joined #salt
00:52 hasues left #salt
01:05 funzo joined #salt
01:10 nitay joined #salt
01:16 markm joined #salt
01:17 ocdmw joined #salt
01:27 nitay joined #salt
01:31 nitay joined #salt
01:38 nitay joined #salt
01:45 claytron_ joined #salt
01:58 timoguin joined #salt
01:59 nitay whytewolf: still at similar place (picking this up again) - one interesting thing it seems to wrok from master salt cmd now but not from minion salt-call cmd
01:59 nitay thats after updating bootstrap script
01:59 nitay forcing to 2014.7 doesnt seem to work havent figured out why yet
02:00 dthom91 joined #salt
02:01 quasiben joined #salt
02:06 dthom91 joined #salt
02:09 flebel joined #salt
02:14 omegamike joined #salt
02:24 mapu joined #salt
02:26 claytron_ joined #salt
02:36 funzo joined #salt
02:46 quasiben joined #salt
02:47 quasiben joined #salt
02:54 favadi joined #salt
02:54 zmalone joined #salt
02:59 murrdoc joined #salt
03:00 subsignal joined #salt
03:01 sunkist joined #salt
03:04 Furao joined #salt
03:13 pdayton joined #salt
03:15 subsignal joined #salt
03:16 subsignal joined #salt
03:23 VooDooNOFX joined #salt
03:26 napsterX joined #salt
03:27 claytron_ joined #salt
03:29 pdayton joined #salt
03:35 evle joined #salt
03:35 dendazen joined #salt
03:43 VooDooNOFX joined #salt
03:44 mosen joined #salt
03:45 malinoff joined #salt
03:49 ablemann joined #salt
03:49 Matthews_ joined #salt
03:54 claytron_ joined #salt
03:54 quasiben joined #salt
03:59 clintberry joined #salt
04:01 ablemann joined #salt
04:02 omegamike joined #salt
04:03 nitay joined #salt
04:09 nitay for some reason salt-cloud is no longer writing the configs
04:09 nitay so when I spin up a minion it just has empty default config
04:09 nitay any idea why that would be the case?
04:11 ajw0100 joined #salt
04:12 fllr joined #salt
04:14 VooDooNOFX joined #salt
04:20 Smoked_Duck joined #salt
04:24 ITChap joined #salt
04:35 whytewolf nitay: empty default config? I honestly couldn't say. my own salt-cloud install is using git and comes with a minion config that is pretty much default, but defintly not blank
04:36 nitay whytewolf: when I do —keep-tmp the right file is there under /tmp/.salt...
04:36 nitay so im thinking it gets written but then overritten or sth?
04:36 whytewolf maybe, do you have anything in a highstate that would try writing to the minion config?
04:37 nitay hmm dont think so, it doesnt happen when i didnt have the script_args
04:37 nitay now I am running with script_args: -c /tmp/ -D stable 2014.7
04:37 nitay hoping to get rid of the weird pip bug
04:38 joehh bernieke: just pick the debian dir from the branch relevant for your distro and you should be able to use your old workflow
04:38 nitay whytewolf: i use salt-formula
04:38 whytewolf script_args: -P -D -L git v2015.8.0rc2
04:38 joehh bernieke: I'm keen to learn how you go and also if there are any changes we need to incorporate into the packaging
04:38 whytewolf thats what I am using
04:38 nitay k lemme try that
04:38 whytewolf well you don't want a newer minion then you have a master
04:39 nitay right
04:39 whytewolf and honestly -P is just use pip for extras, -D is debug and -L is add libcloud
04:39 nitay ye im trying it now but likely going to do same thing
04:40 nitay also it didnt work for me without -c /tmp/
04:40 nitay ssh kept failing
04:40 whytewolf yeah you have something strange going on. I would start parsing the debug info to see if there is something odd there
04:41 whytewolf wouldn't work with out -c /tmp? thats strange
04:41 otter768 joined #salt
04:41 whytewolf is this a custome image of ubuntu you created or the default one in aws?
04:41 nitay default
04:42 whytewolf I'm running out of ideas here. there is strangeness. unforchantly I am not using aws. my cloud is a home built openstack
04:42 nitay everything was working fine until thigns started auto updating
04:42 nitay now i cant get it back to anything that works
04:44 whytewolf updating? nothing should update with out telling it to. unless you have the salt formula or something
04:44 nitay i use salt formula yeah, just so if i need to update a minion cfg i can do it all in one place
04:45 whytewolf you have checked out your own copy so you are not relient on the upstream repo correct?
04:46 nitay yeah
04:46 nitay i have all my own versions of formulas
04:46 nitay nothing’s changed there
04:46 whytewolf okay.
04:46 whytewolf thats good. and how it should be done with working with formulas.
04:47 ramteid joined #salt
04:47 whytewolf I'm confused. I honestly have no idea what is happening.
04:48 nitay join the club, all day with this :(
04:48 nitay trying your rc2 versio now
04:49 whytewolf I honestly can say. I'm not sure it will work. but only based on the fact nothing seems to fix it
04:51 nitay well slightly different but same effec
04:51 nitay there’s no minion config at all now in /etc/salt after launch
04:51 nitay whereas before there was the default one
04:51 Tyrm joined #salt
04:52 rdas joined #salt
04:52 nitay and the right one is in /tmp/.salt.. when I do —keep-tmp whytewolf
04:54 whytewolf I'm afraid I am no help. I have never seen these odd behavours. and don't even know where to start debugging them. I mean maybe something bad happened to the python scripts on the master that is messing up the way they act.
04:54 nitay ye im starting to think about spinning up a whole new salt master
04:54 nitay getting desparate
04:54 stoogenmeyer joined #salt
04:56 whytewolf couldn't hurt to try it. you don't have to point old minions at it to start with.
05:09 TyrfingMjolnir joined #salt
05:14 napsterX joined #salt
05:17 claytron_ joined #salt
05:18 catpigger joined #salt
05:34 nitay joined #salt
05:35 zer0def joined #salt
05:38 nitay joined #salt
05:48 MatthewsFace joined #salt
05:50 omegamike joined #salt
05:54 malinoff joined #salt
05:55 jhauser joined #salt
05:59 moos3 joined #salt
06:02 colttt joined #salt
06:04 bhosmer joined #salt
06:07 ttrumm joined #salt
06:14 dopesong joined #salt
06:15 dopesong_ joined #salt
06:18 subsignal joined #salt
06:18 claytron_ joined #salt
06:24 AndreasLutro joined #salt
06:28 stoogenmeyer joined #salt
06:34 shantanoo joined #salt
06:35 lb1a joined #salt
06:40 Tyrm joined #salt
06:42 otter768 joined #salt
06:58 nitay joined #salt
06:59 nitay whytewolf: no luck, still same thing - if i put anything in script_args, ssh fails, if I add -c /tmp salt-cloud succeeds but then nothing is actually setup
07:00 moos3 joined #salt
07:05 fllr joined #salt
07:07 KermitTheFragger joined #salt
07:09 krymzon joined #salt
07:11 nitay joined #salt
07:13 linjan joined #salt
07:17 todd__ joined #salt
07:17 mejiamariano joined #salt
07:18 eseyman joined #salt
07:18 mejiamariano joined #salt
07:20 forrest joined #salt
07:22 GreatSnoopy joined #salt
07:24 kawa2014 joined #salt
07:25 GreatSnoopy joined #salt
07:34 markm_ joined #salt
07:39 kbaikov joined #salt
07:40 omegamike joined #salt
07:47 krymzon joined #salt
07:48 kbaikov joined #salt
08:00 ITChap joined #salt
08:06 s_kunk joined #salt
08:07 holyzhou joined #salt
08:08 _mel_ joined #salt
08:11 monkey66 joined #salt
08:14 bernieke joehh: I had to add python-tornado to debian/control (I added it after both zmq occurences), will let you know if I encounter anything else
08:14 slav0nic joined #salt
08:15 Vynce joined #salt
08:17 katyucha joined #salt
08:18 claytron_ joined #salt
08:18 AndreasLutro does anyone know *why* you have to specify the state type in requirements? i.e. why do I need file: /path/to/file instead of just the path?
08:28 N-Mi joined #salt
08:28 stoogenmeyer joined #salt
08:29 gcfhvjbkn joined #salt
08:30 Mate AndreasLutro: what should it do otherwise with this:     foo: {pkg: [installed], service: [running]}
08:33 AndreasLutro Mate: in my opinion, require both
08:34 holyzhou joined #salt
08:34 Mate and how would you reqire it selectively?
08:34 AndreasLutro the same way as you would today, - pkg: foo
08:34 AndreasLutro salt can check if the list item is a string or a dict at runtime
08:35 ITChap joined #salt
08:35 Mate seems a useful improvement to support it
08:35 ITChap does somebody use salt-cloud with Joyent's SDC
08:35 markm joined #salt
08:36 holyzhou hi guys, i got question , i write a template , but i find  ’{% set xms = grains['mem_total']/2 | int %} ‘  doesn't work, still return float type
08:36 ITChap I am trying to set it up but my sdc doesn't have a domain, is it possible to use api_host_suffix with an IP ?
08:42 fredvd joined #salt
08:43 otter768 joined #salt
08:55 VooDooNOFX joined #salt
08:57 mejiamariano joined #salt
08:57 fllr joined #salt
08:58 Grokzen joined #salt
09:00 mage_ any idea for this https://dpaste.de/aypA ?
09:01 Aidin joined #salt
09:03 rim-k joined #salt
09:04 claytron_ joined #salt
09:07 Xevian joined #salt
09:22 spo0nman joined #salt
09:23 dopesong_ joined #salt
09:33 Guest80 joined #salt
09:33 mrmarv joined #salt
09:38 totte joined #salt
09:38 yannis joined #salt
09:39 kawa2014 joined #salt
09:40 yannis joined #salt
09:40 malinoff joined #salt
09:46 yannis left #salt
09:47 yannis joined #salt
09:47 yannis_ joined #salt
09:48 claytron_ joined #salt
09:48 _mel_ how can i target minions on kernelrelease lower than 3? i tried: salt -G 'kernelrelease < 3' test.ping
10:04 CeBe joined #salt
10:08 aqua^c joined #salt
10:11 DanyC joined #salt
10:14 DanyC Hi all, Friday i had a prob with a slow highstate on first run and i bounced few ideas with VR_Jack user. What i found is that if i delete teh minion cache base dir everything works as expected. I'm on latest version of master/ minion except ZMQ which is on 3.x and not 4.x
10:15 DanyC Any idea how i can tell minion on restart to first delete the "present" dir cache in same way highstate can be configured to run on start up ?
10:16 Tyrm joined #salt
10:16 moos3 joined #salt
10:17 DanyC To be more clear - the cache dir is /var/cache/salt/minion/files/*
10:18 yannis_ Question: The grains have been updated on the minions, which I can verify by running 'salt '*' grains.get <my grain>' but I cannot filter hosts by grain (and thus cannot deploy my states by grain) on the salt master yet. It seems as though the salt master has not been updated with the latest grains from the minions even though he has connectivity to them. This hasn't change in a few hours already, what should I do to update the salt m
10:34 stoogenmeyer joined #salt
10:34 babilen yannis_: I wouldn't target states by grains (or rather set roles in grains), but: http://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.cache.html
10:44 otter768 joined #salt
10:46 iamgr00t left #salt
10:49 che-arne joined #salt
10:53 yannis_ thanks babilen, what would be another thing to use instead of grains to separate roles?
10:55 rofl____ https://gist.github.com/roflmao/4b95039e1a031d0c2a1e
10:55 rofl____ anyone had these issues with salt-ssh before?
10:55 babilen I mentioned that because grains are inherently insecure (they are under the control of the minion) and you can target by pillar just as well. I also don't see the point of storing deployment information on the minions (i.e. in a distributed way) rather than centrally on the master (e.g. via external pillars)
10:56 babilen yannis_: ^
10:56 mschiff how does salt determine the shell grain?
10:58 AndreasLutro mschiff: the SHELL environment variable
10:58 AndreasLutro defaulting to /bin/sh if it doesn't exist
10:58 babilen mschiff: Why does it matter?
10:59 zer0def joined #salt
10:59 babilen https://github.com/saltstack/salt/blob/develop/salt/grains/extra.py#L24 to be precise
10:59 mschiff babilen: because on debina, default shell is this dahs crap, and then states will not do what they should
10:59 babilen mschiff: If you want it to use a specific shell then you have to be specific about *that*. /bin/sh is *not* guaranteed to be /bin/bash and relying on that is wrong.
11:00 yannis_ thanks babilen
11:00 babilen You can reconfigure dash or bash and set /bin/sh to what you want, but if you want bash then be specific about that.
11:00 mschiff babilen: I know, but default shell is dash here but salt grain "shell" point to /bin/bash and I wonder why
11:00 herpoderp joined #salt
11:01 BradThurber joined #salt
11:01 mschiff babilen: Maybe the difference is whether salt-minion is started from init (which has dash) or by root (which has bash)
11:01 herpoderp joined #salt
11:02 babilen Sure, root's SHELL would be bash
11:02 babilen (or zsh or tcsh or ...)
11:02 mschiff and starting the init script as root may set SHELL to bash
11:02 aqua^c joined #salt
11:03 mschiff so is there a way to tell salt to always use /bin/bash without telling in every single cmd.run/wait state?
11:06 moos3 joined #salt
11:08 yomilk joined #salt
11:08 babilen None that I know of
11:08 mschiff so this seems like a funny effect: the shell grain is different after system startup than if you restart the minion as root
11:08 DanyC Guys i'm running out of ideas, anyone able to help understanding why on earth the first highstate is super slow? I can prove with minions logs that it takes ~2 min only to atempt to auth with Salt Master
11:08 babilen I am intrigued though: What kind of cmd.run states do you have that actually require that?
11:09 mschiff babilen: in my case I had "echo -e" in a shell command. And dash just echoed "-e" instead of using it as an option ...
11:10 babilen DanyC: Does the same hold true once "test.ping" succeeded?
11:11 evle joined #salt
11:12 DanyC babilen: nope, only with highstate. Basically what i do is in the OpenStack HEAT user_data i run the following  sequence  "service salt-minion restart; sleep 60; salt-call state.highstate; sleep 60;service salt-minion restart; sleep 60; salt-call state.highstate
11:13 DanyC babilen: and i do that so i can first get the mine_attributes being applied and then the sates for that grain type minion
11:14 bernieke joehh: added it after python-croniter (salt-common) instead, salt-ssh needs it as well apparently
11:14 babilen It takes some time between the "key accepted" and "minion ready for communication" events
11:14 DanyC babilen: i know you might say is all down to how big your salt states/ pillar are but are nto big at all. No the YUM repo is slow as is all local repo (not going to internet)
11:14 DanyC and i only have 5 minions in total, not a biggie at all in terms of performance etc
11:15 babilen DanyC: I'm simply interested if the first *highstate* actually takes that long, or if you are simply waiting for the key exchange and the "register with the master" process to finish.
11:16 babilen What I'm even more interested in right now is lunch ... so, farewell, and until later :)
11:16 omegamike joined #salt
11:16 DanyC babilen: that i think is the main issue where the prob is....just tell me what you need and i'll give you all the info
11:17 DanyC babilen: enjoy your lunch, i'm going to do the same (i guess we are on same TZ) :)
11:17 babilen CEST ftw!
11:19 wryfi joined #salt
11:19 fredvd joined #salt
11:21 dopesong joined #salt
11:23 dthom91 joined #salt
11:25 dthom91 joined #salt
11:28 Twiglet so somewhere between 2014.7 and 2015.5 you can't use a https://username:password@dot.com fot a key url in pkgrepo.managed :/
11:31 bhosmer joined #salt
11:35 dthom91 joined #salt
11:37 Twiglet yup: https://github.com/saltstack/salt/issues/24106
11:37 saltstackbot [#24106]title: fileclient.py#get_url ignores HTTP Auth again (2015.5 regression) | It appears the bug described in #18131 has resurfaced in 2015.5....
11:37 Aidin joined #salt
11:39 joehh bernieke: thanks - good to know
11:39 joehh bernieke: out of interest, what has your process been
11:40 joehh debuild/dpkg-buildpackage?
11:44 bernieke joehh: I now simply run "dpkg-buildpackage -b -uc -d"
11:45 omegamike joined #salt
11:50 ingslovak joined #salt
11:51 claytron_ joined #salt
11:52 z3r0 joined #salt
11:52 mschiff ok, now I found this nice debconfmod state so that I can set "dash/sh false" in debconf via salt. Now my problem is that salt will set this on *every* run, even if the value is already "false". Any idea someone what might be wrong?
11:55 moos3 joined #salt
11:58 mschiff ok, solved it. Had a space before the type 'boolean' so that it read ' boolean' ...
12:01 favadi joined #salt
12:02 fredvd joined #salt
12:04 dkrae joined #salt
12:10 rideh joined #salt
12:14 moos3 joined #salt
12:15 murrdoc joined #salt
12:15 tmclaugh[work] joined #salt
12:21 fgimian joined #salt
12:22 DammitJim joined #salt
12:22 funzo joined #salt
12:29 hasues joined #salt
12:30 cpowell joined #salt
12:31 dthom91 joined #salt
12:35 fllr joined #salt
12:37 mschiff Does anybody have an idea if/how it is possible with salt to create files on the fly that will be requested from the master by a minion if it doe snot yet exist?
12:38 murrdoc joined #salt
12:40 DanyC babilen:  are you back from lunch ? you still interested in understanding/ helping with regards to "interested if the first *highstate* actually takes that long"
12:40 AndreasLutro mschiff: file.managed with an "unless" argument?
12:41 babilen DanyC: I am, but I don't really have time to delve into that
12:42 ttrumm joined #salt
12:42 MadsRC Is it possible to have ssh_auth set exclusive keys? I see that it will add the listed keys, but not remove keys that aren't listed
12:43 mschiff AndreasLutro: SOmething like that, but the file should be generated on the master so it can be served to other minions as well
12:43 DanyC babilen: sure no prob, appreciate your open respose
12:43 MadsRC or would I have to do a ssh_auth.abent on every key that I don't want on the system?
12:43 babilen DanyC: You might want to look into startup_states or some reactor driven provisioning rather than your fragile bash wrapper
12:43 AndreasLutro mschiff: pretty sure file.managed fills that requirement
12:44 babilen DanyC: https://github.com/saltstack/salt/issues/4084 is essentially what you are facing
12:44 saltstackbot [#4084]title: Restarting both master and minion delays ability to run a command | version: dc2f0f3c1928b5ba9197355798a01e923c12f529...
12:44 AndreasLutro MadsRC: if you want to do that, maybe a file.managed of authorized_keys is a better option
12:44 mschiff AndreasLutro: ok, but how can that be done? is the master able to execute states?
12:44 otter768 joined #salt
12:45 babilen mschiff: You can install a minion on the master and implement whatever you want in an exection module (for example)
12:45 AndreasLutro mschiff: no, you just put whatever file you want into the states directory and distribute it with file.managed, adding templating as necessary
12:46 DanyC babilen: that is on my target to do but for now i need to pass the 1st hurdle on why those things don't work. The bug you gave me doesn't apply to me since i don't restart master, only bring minions up
12:46 AndreasLutro mschiff: for context, what sort of files are you actually talking about
12:46 babilen DanyC: It is the same delay in the minion startup
12:46 mschiff AndreasLutro: rsa key data
12:46 babilen DanyC: Just think that startup_states gets around your problem
12:47 AndreasLutro mschiff: so you want to generate a private key if it doesn't exist, then distribute the public key to other minions?
12:48 dendazen joined #salt
12:48 babilen saltstack *really* needs writable pillars !
12:48 babilen So badly.
12:49 mschiff AndreasLutro: I must distribute the proivate key as well in such cases
12:49 AndreasLutro really?
12:50 dyasny joined #salt
12:50 kawa2014 joined #salt
12:50 mschiff babilen: I will have a look at execution modules, too thanks
12:50 AndreasLutro that's odd, but regardless... not sure how to achieve that
12:50 yomilk joined #salt
12:50 mschiff AndreasLutro: yes really ;), ok but thanks!
12:50 MadsRC AndreasLutro: I ended up creating an empty dummy authorized_keys file that I made sure was placed there before SSH keys was added. Works like a charm, but a tad hackish...
12:51 AndreasLutro MadsRC: that works fine as well, though you'll be told there are changes on every highstate run
12:52 amcorreia joined #salt
12:53 babilen mschiff: You might have explained that earlier, but what is it that you are trying to achieve with the SSH keys?
12:54 moos3 joined #salt
12:56 subsignal joined #salt
12:56 tkharju joined #salt
12:57 peterdemin joined #salt
12:58 mschiff babilen: I am not talking about ssh keys. I am talking about a distributed service where every minion needs to calculate signatures for various entities. And for each entity every minion must do this with *the* key for that entity, not any
12:59 mschiff (minion == the system where a minion is running)
13:00 mschiff But maybe I really need the minion on the master to be the central key store creating all files required
13:00 subsigna_ joined #salt
13:00 bhosmer joined #salt
13:01 peterdemin Hi, I'm trying to manage GPFS cluster using Salt. The main problem here is that GPFS has remote execution engine built-in, so some commands must be executed only on one node. This opens 2 questions: 1) what is the best way to target minion on localhost? 2) How to execute state on exactly one node, no matter which?
13:02 jdesilet joined #salt
13:03 racooper joined #salt
13:04 mschiff babilen, AndreasLutro: Mayb the master-minion should produce pillar data, so that I can control, which minion gat fetch which keys...
13:05 mschiff but then next problem arises: How will a minion behave if the pillar data it wants (contents_pillar in file.managed) does not exist (yet)?
13:06 mschiff well {% if in pillar[# ... %} should solve that...
13:09 babilen mschiff: You are aware that you can share data via the salt-mine aren't you?
13:10 mschiff babilen: no, I did not have that in mind. Thanks. Will read about it now...
13:10 mschiff thanks
13:11 omegamike joined #salt
13:11 mschiff babilen: this really sounds very promising. I think I might have benn looking for somehting like that ;)
13:12 moos3 joined #salt
13:12 babilen Okay, sorry, it wasn't clear to me what you are trying to achieve
13:12 infamous_derp joined #salt
13:12 claytron_ joined #salt
13:13 Aidin joined #salt
13:14 pdayton joined #salt
13:16 mschiff babilen: is there something like access control in the mine?
13:16 Tyrm joined #salt
13:16 babilen no, do you require that?
13:17 mschiff would be better so that the key material will only be available for the minions that actually require it
13:18 Tyrm_ joined #salt
13:19 breakingmatter joined #salt
13:21 sunkist joined #salt
13:24 Grokzen Is the 404 page on docs.saltstack.com is broken and fails to render? I get 404 on all static files when viewing for example https://docs.saltstack.com/en/latest/topics/releases/foo
13:25 babilen Grokzen: Looks like it
13:27 Deevolution joined #salt
13:27 XenophonF joined #salt
13:28 teryx510 joined #salt
13:28 yomilk joined #salt
13:29 markm joined #salt
13:32 nitay joined #salt
13:34 moos3 joined #salt
13:38 funzo joined #salt
13:41 bernieke I'm not getting 2015.8.0rc3 to work. My master config is empty and my minion config contains only the id and master.
13:41 dthom91 joined #salt
13:42 bernieke Both seem to start fine, but "salt-key" won't show me a key to accept.
13:42 bernieke In the minion log the last I see is: "[DEBUG   ] Initializing new AsyncZeroMQReqChannel for ('/etc/salt/pki/minion', 'bernie-salt-upgrade-1', 'tcp://10.147.128.174:4506', 'clear')"
13:42 bernieke Anyone any idea?
13:43 bhosmer joined #salt
13:44 nahamu brand new machines? could you have a firewall in the way?
13:45 aqua^c joined #salt
13:45 babilen Can the boxes ping each other? Can you telnet?
13:47 mpanetta joined #salt
13:47 bernieke it's the same machine
13:47 bernieke I originally had it set up with interface and master to 127.0.0.1, didn't work either
13:48 bernieke no firewall on this vm either
13:48 bernieke and the vm is the same template 2014.7 works on fine
13:48 ekristen joined #salt
13:48 Norrland bernieke: what is the 'master:' set to?
13:48 mapu joined #salt
13:49 bernieke master: 10.147.128.174
13:49 bernieke telnetting to 10.147.128.174 4506 connects, not sure what else I can do at the telnet prompt?
13:50 DammitJim joined #salt
13:51 kawa2014 joined #salt
13:53 Norrland bernieke: restarted salt-minion after changing master?
13:54 bernieke yes, several times :)
13:54 bernieke the last message is always the AsyncZeroMQReqChannel one
13:55 Brew joined #salt
13:56 Norrland bernieke: updated from packages or source?
13:56 bernieke these are debs I built from the source (2015.8.0rc3 tag)
13:56 jalbretsen joined #salt
13:56 timoguin joined #salt
13:56 bernieke I'll try the pip packages (I noticed rc3 exists in pypi)
13:57 SheetiS joined #salt
13:58 bernieke ah, I think I found my problem
13:59 sovern I have two new Centos7 vm's that I have installed SALT from EPEL.  I've only changed the master address on the minion.
13:59 bernieke my tornado version is too low (3.1.1-2, whilst I need >= 4.0)
13:59 sovern The minion refuses to connect to the master.. i've disabled selinux and the firewall.
14:01 favadi joined #salt
14:02 andrew_v joined #salt
14:04 VooDooNOFX joined #salt
14:05 BradThurber joined #salt
14:06 indispeq Hello everyone. Would somebody have a gist or a link to a working salt-cloud configuration for salt 2014.7.5 that can manage openstack Juno? The one in the salt docs seems to be fore Essex.
14:09 indispeq I mean that openstack Juno is a provider
14:10 arif-ali joined #salt
14:14 quasiben joined #salt
14:16 VooDooNOFX joined #salt
14:19 claytron_ joined #salt
14:24 fllr joined #salt
14:24 spark_ joined #salt
14:26 tvinson joined #salt
14:30 clintberry joined #salt
14:30 darix in puppet you could use the << >> thing to get a list of all the webservers e.g. to feed that into a list to set up the haproxy backend list. is there something similar for salt?
14:32 PI-Lloyd darix, take a look into salt mine, that is what we use to populate our haproxy configs
14:32 darix thanks
14:32 deedubs darix: https://docs.saltstack.com/en/develop/topics/mine/index.html
14:33 sakaYK joined #salt
14:34 DanyC babilen: thanks! I tried with startup_state: highstate but not much hope. you can see my problem in the log http://paste.openstack.org/show/412374/ where it takes a loong time even before it auth wiht master and hten you can see nothing happens. If anyone has any ideas i'd much appreciate
14:36 darix so i need to find out how to set the "web" grain for my hosts. thanks
14:37 deedubs darix: you can do that in /etc/salt/grains
14:38 darix deedubs: on the minion i guess
14:38 deedubs yes
14:38 deedubs darix: or use something like salt '<your targets here>' grains.append roles web
14:40 breakingmatter Hey guys. I'm having an issue with environments. I have GitFS setup for the fileserver backend. The main state tree is configured to use the different git branches for environments (e.g., "master", "develop", "feature/*"). I also have a few formulas configured using GitFS. These only have "master" branches. If I run a state that calls one of these formulas and use an environment that exists in the main state tree but not the formula
14:40 breakingmatter tree I get an error saying "Specified SLS <FORMULA NAME> in saltenv <ENV NAME> is not available on the salt master or through a configured fileserver". Any ideas?
14:40 darix deedubs: thanks!
14:42 darix salt 'roles:web' test.ping should work afterwards right?
14:44 darix -G
14:44 apejens joined #salt
14:45 otter768 joined #salt
14:46 mejiamariano joined #salt
14:47 deedubs it should darix yes
14:47 darix yeah forgot the -G
14:47 zwi joined #salt
14:47 ajw0100 joined #salt
14:47 mejiamariano left #salt
14:48 apejens I'm having some problems with gitfs, and I can't seem to find much with google on this error :( https://gist.github.com/omega/c1a82fb76d92c5162bc5#file-gistfile1-txt-L19
14:48 apejens I can clone the repo as the user running salt-master (inputting the passphrase from the config)
14:49 babilen breakingmatter: master should be base and available to all minions
14:49 babilen (assuming they are all in base)
14:50 babilen breakingmatter: You can/could/have to create additional branches if you want your formulas to also reflect the environment setup (so that you can, for example, merge from dev to prod if you try out new things)
14:51 zwi joined #salt
14:52 breakingmatter babilen: The base is set to master for all branches, but I'd like to be able to run states from a feature/develop branch. ANd that part works fine, except for when it includes a state file from another GitFS tree that doens't have that environment.
14:52 zmalone joined #salt
14:53 babilen Are those boxes in base as well? That should™ work if you run a highstate :-/
14:53 breakingmatter I'm not talking about a highstate. I'm trying to run one specific state.
14:53 breakingmatter And what do you mean by are those boxes in base?
14:53 babilen And you also specifiy a specific environment?
14:54 SheetiS should™ is a trademark of the Good Luck Yeah Right
14:54 babilen :D
14:54 SheetiS Corporation :D
14:54 breakingmatter babilen: "salt '<target>' state.sls core.ad env=feature/my-feature-name
14:54 SheetiS <3
14:54 Nazzy joined #salt
14:54 babilen breakingmatter: I mean that the boxes that should use the formula should *all* have a "base: 'foo': - theformula" entry in your top.sls
14:55 babilen breakingmatter: Yeah, if you want to do that then you would have to ensure that the formulas also have a feature/my-feature-name branch
14:56 babilen (if they are being used in core.ad)
14:56 breakingmatter babilen: That's absurd.
14:56 babilen Isn't it?
14:56 breakingmatter What about using formulas from other users off of Github? I can't tell them to make my branches.
14:57 breakingmatter I love all these half-baked features.
14:57 babilen Well, I wouldn't ever reference formulas on GH directly, but the whole "git branch == environment" aspect of GitFS is a bit ludicrous.
14:57 mapu joined #salt
14:57 breakingmatter le sigh
14:57 mpanetta There should be a mapping config for it.
14:57 mpanetta Why isn't there? :P
14:58 babilen What I would do: Use https://github.com/saltstack-formulas/salt-formula and, in particular, https://github.com/saltstack-formulas/salt-formula/blob/master/pillar.example#L132 for managing formulas
14:58 breakingmatter babilen: I don't know what I'm looking at here.
14:58 favadi joined #salt
14:59 * iggy hates salt-formula's formula handling
14:59 dthom91 joined #salt
15:00 babilen Not entirely sure what to do about your "feature/my-feature-branch" problem. I typically simply work on those branches, clone them locally and use them as /srv/salt tree in my vagrant boxes. That's the only area in which my feature branch features ...
15:00 babilen iggy: Do you prefer GitFS?
15:00 tvinson can salt syndic be configured on redundant masters such that each master points at the other? would this allow you to address all minions from either master?
15:00 babilen We use salt-formula's and GitFS in different project and I'm happy with both ...
15:00 iggy of those 2 options, yes
15:01 favadi joined #salt
15:01 babilen breakingmatter: My main point is: I'd leave the whole "feature branch" thing out of your master configuration and configure your test boxes to simply use what is in /srv/salt/foo (up to you to clone the right branch then)
15:02 breakingmatter But then that makes staging painful.
15:02 babilen Once you are happy with your development you can merge it into the "dev" or "qa" or "prod" branch explicitly and push it to the master where it is being picked up by GitFS
15:02 cwandrews joined #salt
15:02 BradThurber joined #salt
15:03 breakingmatter babilen: I still don't think that would fix it. Because I still need to make calls to these external formulas that doesn't have the "dev" "qa" or "prod" branches. WHich is the issue.
15:03 babilen I might also not be aware of a cooler/nicer approach to the whole "environments and formulas" malarky ...
15:03 breakingmatter Everything works "fine" except for making calls to external branches
15:03 ALLmightySPIFF joined #salt
15:03 breakingmatter err, making calls to formulas that don't have the same branch structure that is.
15:04 scottpgallagher joined #salt
15:04 cwandrews Hello all I am experiencing an issue with salt-cloud that is stopping me from starting new nodes. It seems salt-cloud is unable to start the the salt-minion on the new node
15:04 babilen minions can be in multiple environments and it might make sense to use "base" / "master" for states that should be used by all of them
15:04 sdm24 joined #salt
15:04 breakingmatter babilen: These environments dont' exist in the top.sls file..
15:04 ALLmightySPIFF joined #salt
15:04 breakingmatter It's all handled by the gitfs settings
15:04 favadi joined #salt
15:05 babilen breakingmatter: I'm off to training .. Might want to raise this on the mailing list as it is an important topic and I don't want you to go off on a tangent simply because I couldn't think of a better solution :)
15:05 breakingmatter babilen: I'll have to find the mailing list.. lol. I'm not sub'ed.
15:05 babilen https://groups.google.com/forum/#!forum/salt-users
15:05 breakingmatter Wonderful. Thank you
15:06 murrdoc try again
15:06 breakingmatter This actually brings up another question. What is the relationship of the top.sls file to the rest of salt OTHER THAN highstate.
15:07 manfred breakingmatter:  nothing
15:07 manfred it is just another state file
15:07 ALLmightySPIFF joined #salt
15:07 manfred only special
15:07 breakingmatter manfred: Why do people mention it in reference to environments then?
15:07 breakingmatter If I'm not concerned about using something for highstate, why does top.sls matter?
15:08 manfred you specify your environments in the top as well
15:08 breakingmatter So if I want to use environments (other than with GitFS features), I have to define them in top?
15:08 manfred so, if you aren't using highstate, then you don't need to care about top.sls
15:08 babilen http://docs.saltstack.com/en/latest/ref/states/top.html#environments
15:09 funzo joined #salt
15:09 manfred if you just want  to specify saltenv= when running state.sls, then yeah
15:09 babilen (which is why I'm asking: "are they also in base?")
15:09 manfred that is all highstate really does
15:09 cwandrews joined #salt
15:10 breakingmatter So you need to define an environment, associate minion id's with them, and then define the states that you want to run during a highstate?
15:10 babilen Well, you say which states are available to which minion from which environment
15:10 babilen (all of which will be applied to the minion if you run the highstate)
15:11 babilen bbl, good luck!
15:11 breakingmatter What if you want to do that but NOT run a state during highstate?
15:11 breakingmatter i.e., Openstack installation states
15:11 favadi joined #salt
15:12 sdm24 change the targetted minions in the highstate
15:12 sdm24 or add individual if statements and/or requisite checks in the state files
15:13 breakingmatter I feel like there should be a better way of handling this.
15:13 spatry2015 hello everyone.  I am applying pillar data to minions based on an env custom grain.  I have a pillar file that holds a loc and ipaddrs.  is it possible to have that data parsed from top.sls?
15:14 breakingmatter We have some states that can't guarantee idempotence, and we can't guarantee that a user won't run highstate on a minion.
15:14 spatry2015 or is this better served by just splitting the ipaddrs across diff pillar loc files?
15:14 murrdoc u want those states to not ibe in highstate ?
15:15 breakingmatter murrdoc: Yes
15:15 breakingmatter But, still defined in an environment.
15:15 breakingmatter For specific minions
15:15 murrdoc u want them to only be run by smart peoples
15:15 murrdoc try http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#salt.modules.state.disable
15:15 breakingmatter In a perfect world, I would be able to lock down specific states to specific minions in specific environments.
15:15 murrdoc oh
15:16 murrdoc you can lock down states to minion and targets much easier
15:16 murrdoc wrap em in if loops
15:16 breakingmatter Yeah, I figured that out Friday thanks to some people in this IRC.
15:16 breakingmatter I have some if loops in states that test for grains and then use fail states to render
15:16 breakingmatter But that doesn't solve everything.
15:17 breakingmatter Because I still need to be able to lock down based on environments.
15:17 murrdoc saltenv is a jinja variable
15:17 breakingmatter hmmm
15:17 breakingmatter THat may help
15:17 breakingmatter I'll play with that then and see where i can get
15:18 fllr joined #salt
15:18 breakingmatter thanks murrdoc :)
15:18 djstorm joined #salt
15:18 breakingmatter I know my use case is probably a very underutilized case.
15:18 breakingmatter In a perfect world, you just don't run the MySQL states on your webservers.
15:19 rm_jorge joined #salt
15:20 breakingmatter So, If I dont' have a state defined in top.sls for an environment, why can I still run the state on that minion?
15:21 dopesong_ joined #salt
15:21 dopeson__ joined #salt
15:22 murrdoc sorry
15:22 murrdoc i dont understand the question
15:23 sdm24 because the default env is base? I think that's what you are asking
15:24 claytron_ joined #salt
15:24 breakingmatter Lets say I have two states. mysql and nginx. If My top file is "base: '*': - nginx", why can i still run mysql on the minions if it's not defined?
15:24 murrdoc top.sls only gates whats in highstate
15:24 murrdoc are u trying setup a per minion blacklist
15:24 murrdoc or whitelist
15:24 breakingmatter Then what is it's relationship to environments?
15:25 murrdoc its a map of what states need to be run in what environment as part of highstate
15:25 breakingmatter I want to have environments like "prod", "dev", "OpenStack", "Ceph", etc.
15:25 murrdoc ok
15:25 sdm24 the top.sls is designed to simplify/automate calls. You defined environments and states for minions, so you can run it all with just a "salt '*' state.highstates" instead of calling each and every state in a long CLI command
15:25 DammitJim joined #salt
15:25 murrdoc breakingmatter:  what u need is orchestrate
15:25 elfixit joined #salt
15:26 murrdoc and then in set your top.sls to only run tasks that are truly global
15:26 sdm24 but you can still run any call on any minion manually
15:26 breakingmatter I haven't read up on orchestrate. What does it offer?
15:26 sdm24 like when I tried to run one of my linux states on a windows minion :(
15:26 breakingmatter sdm24: That's the kind of stuff I would like to block.
15:27 breakingmatter So if someone goofs and runs "salt '*' state.sls mysql" it doesn't blow up the DC.
15:27 murrdoc for that
15:27 murrdoc shut down your salt master
15:27 sdm24 Yeah I'm not sure how to specifically stop that from EVER happening
15:27 murrdoc and use pepper
15:27 murrdoc and salt-api
15:27 murrdoc only run stuff from api calls, and use the 'user auth' to prevent fuckups
15:28 sdm24 One way would be to include if statements in the state file
15:28 iggy salt is a swiss army knife with a gun
15:28 murrdoc yeah
15:28 sdm24 like for our postfix state, we have {% if grains['id'].startswith('mail' %} then do nothing
15:28 breakingmatter sdm24: I have if statements in some of the states, and that works well usually.
15:28 murrdoc the orchestrate works because u train all the users to use orchestrate calls
15:28 murrdoc so they dont know mysql exists as a state
15:29 murrdoc breakingmatter, u can also do this
15:29 murrdoc make a 'pillar' with an environment to allowed states map
15:29 breakingmatter The if states work well, but it doens't offer everything I need. As I would also like to have "dev" environments for the same state
15:30 breakingmatter murrdoc: How would that integrate?
15:30 breakingmatter i.e., how could that keep a state from running?
15:30 murrdoc write a python module to read that map, the environment and so on
15:30 murrdoc in a python module u can call state.single to execute states
15:30 VR-Jack2 ugh. perhaps I should return to 2014.7... the bug list on 2015.3 is driving me nuts
15:30 VR-Jack2 err. 2015.5.3
15:30 breakingmatter murrdoc: Oh okay I see what you're saying.
15:30 murrdoc and call that module at the top of your 'scary' states
15:31 sdm24 use if statements {% if salt['pillar.get']('env') == 'dev' %}...
15:31 murrdoc VR-Jack2:  whats the bug list
15:31 murrdoc nah sdm24 encapsulate all of it in a python module
15:31 sdm24 that too'
15:31 sdm24 but I don't know/use python
15:31 murrdoc he can use __salt__[pillar,get], __salt['state.sls']
15:31 sdm24 (I know I should)
15:31 breakingmatter So the module would be at the top of the state file.
15:31 breakingmatter Would it run the state itself?
15:31 breakingmatter How would that look.
15:32 murrdoc it wont run the state file
15:32 bernieke nahamu, babilen, Norrland: my install is working, tornado was indeed the culprit
15:32 murrdoc it will exit out of the state file if the file is not safe for env/minion
15:32 DanyC VR-Jack2: am i wrong or the 2014.7 is no longer part of centos yum repo ?
15:32 VR-Jack2 murrdoc: problems with using file:// or just specifying the file path. should be fixed I believe. have to test that. Problems with functions that were empty. checksum seems to be broke in places
15:32 nahamu bernieke: what was tornado doing that was causing problems?
15:32 breakingmatter murrdoc: How can the module cause an exit?
15:33 bernieke joehh: so "python-tornado (>= 4.0)" instead of just python-tornado for the debian/rules
15:33 breakingmatter I know python very well, I've just never written a salt module lol
15:33 murrdoc 'state.single'('test.fail')
15:33 breakingmatter Oh, yes.
15:33 breakingmatter Duh
15:33 dthom91 joined #salt
15:33 breakingmatter The office is out of coffee. Forgive me.
15:34 murrdoc if u make it a state module
15:34 bernieke nahamu: it was just a too low version (the ubuntu 14.04 3.1.1 instead of the required >=4.0)
15:34 murrdoc u can prereq it
15:34 breakingmatter prereq?
15:34 murrdoc http://docs.saltstack.com/en/latest/ref/states/requisites.html#prereq
15:34 breakingmatter Oh, because it's a state.
15:34 breakingmatter I getit
15:35 VR-Jack2 DanyC: you appear to be right. weird
15:36 murrdoc VR-Jack2:  that sucks , the bug list
15:36 murrdoc damn u based pi
15:36 VR-Jack2 yeah. they removed 2014.7 from epel. :(
15:37 VR-Jack2 the problem as far as I can tell is that 2015.5 commited a lot of major changes without anyone testing functionality
15:37 sdm24 So does anyone know if 2015.5.4 will be released, and will it be before or after 2015.8?
15:37 DanyC VR-Jack2: i found out after our discussion regarding my issue where the minion takes a long time to auth wiht master - which i still haven't figure out (http://paste.openstack.org/show/412374/ ) - and when i tried to follow your sugestion to downgrade to a more stable (aka less buggy) version i hit this bump
15:37 VR-Jack2 it's like: "Hey, we changed a bunch of stuff in file.*, should be perhaps test all the various ways to call that? Nahhhhh"
15:38 drawsmcgraw When I update my topfile, my minions don't seem to be getting the updated version of my topfile.
15:38 drawsmcgraw I'm using GitFS
15:38 sdm24 does the master update the repo?
15:38 breakingmatter drawsmcgraw: Have you ran "salt-run fileserver.update"?
15:38 sdm24 err update itself with the new repo
15:38 subsignal joined #salt
15:38 drawsmcgraw I can see in a state.highstate -l debug that the master is compiling the topfile from all the different branches....
15:39 drawsmcgraw sdm24: breakingmatter yes, I've updated the master's fileserver
15:39 yomilk joined #salt
15:39 subsign__ joined #salt
15:39 drawsmcgraw I can see my desired branch ('base') in the output of  '-l debug'
15:39 VR-Jack2 basepi: any chance you can add 2014.7 back into epel? 2015.5 still isn't stable enough.
15:39 sdm24 is git set above roots in the fileserver list? it might be running the local top.sls file
15:39 drawsmcgraw But.... Not sure why the 'base' topfile is not the one that the minion get handed
15:39 drawsmcgraw sdm24: I had thought that as well (it's bitten me before).
15:39 drawsmcgraw but
15:39 drawsmcgraw I don't have a topfile in /srv/salt
15:40 sdm24 Do other states get loaded in?
15:40 sdm24 i.e. if you add a random test.sls in git will the minions see it?
15:40 nitay joined #salt
15:40 drawsmcgraw sdm24: Yeah. I've manually run the states on the minions
15:40 drawsmcgraw i.e.  state.sls foo.bar
15:41 sdm24 but will they see any changes if git updates the file?
15:41 drawsmcgraw But the minion won't run foo.bar during a highstate.
15:41 sdm24 is it only top.sls that won't be updated on the minions?
15:41 drawsmcgraw sdm24: correct
15:41 drawsmcgraw (at least from what I'm seeing)
15:41 VR-Jack2 murrdoc: 2015.5 also breaks nodegroups talking to older minions. The change wasn't exactly bad, but we could have been a little more friendly
15:41 sdm24 gotcha
15:41 jondonas joined #salt
15:41 drawsmcgraw I pushed my states directly to Git, so that's the only way the minions would see them.
15:41 murrdoc VR-Jack2:  damn
15:42 DanyC VR-Jack2: thanks! Unless you or basepi fancy having at help me out and see if we spot/ fix the issue (which is a BIg tough nut to crack )
15:42 VR-Jack2 what's sad is, I'm not sure why minions should be receiving and verifying the nodegroup to begin with
15:42 drawsmcgraw sdm24: scratch that. I can see minion getting all the compiled topfiles
15:42 drawsmcgraw from the various branches I have
15:42 drawsmcgraw But for some reason, it's not choosing the topfile from 'base' :/
15:43 VR-Jack2 ie, I send to a minion the entire nodegroup string. That's leaking info to a minion I don't think it needs to know
15:43 VR-Jack2 The master is the only one who should be aware of and processing nodegroups, imho.
15:44 drawsmcgraw The minion seems to ignore my 'saltenv=base' flag on the salt-run too.... I must be missing something
15:44 basepi VR-Jack2: the problem is that that is how salt is architect ex
15:44 basepi Gah, stupid phone sent too early.
15:45 yannis_ guys: my salt master seems to be connecting in a different way to some of my minions. I'm not sure the exact way to describe it but by doing "salt '*' cmd.run 'env'" I can see the very different shell context, e.g. for (the incorrect ones) I have SHELL=/bin/bash and SHLVL=1. For the correct ones it seems to be connecting to the minion directly, env vars include  UPSTART_JOB=salt-minion. One of the problems this causes me is the $PATH
15:45 VR-Jack2 basepi: yeah. we did it early on. changing would be hard. Unless we had the master split up the nodegroup and send a modified nodegroup to each minion with just that node listed.
15:45 basepi Salt's architecture is pub sub. We sent jobs to all minions and they decide whether to run the job.
15:46 XenophonF joined #salt
15:46 basepi I suppose we could add an option to transform node group matches to list targets
15:46 basepi Actually that might be cool, I'll have to think about it.
15:46 VR-Jack2 I'm thinking security wise. Why leak node info to nodes that don't need to know.
15:47 basepi As far as 2014.7 in epel I'll ask terminalmage about it. I assume he would have left the old version if that were an option -- it's unlikely we will roll epel back completely, especially with 2015.8 coming soon.
15:47 VR-Jack2 plus, if we hadn't done the nodegroup check on the minion, we wouldn't have broken it. lol
15:47 basepi Make sure your issues have github issues, and ping me on them if you like, I'll make sure they get eyes.
15:48 VR-Jack2 nodegroup one has you pinged. I won't "fix" it unless you approve it
15:48 basepi I think I remember that one. Can you link it to me please?
15:48 VR-Jack2 basepi: https://github.com/saltstack/salt/issues/26107
15:48 saltstackbot [#26107]title: Issue targeting nodegroups - Invalid compound target: ( L@ ... ) | Seeing a strange bug when targeting nodegroups. Some of my minion return fine, whereas others give me either "Minion did not return. [No response]" or "Minion did not return. [Not connected]"....
15:49 VR-Jack2 fix looks easy. it's even easier in dev I think. we reworked it again after 2015.5
15:49 dthom91 joined #salt
15:49 Akhter joined #salt
15:50 Akhter Hey guys, I'm trying to create a salt grain with subprocess, but I'm running into this error.  TypeError: can't serialize <subprocess.Popen object at
15:50 Akhter Anyone know a way around it
15:51 venu0336 joined #salt
15:51 basepi Yeah, thanks, in a meeting at the moment, will give it a proper look and probably approve your fix a little later
15:52 drawsmcgraw Alas - https://github.com/saltstack/salt/issues/5440
15:52 saltstackbot [#5440]title: minion uses wrong default environment when using git backend | When using git as a backend and the environment is not explicitly specified, salt may select an environment/branch other than the base/master. I've specifically seen this with state.show_top and state.highstate....
15:52 drawsmcgraw Still reading that one... I believe I've found what's going on in my situation
15:52 sdm24 joined #salt
15:52 rideh^ joined #salt
15:54 nitay joined #salt
15:54 CheKoLyN joined #salt
15:56 iggy Akhter: you can't do that
15:56 Akhter iggy: Why?
15:57 Akhter Would it be preferred if I used subprocess.call instead?
15:57 iggy Akhter: nvm, I was thinking threading
15:57 iggy what are you actually trying to do?
15:58 iggy Grains get updated quite frequently, you really wouldn't want to run some heavy process all that often
15:58 Akhter iggy: I'm creating an IPMI grain that will get the IPMI IP.  I'm well aware of the ipmi capabilities on the new salt version, but due to other bugs we can't move to that version just yet.
15:58 Akhter So I've created this.  https://gist.github.com/AkhterAli/c5586c621065f3626b02
15:58 Akhter I just want the IP from the IPMI module.
15:59 Akhter And I'm using salt 2014.7.0
15:59 iggy why don't you just use __salt__['cmd.run']() ?
16:00 Akhter I can't use pipes then.
16:00 Akhter It will just return the entire "ipmitool lan print"
16:00 Akhter And the return type is int.
16:00 drawsmcgraw Holy crap I've found a raw nerve: https://github.com/saltstack/salt/issues/12483
16:00 saltstackbot [#12483]title: Top SLS compilation does not behave the same as Docs describe | Hi...
16:00 Akhter So I can't split that.
16:00 drawsmcgraw But it looks like(?) there's some closure in sight. Maybe?
16:00 murrdoc Akhter:  try cmd.run ('', python_shell=True)
16:00 iggy cmd.shell then?
16:00 iggy or that
16:01 drawsmcgraw I think I'll just try to get rid of the branches in my Git repo until the dust settles on that one. Wow.
16:01 nitay joined #salt
16:01 Akhter iggy: I'll give that a shot.
16:01 RedundancyD joined #salt
16:01 Akhter One moment.
16:01 malinoff joined #salt
16:03 bhosmer_ joined #salt
16:04 Akhter iggy: I'm going to try with this.
16:04 Akhter output = __salt__['cmd.run']('/usr/bin/ipmitool', 'lan', 'print', '|', 'awk', '"/IP Address    /', '{ print $4 }"', python_shell=True)
16:04 Akhter Via CLI this did not work, it didn't pipe as I want it and returned an type int due to return code.
16:04 cwandrews joined #salt
16:05 iggy why are you breaking it up like that?
16:05 iggy that's really not the format cmd.run expects
16:06 wych joined #salt
16:06 XenophonF can't you put it all into one string, like "cat foo | awk"?
16:06 dthom91 joined #salt
16:07 XenophonF drawsmcgraw: how does the salt minion know which environment it's in?
16:07 iggy that's what I Was saying
16:07 fllr joined #salt
16:08 Akhter XenophonF: I'll try it in one string.
16:08 claytron_ joined #salt
16:08 Akhter output = __salt__['cmd.run']('/usr/bin/ipmitool lan print | awk "/IP Address    / { print $4 }"', python_shell=True)
16:08 Akhter Better?
16:09 theologian joined #salt
16:09 XenophonF sure, that should work
16:09 zer0def joined #salt
16:09 darix i am not sure how much it affects the usability of the website. but chrome blocks insecure resources on the saltstack documentation website.
16:09 funzo joined #salt
16:11 mejiamariano joined #salt
16:11 Akhter XenophonF: iggy: Same error.  I'm assuming that subprocess is imported before I attempt to sync grains.
16:11 Trance92071 joined #salt
16:11 Trance92071 left #salt
16:12 stoogenmeyer joined #salt
16:12 stoogenmeyer joined #salt
16:12 LtLefse darix: firefox does too. firefox doesn't mind if you just browse the whole thing with unencrypted http://, though
16:13 darix LtLefse: i could also click in chrome to tell to load the resources :)
16:13 s_kunk joined #salt
16:13 darix it should be something easy to fix though
16:13 joehh joined #salt
16:13 LtLefse yes, it is
16:14 iggy if someone doesn't fix that is mapping crap in the salt-formula, I'm going to revert that whole commit
16:15 zsoftich2 joined #salt
16:15 mejiamariano joined #salt
16:17 krymzon joined #salt
16:18 Brew joined #salt
16:19 Brew joined #salt
16:21 Brew1 joined #salt
16:22 jmreicha joined #salt
16:22 XenophonF would someone mind looking at this error - https://gist.github.com/xenophonf/efab3a2fa78d98256d53
16:22 XenophonF i'm trying to use context variables in a file.managed state, but i'm getting a render error "expected document start but foudn block mapping start"
16:22 Brew1 joined #salt
16:24 lrojas joined #salt
16:25 MatthewsFace joined #salt
16:27 mapu joined #salt
16:27 Brew joined #salt
16:28 XenophonF i took out the |yaml filter and it worked, so who knows
16:29 SheetiS XenophonF: I sometimes have trouble with nesting |yaml inside of yaml stuff.  I've found I can usually get around it by piping to |json if I need to pass something more complex than a string
16:30 lrojas left #salt
16:30 XenophonF SheetiS: thanks for the clue
16:31 XenophonF i'm probably going to put |yaml_squote in, instead
16:31 mapu joined #salt
16:34 bhosmer_ joined #salt
16:34 manfred Anyone know what directory I can put custom engines in?
16:35 pipps joined #salt
16:36 aparsons joined #salt
16:36 drawsmcgraw XenophonF: Sorry, got pulled away. I haven't made any changes to the minion config so it should be taking the default 'base'
16:36 KingJ joined #salt
16:37 mr_const joined #salt
16:37 KingJ joined #salt
16:37 mr_const hi all
16:37 kaptk2 joined #salt
16:37 mr_const does someone know, why my minion placed in azure cloud disconnects in 3-4 minutes from master, which located in my office?
16:37 VR-Jack2 hmmm. looks like someone did a bad patch
16:39 VR-Jack2 _urlparse(source).scheme != 'salt': and similar is all over the code. They patched one instance of it as _urlparse(source).scheme not in ('salt',''). That leaves the rest of the code base broken still
16:39 mkillebrew mr_const: adjust your timeouts
16:39 adelcast left #salt
16:39 XenophonF drawsmcgraw: i don't recall hitting that bug, but conceptually, it was easier for me conceptually to restrict the base environment to just targeting
16:39 mkillebrew in /etc/salt/minion --
16:39 mkillebrew tcp_keepalive: True
16:39 mkillebrew tcp_keepalive_idle: 30
16:40 aparsons_ joined #salt
16:40 XenophonF drawsmcgraw: to wit, https://github.com/irtnog/salt-states/tree/master/top.sls
16:40 drawsmcgraw XenophonF: Maybe just force each minion into the 'base' environment you mean?
16:40 XenophonF drawsmcgraw: no my base environment is completely empty
16:40 drawsmcgraw OH
16:40 VR-Jack2 We should have converted all / paths to file:// internally and processed the file scheme for all such cases.
16:42 capricorn_1 joined #salt
16:42 Gareth morning morning
16:43 XenophonF drawsmcgraw: minions match only one of three environments (dev/test/prod)
16:43 XenophonF of course, that makes deploying staged changes to prod a little tricky
16:44 adelcast joined #salt
16:44 drawsmcgraw You must be good at assigning environments :)
16:44 XenophonF b/c sometimes that means i need to run refresh_pillar saltenv=staging in addition to running state.sls saltenv=staging
16:44 drawsmcgraw right
16:45 XenophonF i assign the environment based off the minion id
16:45 nitay joined #salt
16:46 Fiber^ joined #salt
16:46 mr_const mkillebrew, seems to be working, thanks :)
16:46 otter768 joined #salt
16:47 mkillebrew I had the same issue going through a firewall, even thought it had an application rule. After a bit the minions would show connected on netstat, but were ,for all intents and purposes, dead.
16:48 VR-Jack2 yeah, in systems still using system-iptables, restarting the tables will generally screw the minion up for awhile
16:48 VR-Jack2 it resets the state information
16:49 amcorreia joined #salt
16:50 Brew1 joined #salt
16:51 linjan joined #salt
16:51 breakingmatter joined #salt
16:52 zwi joined #salt
16:53 iggy mr_const: there was also a bug in older salt versions that wouldn't enable keepalives on the return port
16:53 pipps joined #salt
16:57 Brew joined #salt
16:58 writtenoff joined #salt
16:59 prometheus_ joined #salt
16:59 VR-Jack2 So the unit tests check the underlying functionality. Do we have any tests that check the high level functionality?
17:00 VR-Jack2 I'm guessing not given the errors
17:02 VR-Jack2 wheel is especially bad since we hard return True to it's calls no matter what. :(
17:03 mr_const another question: is it possible to reference pillar key inside of same pillar config file?
17:04 mapu joined #salt
17:04 mr_const I wrote "work_mode: server"
17:04 mr_const then: {% if pillar.get('work_mode') == 'server' %}
17:04 VR-Jack2 mr_const: I've never seen pillar referencing pillar work. I usually do import_yaml in jinja and reference
17:04 mr_const pillar.get returns empty string
17:04 VR-Jack2 correct, and doesn't even have to be the same file
17:05 VR-Jack2 best option I have come up with is a special yaml file that contains reusable data. Then import_yaml and use as needed in all pillar files
17:06 mr_const hm... seems a little bit overcomplicated
17:06 VR-Jack2 not really. one sec
17:06 VR-Jack2 mr_const: https://gist.github.com/vr-jack/fa71b7e452dbfdb1cfe4
17:07 VR-Jack2 This used a valid pillar file, but you don't have to
17:07 dstokes joined #salt
17:07 nitay joined #salt
17:08 mr_const VR-Jack2, thanks
17:08 DanyC mr_const: isn't this what you are asking for? https://groups.google.com/forum/#!topic/salt-users/efvoj1Z4tMY
17:08 dstokes joined #salt
17:09 DanyC mr_const:  which seems was merged following a PR into the code but not sure on which version it is
17:10 CeBe joined #salt
17:11 sdm24 DanyC, mr_const: taken from the PR: "Looks like it will be in the Boron release (the release after 2015.8)."
17:11 mr_const DanyC, yeah looks like, thanks
17:12 sdm24 but ooh that will be sweet when its in
17:12 jaybocc2 joined #salt
17:12 DanyC mr_const: pleasure. sdm24 thanks for that. I guess will be close to XMAS so Santa can drop the gift :)
17:13 iggy it will probably be next year
17:13 stoogenmeyer joined #salt
17:13 claytron_ joined #salt
17:14 iggy 2015.5 was supposed to be 2015.2, then 2015.8... they've been keeping a roughly 6 month release cadence, so I wouldn't expect boron before 2016
17:14 iggy I'd love to be proven wrong though
17:14 forrest joined #salt
17:18 cpowell joined #salt
17:20 VR-Jack2 even at 6 months, there's issues with QA
17:21 aqua^c joined #salt
17:22 krymzon joined #salt
17:23 VR-Jack2 wonder if jenkins can handle what I need. deploy master at branch X, deploy minions at branch X,Y,Z; run set of tests to verify functionality.
17:24 VR-Jack2 I can manually script it locally mostly in bash, but that doesn't help the project
17:25 breakingmatter joined #salt
17:25 saltycharles joined #salt
17:25 spark_ joined #salt
17:26 CeBe joined #salt
17:27 dfsgdfg joined #salt
17:28 ajw0100 joined #salt
17:29 gcfhvjbkn joined #salt
17:29 dthom91 joined #salt
17:31 conan_the_destro joined #salt
17:31 markm joined #salt
17:34 andrew_v_ joined #salt
17:36 pi3r13 joined #salt
17:37 ajw0100 joined #salt
17:38 troyready joined #salt
17:41 pipps joined #salt
17:44 baweaver joined #salt
17:45 DanyC VR-Jack2: hehe, then get rid of Jenkins :))
17:45 druonysus joined #salt
17:46 VR-Jack2 DanyC: jenkins is used for the build process on saltstack. I'm not sure to what degree, but I presume it runs all the unit tests. Functional tests require a bit more work.
17:47 iggy kitchen sink?
17:47 iggy or whatever it's called
17:47 DanyC VR-Jack2: everyone has the same problems ;)
17:48 VR-Jack2 A functional test has to load up both master and minions (including older versions) and then test each function in context. ie, via salt-run, via salt, via salt-call
17:48 VR-Jack2 of course, not all functionality is supported in all 3
17:49 VR-Jack2 for example, wheel.* functions must be run via salt-run
17:49 spark_ joined #salt
17:51 dthom91 joined #salt
17:56 iggy and most important, you need docs so new features can get tests without a rocket science degree
17:57 claytron_ joined #salt
17:58 venu0336_ joined #salt
18:02 venu0336_ joined #salt
18:02 VR-Jack2 iggy: true. ideally, the tests would be provided by the feature provider matching the docs for feature
18:02 VR-Jack2 my theory is that we'd have to have a 4th build server to handle it.
18:02 omegamike joined #salt
18:03 VR-Jack2 the 3rd build could do it, but it would probably be nicer to separate them out
18:04 VR-Jack2 ideally, we'd also take snapshots of feature test times and compare them as we go through different versions and builds.
18:04 fxhp joined #salt
18:04 VR-Jack2 That would let us track slowdowns
18:05 pm90__ joined #salt
18:06 rdutch joined #salt
18:06 VR-Jack2 building of _cache takes x time on version X vs version Y. file.managed took x time on version X vs version Y. etc.
18:07 VR-Jack2 or how it differs from salt-run, salt-call, salt in runtimes
18:09 VR-Jack2 either way, it requires support of the corporate dev team, I suspect, since they handle the build process to my knowledge.
18:10 funzo joined #salt
18:11 VR-Jack2 It would be nice if it's relatively easy to run the functional tests outside the build system, though, so we could verify locally.
18:11 baweaver joined #salt
18:13 VR-Jack2 major issue of that would be dealing with the various minions. presumably virtualized minions
18:15 zmalone joined #salt
18:16 icflournoy joined #salt
18:18 AndreasLutro joined #salt
18:21 jaybocc2 joined #salt
18:23 toddnni joined #salt
18:24 viq joined #salt
18:29 toddnni joined #salt
18:32 andrew_v joined #salt
18:33 jvv joined #salt
18:35 deedubs left #salt
18:36 andrew_v joined #salt
18:37 nzero joined #salt
18:38 druonysus joined #salt
18:38 druonysus joined #salt
18:39 clintber_ joined #salt
18:39 X67r joined #salt
18:42 pm90__ hello, if I want to configure a password for a user using salt minion, is there a way to do so using salt states?
18:42 sdm24 http://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
18:42 deedubs joined #salt
18:42 sdm24 just use user.present with the password field set. If the user exists, Salt won't change those other settings
18:43 pm90__ sdm24: thanks!
18:43 sdm24 np
18:45 dezertol joined #salt
18:46 Tyrm joined #salt
18:47 jaybocc2 joined #salt
18:47 otter768 joined #salt
18:47 Tyrm joined #salt
18:49 nitay joined #salt
18:49 fridder joined #salt
18:49 icflournoy joined #salt
18:51 Tyrm_ joined #salt
18:51 Tyrm__ joined #salt
18:53 dthom91 joined #salt
18:53 peno joined #salt
18:55 X67r joined #salt
18:58 yomilk joined #salt
18:58 baweaver joined #salt
18:59 stoogenmeyer joined #salt
18:59 stoogenmeyer joined #salt
19:00 Furao joined #salt
19:00 rdutch left #salt
19:00 nitay joined #salt
19:00 stoogenmeyer joined #salt
19:01 stoogenmeyer joined #salt
19:02 dthom91 joined #salt
19:02 stoogenmeyer joined #salt
19:03 stoogenmeyer joined #salt
19:03 khaije1 joined #salt
19:04 stoogenmeyer joined #salt
19:04 stoogenmeyer joined #salt
19:05 bhosmer_ joined #salt
19:05 stoogenmeyer joined #salt
19:06 X67r joined #salt
19:06 dezertol joined #salt
19:06 stoogenmeyer joined #salt
19:06 davisj Is there a simple  way to target based on cidr within in a state? I could parse the content of grain['ipv4'] but that seems clunky.
19:07 stoogenmeyer joined #salt
19:07 dezertol left #salt
19:07 iggy davisj: you don't target in a state, you target in the top file
19:08 stoogenmeyer joined #salt
19:08 davisj iggy: Sorry, meant a template :)
19:08 iggy davisj: you don't target in a template, you target in the top file
19:09 davisj iggy: i.e. {% if grains['host'] in [some, list] %}
19:09 stoogenmeyer joined #salt
19:09 dezertol joined #salt
19:09 stoogenmeyer joined #salt
19:10 * davisj wants to do {% if '10.0.0.0/24' in grains['cidrs'] %}
19:10 davisj but grains['cidrs'] does not exist (as far as I know)
19:10 stoogenmeyer joined #salt
19:10 davisj I figurd that'd be a fairly common pattern.
19:11 Sketch joined #salt
19:11 iggy you should really target in the top file
19:11 davisj * figured, even
19:11 funzo joined #salt
19:11 stoogenmeyer joined #salt
19:11 bhosmer_ joined #salt
19:11 davisj iggy: highstates are a dangerous proposition in my env. so I need some logic at a lower level
19:11 iggy but if you insist on _not_ doing what you're supposed to, there's salt.modules.network.in_subnet
19:12 stoogenmeyer joined #salt
19:12 davisj iggy: thanks for handing me that shiny gun ;)
19:12 stoogenmeyer joined #salt
19:13 iggy You're welcome Barney Fife... err, davisj
19:14 davisj how'd you know the $env == Mayberry!!??
19:15 stoogenmeyer joined #salt
19:15 nitay joined #salt
19:16 stoogenmeyer joined #salt
19:17 stoogenmeyer joined #salt
19:21 nitay basepi: if ure there, ive been having a potpouri of issues - first my current instances seem to be broken regarding pip getting KeyError: ‘pip.installed’ - seems similar to https://github.com/saltstack/salt/issues/25813, then I tried to make salt-cloud provision instances with stable 2014.7, I get an SSH error unless I add -c /tmp/ to script_args, but then when I do that it doesn’t seem to actually write the minion configs, so I just get
19:21 saltstackbot [#25813]title: debconf.set throwing exception in 2015.8.0rc2 | trying to use the current RC for dev work. and ran into this bug on a state that was working. ...
19:21 nitay bare minion not pointing to right master
19:22 nitay just trying to find something stable that works
19:23 claytron_ joined #salt
19:23 DanyC joined #salt
19:23 mapu_ joined #salt
19:29 pi3r13 joined #salt
19:30 breakingmatter joined #salt
19:31 nitay joined #salt
19:32 baweaver joined #salt
19:34 GreatSnoopy joined #salt
19:39 tercenya joined #salt
19:46 danielcb joined #salt
19:47 viq joined #salt
19:48 nitay joined #salt
19:49 stoogenmeyer joined #salt
19:50 nitay joined #salt
19:50 stoogenmeyer joined #salt
19:51 stoogenmeyer joined #salt
19:52 stoogenmeyer joined #salt
19:53 stoogenmeyer joined #salt
19:53 DammitJim why do you guys think I'm having this problem? http://pastie.org/10342441
19:54 DammitJim it doesn't install the package hp-snmp-agents
19:54 stoogenmeyer joined #salt
19:55 stoogenmeyer joined #salt
19:56 Barbarossa left #salt
19:56 stoogenmeyer joined #salt
19:57 stoogenmeyer joined #salt
19:57 whytewolf DammitJim: hopeing there is a paste error there. cause that repo doesn't look right in that paste. I'm seeing it there as trust    y current/non-free
19:57 VR-Jack2 DammitJim: does the repo itself install? if .installed is running first, that might cause some issues. Recommend also using -l debug with salt-call
19:57 stoogenmeyer joined #salt
19:58 DammitJim oh yeah, it was my terminal copy
19:58 mapu joined #salt
19:58 DammitJim if I go to the server and do an apt-get update, it works without errors
19:58 DammitJim and apt-cache search finds hp-snmp-agents
19:58 DammitJim just don't know why the state doesn't install it
19:59 DammitJim or is something out of order?
19:59 XenophonF left #salt
20:00 godlike hello again... so... any particular reason why file accumulators wouldn't work with blockreplace? I have the following: https://gist.github.com/godlike64/934199d8e6087ce5b89a but the "source [...] /cpuflags" is not being added to the managed zone
20:00 ntropy DammitJim: did you try with some debug, also maybe call the pkg module directly salt-call -l debug pkg.install hp-snmp-agents
20:01 bhosmer_ joined #salt
20:02 DammitJim I'll try the debug
20:02 druonysuse joined #salt
20:02 druonysuse joined #salt
20:02 iggy davisj: you should have a require_in on the pkgrepo
20:02 iggy err DammitJim ^
20:02 DammitJim oh
20:02 * iggy uncalls davisj
20:03 baweaver joined #salt
20:03 aqua^c joined #salt
20:03 VR-Jack2 Well, he should, but if the manager is finding the package, the repo is apparently installed already
20:04 godlike forget I said anything, I just fixed it (PEBKAC)
20:05 dthom91 joined #salt
20:05 DammitJim where does this require_in fit, though?
20:05 DammitJim do I need to create a separate section with hp-nsmp-agents: pkg.installed ?
20:06 pipps99 joined #salt
20:06 zwi joined #salt
20:08 iggy DammitJim: it goes in the pkgrepo section and is a list of - pkg: hp-pkgs
20:09 iggy require_in on pkgrepo is special, it makes sure not only that the state has run (which natural ordering would have done here), but it also makes sure the minion runs apt-get update
20:10 sdm24 however, if it can't find the repo, won't it still try to run pkg.installed?
20:11 vexati0n quick question - I have a number of Ubuntu servers. Some of these servers have package X installed (i don't want it installed on all of them, but which ones have or don't have it is arbitrary). How do I tell a state to execute only if package X is installed?
20:11 sdm24 maybe also put - refresh: True under the pkg.installed section, so that it will refresh the repo
20:11 sigtom joined #salt
20:11 iggy if the require_in works correctly, refresh: True shouldn't be necessary
20:12 sdm24 vexati0n: One way I do it is to test if a directory specific for that package
20:12 sdm24 so - onlyif: test -d /etc/salt
20:12 green_ joined #salt
20:12 sdm24 will only run whatever if /etc/salt exists, which should only exist if a  salt package is installed
20:13 sdm24 iggy: ah, didn't know that  about require_in
20:13 sigtom Howdy, Im working on joining some centos servers to an AD domain.  I see in windows theres a join_domain module, is there anything similar for *nix?
20:13 la250 joined #salt
20:13 DammitJim weird... still no luck :(
20:14 vexati0n sdm24: that was one way I was trying. But since the "require" directive only links to the name of another state ID, that state ID would ultimately run on everything.
20:14 iggy we've been getting the "how do I make a state only run if another X has already run" type of question a lot lately... makes me think people don't quite understand Salt's concepts all that well
20:14 sdm24 vexati0n: I use - unless and -onlyif with tests for a directory
20:15 vexati0n iggy: or, Salt needs to be a bit more adaptable ;P
20:16 DammitJim weird... -l debug doesn't say anything new
20:16 BradThurber_ joined #salt
20:16 DammitJim I added the require_in: and still no go
20:16 sdm24 or using jinja: {% if 0 == salt['cmd.retcode']('test -d /etc/package/directory') %} to only run things if the directory exists, or 1 == if you want to run if the directory doesn't exist
20:16 nkuttler joined #salt
20:16 DammitJim why doesn't salt want to install the package?
20:16 iggy DammitJim: can you paste the current state and the output?
20:16 sdm24 ^ vexati0n
20:17 DammitJim http://pastie.org/10342494
20:18 iggy DammitJim: try what sdm24 said, - refresh: True under the pkg.installed stanza
20:19 nethershaw joined #salt
20:19 DammitJim ok, going again
20:20 DammitJim is there a way to show progress when executing a state?
20:20 DammitJim even with -l debug, it just sits there
20:20 manfred you would have to be on the minion and checking /var/log/salt/minion
20:20 manfred from the master, you only see the end results, when the minion makes it's return
20:20 la250 @iggy maybe i'm one of those that doesn't get the concepts that well, but i think i have a similar question, hopefully you all haven't tried to answer it a million times.. trying to get three unique commands to run to register a server with one of our services but they need to be done in a certain order. is there a good way to do that?
20:20 manfred it returns everything at once, not in chunks
20:20 DammitJim man, still same issue
20:21 manfred DammitJim:  you could run salt-call state.highstate -l debug from teh minion and see progress
20:21 la250 using cmd.run
20:21 DammitJim http://pastie.org/10342503
20:21 sdm24 la250: you can do - order: http://docs.saltstack.com/en/latest/ref/states/ordering.html or require/other requisites http://docs.saltstack.com/en/latest/ref/states/requisites.html
20:21 iggy la250: that's fairly normal I think, just have state C watch state B watch state A
20:22 iggy it's when you want to target a state at a bunch of hosts when it's only supposed to run on some subset
20:23 iggy that's the part that noone has yet to give me a concrete purpose for doing (aside form laziness or doing something wrong)
20:23 la250 ok. i was hesitant to use order because it seemed like the documentation discouraged it
20:23 iggy it is discouraged
20:23 la250 i must have the require statements done wrong, that's what i've tried
20:23 sdm24 you do lose a lot of idempotency with it
20:23 iggy if you just want things to run in a certain order, just write them in the sls file in order
20:23 lexter joined #salt
20:24 iggy la250: you can always paste the states you are testing and let us look at them
20:24 la250 that works to have them in that order?
20:24 sdm24 dammitjim: random idea, but have you tried removing the repo, and then re-adding it and retrying the state?
20:24 iggy Salt processes sls files top-down by default
20:24 DammitJim yes, sdm24 I've deleted the repo
20:25 la250 it's pretty simple. just cmd.run  referring to three different commands with the name option. then I tried to required below 2 of the 3. how do you refer to the other states?
20:25 iggy DammitJim: what command are you running to get that output?
20:25 la250 but if its just top down i should be set
20:26 DammitJim salt -l debug '<servername>' state.sls hp
20:26 iggy la250: that's why it's best to paste, we can see exactly what you're doing, instead of just guessing at what order you used, any extras, etc...
20:26 sdm24 and any syntax errors
20:26 iggy la250: you could have something else that changes order that you didn't think to mention, but that actually makes a huge difference
20:27 dopesong joined #salt
20:27 DammitJim what is the command to install a package?
20:27 testuser33221 joined #salt
20:27 Corey Gareth: Or extend the RVM state.
20:27 testuser33221 Hi all. I installed salt thorugh python2 setup.sh install
20:28 testuser33221 hw do I remove it? turns out I might have messed up my setup by installing this way.
20:28 testuser33221 using centos.
20:28 sdm24 DammitJim: do you mean the salt execution module? pkg.install. Or do you mean apt-get install?
20:28 claytron_ joined #salt
20:28 testuser33221 Just getting started with salt. Can't locate removal command anywhere or through google
20:29 la250 https://gist.github.com/anonymous/7f7bf61774121130ba69
20:29 DammitJim pkg.install
20:29 la250 that is the basic idea, the commands themselves shouldn't effect it
20:29 sunkist joined #salt
20:30 sdm24 la250: do you want schedule to run first?
20:30 DammitJim sdm24, weird... when I did salt '<servername>' pkg.install hp-snmp-agents
20:30 DammitJim it returned -----
20:30 DammitJim for the <servername>
20:30 iggy la250: I commented
20:31 la250 No, the pkg should run first
20:31 la250 sorry the register
20:31 iggy la250: but yeah, just writing them in the order you want them to run will work too (unless you have something else that changes the order)
20:31 sigtom Are there any modules that can help in joining a Linux server to an AD domain, or will i need to write out the module myself calling winbind?
20:31 sdm24 DammitJim: I wonder what happens if you do cmd.run: apt-get install hp-snmp-agents
20:31 iggy sigtom: I've never seen anything to do it
20:31 DammitJim I'm going to do that now
20:31 la250 ah, thats what i was looking for. ok thats simple enough, should've just expected that
20:32 la250 ty
20:32 sigtom_ joined #salt
20:32 sdm24 la250: to get register to run first, change the require: to require_in:
20:33 sdm24 or move the require under the register cmd.run, or move the register section above the schedule section
20:33 DammitJim sdm24, that kinda worked (it gave me the summary and asked Y/N)
20:33 sdm24 cmd.run : - name: apt-get install -y hp-snmp-agents
20:34 DammitJim sdm24, do you want me to test installing like that vs pkg.install?
20:34 sdm24 well if it works...
20:34 DammitJim if it works, then what?
20:34 sdm24 I mean, I know its not the "saltiest" way, but it gets the package installed, right?
20:34 breakingmatter joined #salt
20:35 catpig joined #salt
20:35 DammitJim oh, I can install them by ssh'ing into the server
20:35 DammitJim that's not my issue
20:35 DammitJim I need to do it in a lot of minions
20:35 DammitJim and I want to have a record of it... not a one-off
20:35 dthom91 joined #salt
20:35 venu0336 joined #salt
20:35 sdm24 you can do cmd.run in the state
20:35 Akhter iggy: Just FYI, the issue was with salt-minion 2014.7.0  2014.7.5 works, just in case you care.
20:36 sdm24 Idealy though, I agree you would want to use pkg.install
20:36 DammitJim I like how you think outside the box with cmd.run
20:36 DammitJim but these are the things that later on are going to come back and bite me
20:36 sdm24 definitely
20:37 DammitJim maybe there is a problem with apt
20:37 sdm24 cmd.run is always my fallback. If I can't find a different way to do it, its there
20:37 twork i'm trying to set up a BIND service using a pillar file i cribbed from the formula. apparently as i was trimming it down i goffed it up somehow, because 'salt-call pillar.get [anything under bind]
20:37 twork ...always comes back empty.
20:38 twork the log doesn't tell me much more than the command line does.
20:38 iggy Akhter: what was the issue again?
20:38 sdm24 can you post the pillar file?
20:38 Brew1 joined #salt
20:38 iggy Akhter: (sorry, been a busy day, I'm having trouble keeping track)
20:39 Akhter iggy: I couldn't use subprocess with pipe.
20:39 Akhter and when calling __salt__['cmd.run'] it wouldn't return anything.
20:39 twork adm24: you're asking me? if so, yeah, give me a sec to make sure i'm not putting in anything i don't want you evil people to see
20:39 LtLefse DammitJim: can you clarify what you mean by "it returned ----- for the servername"?
20:39 twork rather, sdm24
20:39 sdm24 twork: definitely don't want to release sensitive info
20:39 Akhter Either way, I went back to subprocess on the new minion, I'd have to test out __salt__['cmd.run'] again.  If it does work, it'd be much less code.
20:39 sdm24 I once uploaded our SSL keys to git X_X
20:40 venu0336 joined #salt
20:40 twork sdm24: well done
20:40 nitay joined #salt
20:40 Akhter iggy: TypeError: can't serialize <subprocess.Popen object at  -- That was the original issue.
20:40 twork i love it when other people relate stories like that. reassures.
20:41 iggy Akhter: ahh, weird, the changes I was thinking of in that area weren't even in 2014.7 (they were in 2015.2...5)
20:41 Brew joined #salt
20:41 ajw0100 joined #salt
20:41 testuser33221 Anyone know how to uninstall from a git "setup.py install" setup?
20:41 sdm24 and now I how how to (google to find the page to) remove files from all git commits
20:41 Akhter iggy: Well I thought the same, which is why I tried out the salt module you had suggested but I couldn't actually launch my own module.  It would always report "'ipmitool.ipmiIp' is not available."
20:42 funzo joined #salt
20:42 Akhter And when set as a grain it wouldn't actually register at all.
20:42 iggy Akhter: were you sync_all'ing after editing?
20:42 Akhter Yeah.
20:42 Akhter sync_all and individual sync_module/grains
20:42 Akhter Just in case something was off.
20:42 Akhter But now, the grains and the module works.  So it wasn't just me :)
20:43 Akhter Let me try out the module you had suggested before, rather than using subprocess.
20:43 yomilk joined #salt
20:44 twork sdm24: https://gist.github.com/mjinks/117e10afec071252b8cc
20:44 twork i don't think there's anything in there to get me called on the carpet
20:44 sdm24 I think you can only have 1 "bind" header
20:44 twork huh. the example had many, many
20:44 twork that's all cribbed stuff
20:45 sdm24 really? I thought it would overwrite
20:45 twork i was confused about that as well, but, new here...
20:45 sdm24 does "salt '*' pillar.get bind" return anything?
20:45 twork lots of cases of where i don't quite grok the signficance of a string based purely on its significance. people gribe bout formats like xml but...
20:46 twork ^purely on its immediate context, rather
20:46 twork no, pillar.get bind does not
20:47 sdm24 in /srv/pillar/top.sls (or wherever your pillar top file is), are you assigning the bind.sls file to the correct minions?
20:48 twork there again, funny you should ask
20:48 DammitJim something is strange if this thing is returning: - - - - - - - -
20:48 twork i started this out with tagged assignments, thought i might bein doing that wrong, now i'm (for now) assigning every pillar file to every minion.
20:49 sdm24 so base: \n  '*': \n  - bind
20:49 quasiben1 joined #salt
20:49 sdm24 or something like that?
20:49 iggy twork: sdm24 is correct, you can only have one dict key in the same dict
20:49 twork yep
20:49 sdm24 what does salt '*' pillar.items give (in terms of relevance to bind)
20:49 twork and, data from other items in those files does come back
20:49 twork ...but bind data does not.
20:49 twork i get an error... let me scroll back...
20:50 DanyC Hey guys, need a hand in understanding the flow between master/ minion registration area. So let's asume the Master is configured to accept any key, what is the flow once Minion is started?  Does it makes a call straight after is started, does first wait a time (if yes which parameter is it) before attempting to auth wiht Master?
20:50 alias_ joined #salt
20:50 iggy DanyC: a minion tries to auth with the master when it starts up (immediately)
20:50 VR-Jack2 yeah, I think it will merge keys between yaml/sls files but not in the same one
20:51 iggy by default it won't even do that
20:51 iggy only if you set it to
20:51 VR-Jack2 iggy: mine always merged by default if it was a dict
20:52 VR-Jack2 or rather, it was a mix. multi-layer dicts would merge, but actual keys would overwrite, including lists.
20:53 twork sdm24: oh yeah, in my current state of thrashing around i am getting, from 'state.highstate': "Rendering SLS 'bind' failed. Please see master log for details." ...but the log doesn't tell me much more than that.
20:53 DanyC iggy: you sure? http://paste.openstack.org/show/412374/ it doesn't happen and the reson why i ask is because before going to the rabbit hole of strace i want to understand the low level flow which i can't seem to find it on the docs (i.e having all the params which might afffect things)
20:53 twork so that does tell me that (i think) the troube is indeed in my pillar.
20:53 Akhter iggy: That works, however the output isn't what I want.  I just want the ip and that returns the IP + text, which I parsed out with bash/awk.
20:53 Akhter output = __salt__['cmd.run']('/usr/bin/ipmitool lan print 1 | awk "/IP Address    / { print $4 }"', python_shell=True, output_loglevel='trace')  Looks like it doesn't accept the "{ print $4 }"
20:54 VR-Jack2 twork: you can only have a single bind: per file.
20:54 twork VR-Jack2: so, the posted formula is wrong?
20:54 twork ...or, i'm using it wrong?
20:54 sdm24 twork: I just tried with multiple headings of the same key, and it didnt work
20:55 sdm24 https://gist.github.com/sdm24/02b710a6c837212f0147 that fials
20:55 VR-Jack2 twork: That would be my guess. you could put each of those bind: in a different file and it would merge
20:55 sdm24 fails* none of them get loaded as a pillar
20:56 VR-Jack2 salt does tree merges, but only between different files
20:56 VR-Jack2 and the keys (endpoints) overwrite instead of merge
20:56 iggy there's a bug open about all this
20:57 iggy it has much more detail than we could cover in an irc channel
20:57 VR-Jack2 but in a single file, the tree must be unique
20:57 twork huh. okay, i wondered if maybe the "this: \n that: [stuff] \n this: \n other: [stuff]
20:57 twork ...format was producing distinct items, like "this:that", "this:other", that the pillar saw as different
20:58 sdm24 twork: https://gist.github.com/sdm24/02b710a6c837212f0147
20:58 VR-Jack2 it builds a tree, but merging/overwriting (when they work) only occurs from a new file into the current pillar tree. Not while processing a single file
20:58 sdm24 for me, it wasn't even merged or overwritten. It just wasn't processed
20:59 iggy DanyC: I guess it depends what you mean... yes, the minion reads the config file first, and then does another couple of things that would impact what master it would actually try to connect to, then tries to connect
20:59 twork sdm24: i think that's what's going on here as well -- just nothing coming out of the processing
20:59 sdm24 twork: yep, but removing the multiple headers fixed it
20:59 iggy DanyC: what is your actual problem?
21:00 yomilk joined #salt
21:00 VR-Jack2 sdm24: yours was a single file, though. put each in a different sls and it should merge/overwrite
21:00 twork now let me go make sure i've handled my cargo-culted code correctly to begin with
21:00 sdm24 VR-Jack2: maybe, but I thought twork's were a single file as well. I'll test it now
21:01 iggy I wouldn't count on things being merged
21:01 twork sdm24: it was, or so i perceived.
21:01 DammitJim oh, I found something interesting!!! WARNING: The following packages cannot be authenticated!
21:01 VR-Jack2 smd24: his is, and it should never work in a single file
21:01 iggy the rules for how that works (and the complete lack of rules for how that works) are a mess
21:01 DammitJim how do I get around this problem for this added repo?
21:01 Vynce joined #salt
21:01 amcorreia_ joined #salt
21:01 iggy DammitJim: is there a gpg key somewhere for it?
21:01 VR-Jack2 yeah. merginging/overwrite are very test oriented. Test them and make sure they work for the version you are using.
21:01 sdm24 oh wait I have production examples where multiple files will merge to a key
21:02 DammitJim ok, that's the issue, then
21:02 timoguin joined #salt
21:02 Vynce1 joined #salt
21:02 pipps joined #salt
21:03 DanyC iggy: right so my prob is the following: I'm running the latest version (master/ minion match) on CentOS vms started on OpenStack (all security groups are in place, no selinux). Master is running all and nice and when i launch a new VM, the 1st highstate run it takes a long time (over 10 min) to complete.  I have tried multiple things like: set startup_state: sls and then appliy few state files, set startup_state: highstate - no luck
21:03 twork here's what i've been cribbing from, maybe it just assumes i know not to crib in the manner i have been: https://github.com/saltstack-formulas/bind-formula/blob/master/pillar.example
21:03 DanyC iggy: i looked at a bug mentioned by babilen following a minion restart things might take longer but didn't help
21:04 sdm24 DanyC: try commenting out or renaming your highstate top.sls, then connect the minion, revert the top.sls changes, and run the highstate
21:04 druonysuse joined #salt
21:05 iggy dammitjim: add `- key_url: https://downloads.linux.hp.com/SDR/repo/mcp/GPG-KEY-mcp` to your pkgrepo stanza
21:05 DanyC iggy: as you can see from the logs i shared it spends a ton of time doing nothing, even the first call to attempt register wiht master is after 2+ min
21:05 iggy where did he go
21:05 iggy DanyC: connect to the minion, stop the service, then start salt-minion -l debug on the command line directly
21:05 VR-Jack2 twork: either put each bind: in a different file or combine them all into a single bind:
21:06 timoguin joined #salt
21:06 iggy twork: mind opening an issue for that formula that says the pillar.example needs a ton of documentation written for it
21:06 DanyC iggy: give me few min and will provide the minion logs in trace mode if is better :)
21:06 twork VR-Jack2: okey-dokey. is this a situation that merits a bug ...was just asking, thatnks
21:06 VR-Jack2 twork: works as intended on that part
21:06 twork thanks iggy
21:07 VR-Jack2 but if the docs say otherwise, that is a bug
21:07 pipps joined #salt
21:07 pipps99 joined #salt
21:08 twork VR-Jack2: you lost me there. what works as intended on what part? nothing i've used here has worked in any way.
21:08 VR-Jack2 twork: haviing duplicates like that in a single file should break
21:08 sdm24 http://docs.saltstack.com/en/latest/topics/pillar/index.html#pillar-namespace-merges that says that you can merge multiple .sls under a key, as long as there are no conflicts
21:08 twork aha!
21:08 VR-Jack2 twork: docs saying that it is okay to do that are wrong
21:08 VR-Jack2 ie, bug report the docs
21:08 twork VR-Jack2: salt works, the formula does not.
21:08 twork got it
21:09 sdm24 it doesn't outright say "you can't user the same header in the same file multiple times"
21:09 twork now then: uh, having never filed a bug report in this context... where do i go?
21:09 VR-Jack2 sdm24: yeah. it doesn't, but the rules have always been that way. merge only improves .sls merges. I believe that is a yaml restriction
21:10 iggy DanyC: trace isn't necessary, and if you do what I said it precludes things like... rogue minion processes interfering, etc.
21:11 VR-Jack2 twork: should file it here I believe. https://github.com/saltstack-formulas/bind-formula/issues
21:11 VR-Jack2 mention documentation
21:13 bandito joined #salt
21:13 claytron_ joined #salt
21:13 twork VR-Jack2: (et al) many thanks
21:13 VR-Jack2 all forumulas are their own repo under the saltstack-formulas user. each does their own tickets
21:13 twork ok
21:14 iggy well, technically we all do them, but github doesn't have the ability to do per-org issues/etc
21:14 bandito hi folks, I'm struggling with file.recurse and exclude_pat, trying to include one directory inside another: http://pastebin.com/pvW2LxQ5  every time I run highstate, it always shows both of those as Changed even if the underlying content hasn't changed
21:14 twork aha, the 'issues' link, yeah?
21:14 sdm24 ah I at least figured out why the pillar errors just say "see master log": The error is protected because it's possible to contain templating data which would give that minion information it shouldn't know, like a password!
21:15 VR-Jack2 twork yeah
21:15 VR-Jack2 nice green button for new issue
21:15 twork found it, thanks
21:16 VR-Jack2 sdm24: yeah. there are exceptions. any exception which isn't trapped will show directly in the pillar.items for example
21:16 VR-Jack2 trapped, caught, whatever python does
21:16 sdm24 gotcha
21:17 * VR-Jack2 really needs to learn python
21:18 VR-Jack2 perhaps I'll learn it after I fix 100 bugs
21:18 subsignal joined #salt
21:19 DanyC iggy: sure, understood. I just did this now "connect to the minion, stop the service, then start salt-minion -l debug on the command line directly", waiting for things to happen so i can share the logs
21:19 CheKoLyN joined #salt
21:19 sdm24 bandito: I don't think exclude_pat uses regex, I think its globs
21:19 DanyC iggy: after that i'll run a 2nd test where "try commenting out or renaming your highstate top.sls, then connect the minion, revert the top.sls changes, and run the highstate"
21:19 sdm24 bandito: oh wait never mind you have that part correct
21:19 bandito sdm24: the docs for it says it does, I'll try it with 2 globs though
21:20 sdm24 yeah, its in the include_pat docs. But even there, they don't use .* to match everything, they just leave it as E@hello
21:20 VR-Jack2 it does regex if you do E@
21:21 bandito yeah looks like you can't pass it multiple globs either
21:21 bandito ill try it without the .s
21:22 bandito still shows as changed with - exclude_pat: E@(git)|(player)
21:23 DanyC iggy: interesting what is going on, which match exactly what i saw so far. So minion is running foreground wiht -l debug. I can confirm wiht salt-run manager.status cli that it sees the minion as down
21:23 iggy DanyC: what's your master config look like (in regards to key acceptance, etc)
21:24 nitay joined #salt
21:24 VR-Jack2 bandito: it may be a bug. do a small test folder. start without things like clean/exclude and build up from there noting when it does and does not report change. run twice at least for each
21:25 DanyC iggy: salt-call key confirm the key has been accepted but yet is seen as "down" After nearly 3 min, is see the line in minion saying "[DEBUG   ] Attempting to authenticate with the Salt Master at 10.233.1.79" and then waits.
21:25 twork submitted. https://github.com/saltstack-formulas/bind-formula/issues/32
21:25 saltstackbot [#32]title: Missing documentation in pillar.example | As written, "pillar.example" has four instances of "bind:" formatted to look like the base of a pillar entry....
21:27 rideh joined #salt
21:27 pm90__ sdm24: so one more question, the password field in user state: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html is it simply the string password or the hash? If its the hash, is there an easy way to get the hash?
21:27 sdm24 you can do either
21:28 VR-Jack2 DanyC salt-key lists the key as in the accept list?
21:28 sdm24 https://gist.github.com/UtahDave/3785738 thats a good example for using a hash
21:28 DanyC VR-Jack2: correct Sir
21:28 sdm24 bandito: I was testing file.recurse, and it would only ignore a directory if I have a * at the end (not using regex
21:28 VR-Jack2 There are current bugs waiting on a fix release concerning using yaml to accept/delete keys is why I asked
21:28 bandito VR-Jack2: it looks like a bug - when I do git in isolation it works properly, because it's not referenced in the second state. when i do player in isolation, it always shows changed. I think this part of the docu is wrong: Also, when 'clean=True', exclude this pattern from the removal list and preserve in the destination
21:29 bandito sdm24: if its E@ it looks like you don't need the *, at least based on my testing here
21:29 DanyC iggy: at the bottom you can see the cfg http://paste.openstack.org/show/412447/
21:29 quasiben joined #salt
21:29 bandito sdm24: unfortunately you can't specify 2 exclude_pats for globs :(
21:29 VR-Jack2 bandito: if you can run each identically in isolation and get different results, then I must presume that player is changing somehow
21:30 sdm24 https://gist.github.com/sdm24/e95dcb2c5b78a42f5719
21:30 sdm24 bandito: you're right, E@second will also exclude it
21:30 bandito VR-Jack2: the difference is just that player is referenced in the other state - by itself of course it'll work, but its when you have 2 of them together that I have the problem
21:31 VR-Jack2 ahh, then yes it may be having issues. Did you do it as salt-call -l debug to test with all the goodies?
21:31 bandito the big-picture here is there are 2 git repos out there whose contents i want copied to web server, but the contents of one go inside of the other
21:32 bandito VR-Jack2: I'll try that
21:32 manfred bandito:  is there a reason that they aren't submodules?
21:32 VR-Jack2 umm, that may be an issue if you set clean=True
21:32 iggy DanyC: so you aren't using open_mode or something, you're accepting the key via reactor?
21:32 bandito VR-Jack2: I agree, but this is from the documentation: Also, when 'clean=True', exclude this pattern from the removal list and preserve in the destination
21:32 VR-Jack2 manfred: 2 different repos, but when checked out to working presumably they make up the webpages
21:33 VR-Jack2 I do the same with mercurial
21:33 bandito exactly
21:33 VR-Jack2 ie, I have a base pillar repo, and then repos for each of my subdirectories
21:33 clintberry joined #salt
21:34 VR-Jack2 bandito: correct, so it "shouldn't" delete the inside .git. Did you verify that it actually didn't?
21:34 VR-Jack2 Also, even though it's keeping it, it may still report it as a change (without actual changes made)
21:35 DanyC iggy: not at all. In fact the only params which are uncomment are: log_level_logfile/ fileserver_backend/ file_roots
21:36 VR-Jack2 bandito: in other words, if it doesn't delete the sub repo (verify that), then reporting changes without any actual changes reported may be a big in that specific instance.
21:36 bandito VR-Jack2: salt-call shows that it is deleting and re-creating the inside git
21:36 VR-Jack2 so it missed the exclude
21:36 VR-Jack2 you need to fix that part
21:36 bandito correct
21:37 nitay joined #salt
21:37 bandito well
21:37 VR-Jack2 recommend just doing the parent one
21:37 VR-Jack2 manually create your sub one
21:37 VR-Jack2 ie, mkdir
21:37 VR-Jack2 tweak, repeat until it stays
21:37 iggy DanyC: what were you saying not at all to?
21:37 DanyC iggy: sorry, as in not using open_mode at all.
21:38 bandito VR-Jack2: are you saying don't use file.recurse for the 'inside' git?
21:38 DanyC iggy: just the reactor as i provided the cfg
21:38 iggy DanyC: does your testing involve killing the minion completely and respinning it completely? or are you merely constantly stopping and starting the minion?
21:39 benvon joined #salt
21:39 VR-Jack2 bandito: not while testing the clean=true / exclude
21:39 VR-Jack2 ie, just add a file/directory yourself manually then rerun the first and see if it deletes it
21:40 VR-Jack2 fix the clean/exclude part first if possible. then worry about the second recurse
21:40 sdm24 bandito: dunno if this helps, but https://gist.github.com/sdm24/1bd65b33e45cebbef929 excludes multiple directories and files in different paths
21:40 iggy DanyC: does this only happen on 1 minion or multiple? Have you tried a minion on the same host as the master?
21:42 DanyC iggy: so the flow is like this - via HEAT i'm creating new VM ans as part of the user_data (in the bash section) i say:  echo master: $master >> /etc/salt/minion;  echo id: $HOSTNAME >> /etc/salt/minion and then i say
21:43 DanyC iggy:  service salt-minion restart; sleep 60; time salt-call state.highstate ; sleep 60 ;service salt-minion restart; sleep 60 ;time salt-call state.highstate
21:43 bandito sdm24: ty
21:43 sdm24 bandito: np. I updated it a little because empty dirs weren't being copied over
21:43 bandito VR-Jack2: without the 'child' managed file it all works as expected
21:44 DanyC iggy: on the last test i only left the first restart command in. it happens on all minions regardless. On master there is already aminion running fromt he first time i spun the VM wiht the master on it
21:44 iggy DanyC: can you test open_mode to see if it's maybe a timing issue with the reactor/wheel setup?
21:44 DanyC sure i can, 2 min and will report back
21:44 la250 Is there a way to check an array length in an if statement? I've tried a simple {% if {{ variable }}.length > 1 %} like I might expect in jinja without success
21:45 iggy DanyC: also, does the minion on the master do the same thing (seemingly sit around for a while doing nothing at startup)?
21:46 baweaver joined #salt
21:46 VR-Jack2 bandito: did you try creating a directory and files under the directory?
21:46 VR-Jack2 ie, perhaps you didn't match the files
21:47 sdm24 la250: {% if variable | length > 1 %}
21:47 VR-Jack2 just the directory itself
21:47 DanyC iggy: i haven't monitored that. I can do it but i guess i'll have to delete any sort of cache on minion and on master for that particular "local" minion ?
21:47 bandito VR-Jack2: I'll try that
21:48 la250 thanks!
21:48 sdm24 np
21:48 VR-Jack2 banditho: might need exclude_path: E@^(
21:49 druonysuse joined #salt
21:49 VR-Jack2 banditho: might need exclude_path: E@^(\.git.*)|(player/.*)
21:50 VR-Jack2 or E@(^\.git.*)|(^player/.*) if it doesn't like the shared ^
21:50 VR-Jack2 without the .*, I suspect it will delete all files under a directory but leave the directory
21:51 bandito now this is weird, if i rm -rf the player/ folder on the minion, and empty out its contents on the master, it comes back as UNCHANGED when it creates the folder... and all subsequent runs show changed....
21:51 bandito which is the exact opposite of what i expected
21:52 TOoSmOotH joined #salt
21:52 PredatorVI joined #salt
21:53 nitay joined #salt
21:54 PredatorVI I'm using environments:  /srv/salt/base, /srv/salt/dev, /srv/pillar/base, /srv/pillar/dev, etc.  and my only top.sls file is in the 'base' directory.  I now want to test a state file that is in 'dev'.  I've included 'saltenv=dev' on the command-line but it can't find pillar data.  What am I missing?
21:54 PredatorVI I should clarify that I have both a /srv/salt/base/top.sls and /srv/pillar/base/top.sls
21:55 VR-Jack2 PredatorVI: paste the 2 relevant locations of the master config in a gist and send to us
21:55 yomilk_ joined #salt
21:55 PredatorVI kk
21:55 sdm24 PredatorVI: are you  setting a pillarenv?
21:56 VR-Jack2 sdm24: I think the problem is how it was configured. He's probably missing the duplicates, but we'll see in the gist
21:56 PredatorVI sdm24: https://gist.github.com/PredatorVI/d8df4877a3b463f73c32
21:57 VR-Jack2 yep
21:57 VR-Jack2 PredatorVI: if you want dev to have the files of base and override with files in dev, then you need to put both directories in it
21:57 funzo joined #salt
21:58 pipps joined #salt
21:58 VR-Jack2 PredatorVI: see the dev on this one: https://gist.github.com/vr-jack/cc4af609ae5604b7ec08
21:59 claytron_ joined #salt
22:00 VR-Jack2 it's an overlay. the dev in mine will use /srv/salt/dev/top.sls if it exists otherwise it will use /srv/salt/base/top.sls. Same goes for the rest of the files.
22:00 sdm24 VR-Jack2: shouldn't srv/salt/dev be above /srv/salt/base then?
22:01 VR-Jack2 sdm24: no. it goes in order. Reason is I believe it loads the files into a dist then does a merge/overwrite
22:01 bandito VR-Jack2: even with the exclude_paths as so it still does same thing: http://pastebin.com/cFz1X5Hn
22:01 DanyC iggy: check this one - so using open_mode i can see the keys were accepted super quick however doing salt-run manage.status still shows me as minions down. I will wiat a bit longer
22:01 VR-Jack2 so second directory merges/overrides the first
22:01 sdm24 oh
22:02 sdm24 http://docs.saltstack.com/en/latest/ref/file_server/file_roots.html#directory-overlay the first example is wrong then
22:02 VR-Jack2 bandito: it shows it deleting then recreating the files?
22:03 sdm24 VR-Jack2 I don't mean to call you out, but I think your order is incorrect. At least, its opposite of what the docs have
22:04 bandito VR-Jack2: yes, according to salt-call -l debug state.hightstate
22:04 VR-Jack2 sdm24: hmm. well I went by memory. *rechecks docs*
22:04 pipps99 joined #salt
22:04 sdm24 just trying to help you out
22:04 nitay joined #salt
22:05 zwi1 joined #salt
22:06 DanyC iggy: no changes i'm afraid, although the key appears to be accepted straight away, the minion is not "up" from Master pov
22:07 bmcorser joined #salt
22:07 VR-Jack2 sdm24: nope. good job. apparently I was wrong. lol
22:07 iggy DanyC: odd, we definitely don't see anything like that here... What version of salt?
22:07 DanyC iggy: hence i'm back to square 1, so annoying as i've been trying to get to the bottom of it for the last 3 days
22:07 dthom91 joined #salt
22:08 DanyC iggy: i'm running   Salt: 2015.5.2          Python: 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)          Jinja2: 2.2.1        M2Crypto: 0.20.2  msgpack-python: 0.4.6    msgpack-pure: Not Installed        pycrypto: 2.0.1         libnacl: Not Installed          PyYAML: 3.10           ioflo: Not Installed           PyZMQ: 14.3.1            RAET: Not Installed             ZMQ: 3.2.5            Mako: Not Installed
22:08 DanyC iggy: sorry for the output format
22:08 VR-Jack2 I fixed my gist
22:09 sdm24 glad I could help
22:09 VR-Jack2 Don't do environments much. Must have gotten it backwards in my memory
22:09 VR-Jack2 :(
22:09 ingslovak joined #salt
22:10 nzero joined #salt
22:10 DanyC iggy: the prob is that i have no end which i can grab and get up since all the troubleshooting paths were checked. Dunno if this is due to ZMQ or something else is missing in which case don't know where to start... hence reason i asked / tried to understand the low level steps on minions conditions to reach/ register with master
22:11 sdm24 Oh man  I just found out about test.opts_pkg. It combines pillar, grains, and options all into one list!
22:11 mvensky joined #salt
22:12 sdm24 now if only I could filter on that list...
22:12 iggy DanyC: that's kind of why I was asking about the master... take a lot of stuff out of the picture (i.e. the entire network)
22:14 VR-Jack2 sdm24: yeah. I hate it. when I run salt-ssh it runs that but then fails because it forgets how to process it. lol
22:14 DanyC iggy: right, will try with minion running on the master and report back. My fear is that in order to test like to like i'll need to delete the minion cache in which case things might start to work again ?
22:15 iggy it was just to narrow things down really... you could just as easily spin up another master and then put the minion on it to test (so you don't mangle your current master)
22:19 forrest well, this is shit
22:19 forrest file /usr/lib64/python2.6/logging/__init__.py from install of python-libs-2.6.6-64.el6.x86_64 conflicts with file from package python-2.6.6-36.el6.x86_64
22:19 forrest On the latest stable when trying to provision in vagrant
22:20 sunkist joined #salt
22:22 forrest Has anyone else been seeing this conflict? It's on a centos 6.4 machine
22:22 DanyC iggy: yes, i'll do that. Thx for your time!! i'll report back tmw as now is very later. HAve a good day
22:22 iggy DanyC: good luck
22:23 iggy forrest: el6.4... upgrade maybe?
22:23 forrest iggy: Possibility, but that's what we need for our dev environment for production
22:23 forrest 6.4 isn't THAT old
22:23 iggy 2 years
22:24 iggy 6.7 just dropped last week iirc
22:24 baweaver joined #salt
22:24 Gabemo joined #salt
22:24 VR-Jack2 bandito: think I got it
22:24 forrest I don't disagree with you, but I don't think there should be major lib conflicts.
22:25 forrest same thing happens on 2015.5.3
22:25 forrest whut
22:25 bandito VR-Jack2: do tell!
22:26 bandito i'm really scratching my head here
22:26 iggy forrest: well, it's not a salt issue, so I don't think a different salt version will change it
22:26 VR-Jack2 bandito: give me a few more minutes. I'm gonna nail every possiblity, but I got it working
22:26 VR-Jack2 it's the E@
22:26 forrest iggy: I know, just confirming on two different releases.
22:26 iggy oh, rgr
22:26 forrest This image is the same as it has been and what was working a few weeks ago
22:26 forrest which leads me to believe the python packages are perhaps screwed?
22:27 iggy that's what I gathered
22:27 gcfhvjbkn joined #salt
22:29 iggy forrest: can you install anything else that uses python successfully?
22:29 iggy specifically anything that deps on python-libs?
22:29 forrest iggy: Not yet I haven't
22:31 forrest iggy: Trying to think of packages that require it off hand
22:31 forrest iggy: Can you recall any?
22:33 iggy I know what site I'd go look at on debian... does that count?
22:33 VR-Jack2 woohoo!
22:33 forrest iggy: sure
22:33 VR-Jack2 now if salt didn't take so long. *sigh*
22:33 forrest iggy: should be similar packages across the distros even if the naming convention is slightly different
22:34 iggy debian doesn't have a python-libs package :/
22:34 forrest iggy: bleh
22:34 Grokzen joined #salt
22:36 iggy what about ansible? (it's python isn't it?)
22:36 forrest iggy: I can duplicate it on a simple yum update of python-libs
22:37 iggy that definitely sounds like a centos problem then
22:37 Vynce joined #salt
22:38 iggy can you do a full upgrade to just 6.4 packages? (i.e. don't go to 6.5, etc.)
22:38 VR-Jack2 bandito: E@^(\.git($|/.*)|player($|/.*))   and have a nice day. :)
22:38 iggy sadly, I used RHEL for years at work and can't remember all the answers to these questions
22:38 VR-Jack2 That will exclude .git but allow .gitmore and exclude player but allow player2. It also matches all the files under those if they are directories.
22:39 sdm24 nice VR-Jack2
22:39 Vynce1 joined #salt
22:41 Vynce1 left #salt
22:41 bandito VR-Jack2: thanks I'll try that in a minute! i got pulled away
22:42 capricorn_1 joined #salt
22:42 druonysuse joined #salt
22:42 druonysuse joined #salt
22:43 VR-Jack2 bandito: no worries. it will work.
22:44 claytron_ joined #salt
22:44 VR-Jack2 the file list for recurse doesn't list a / at the end of a directory. It also appears to do an evil unlink, so it'll wipe out a directory and all files under it. So you not only have to match ^.git$ you also have to match ^.git/.*
22:45 VR-Jack2 Now someone else kindly write up a patch to the docs with a cool example. lol
22:45 aqua^c joined #salt
22:46 nitay joined #salt
22:47 PredatorVI Do I have to define a 'base:' environment in the pillar top.sls file even if I don't need any base pillar information?
22:47 VR-Jack2 don't believe so
22:48 breakingmatter joined #salt
22:48 PredatorVI This whole env thing seemed straight forward but I'm tripping all over myself.
22:49 VR-Jack2 that's why a lot of use don't use them
22:49 bandito VR-Jack2: it doesn't work :(
22:49 sdm24 its 80% obvious
22:49 otter768 joined #salt
22:49 VR-Jack2 bandito: did you run it twice? it worked on mine
22:49 bandito 3 times even
22:50 bandito hmmmmm
22:50 VR-Jack2 I'll gist my test
22:51 bandito ty
22:52 VR-Jack2 bandito: https://gist.github.com/vr-jack/1d984cf972d0701e06fb
22:52 VR-Jack2 fyi: I'm on 2015.5.3
22:54 bandito VR-Jack2: maybe it's a version thing, i'm on debian stable so 2014.1.13
22:54 bandito there is one more variable
22:55 bandito the salt sources on my end are actually symlinks
22:55 bandito to folders outside /srv/salt
22:56 ajw0100 joined #salt
22:56 VR-Jack2 hmmm. could cause an issue. try my testrecurse with a few sample files
22:56 VR-Jack2 may have to adjust for symlink.
22:58 gcfhvjbkn joined #salt
22:58 bandito ok
22:58 funzo joined #salt
22:58 VR-Jack2 testing on mine with symlinks right now
22:59 VR-Jack2 symlinks no issue with my version
22:59 VR-Jack2 possible issue with '/' interpretation. add a / in front of both $ and retry
23:00 VR-Jack2 E@^(\.git(/$|/.*)|player(/$|/.*))
23:00 VR-Jack2 that's possible if 2014.1 looks at directories different, or your os does
23:01 VR-Jack2 The /.* should catch it, but meh
23:02 VR-Jack2 if a 2014.1 bug, they won't let me fix it.
23:03 pm90_ joined #salt
23:04 bandito your test works!
23:05 bandito it works when i change it to be a symlink as well
23:05 bandito hmmmmm
23:06 pipps joined #salt
23:07 VR-Jack2 Did it report in results the files it removed on the first one?
23:08 VR-Jack2 like               removed:
23:08 VR-Jack2 - /test/recurse/player/testing2
23:08 bandito the first run of your test created both of them, no subsequent runs removed it
23:09 VR-Jack2 I meant on your production
23:09 bandito oh yes, on mine it always shows that its removing player first
23:09 VR-Jack2 can you past that one line?
23:09 bandito sure
23:10 bandito removed:                   - /var/www/foo.com/player
23:11 VR-Jack2 hmmmm. your - name: is still /var/www/foo.com/? and you pasted my E@ into the exclude_pat?
23:11 hasues left #salt
23:12 VR-Jack2 The second one would be E@^(\.git($|/.*)   btw
23:12 bandito E@^(\.git($|/.*)|player($|/.*))
23:13 bandito ahhhhhhhhhh
23:13 bandito ok
23:13 bandito if name ends with /, it fails
23:13 bandito otherwise, success
23:13 VR-Jack2 well, it should get it either way actually
23:14 PredatorVI If I just target a minon and run state.sls <mystate>, will salt automatically determine which environment data to load?
23:14 VR-Jack2 /var/www/foo.com/player, /var/www/foo.com/player/, and /var/www/food.com/player/.git all should match
23:14 bandito thats the only change i made because its the only diff i could see between yours and mind, and voila
23:15 VR-Jack2 so what did you change? to make sure I remember.
23:16 bandito - name: /var/www/foo.com/     to     - name: /var/www/foo.com
23:17 bandito thanks for the help! it has gotten me out of a pickle
23:17 VR-Jack2 hmm. mine ended with a / tool I'd copied yours from the paste. name with / and source without
23:17 bandito the manual one that i created to test yours (i was just using foo and bar and baz names in my directories) didnt have the /s
23:18 VR-Jack2 ahhh, so it's a bug in 2014.1 dealing with the '/' then
23:18 bandito i think so
23:18 VR-Jack2 good to know.
23:19 bandito thanks again, nowi need a smoke :P
23:21 VR-Jack2 ahh, updated my gist example to mention that.
23:23 Aidin joined #salt
23:25 bhosmer_ joined #salt
23:26 PredatorVI I have my 'base' and 'dev' file roots defined in my master config per VR-Jack2's recommendation but when I run the 'state.sls mystate saltenv=dev' it can't find the states located in 'base'.
23:27 PredatorVI if I eliminate the 'saltenv=dev', I get a stack trace that looks like an infinite recursion.
23:28 claytron_ joined #salt
23:28 VR-Jack2 do up a new gist with your master config sections for file and pillar roots and your top.sls in each
23:29 PredatorVI https://gist.github.com/PredatorVI/d8df4877a3b463f73c32
23:30 PredatorVI Also includes a file tree of all my states and pillars
23:32 VR-Jack2 looks good to me. That is the extent of my env knowledge.
23:33 PredatorVI Shoudl I even need the 'saltenv=dev' directive?  I would have expected salt to evalute the top.sls files and find the environment implicitly
23:33 |_[O_O]_| joined #salt
23:34 otter768 joined #salt
23:34 baweaver joined #salt
23:35 VR-Jack2 Not sure, sorry.
23:35 PredatorVI np, thanks for the help.
23:36 VR-Jack2 question, though. you don't appear to have a dbarmor/init.sls in base
23:37 VR-Jack2 shouldn't matter for a manual call, though
23:38 PredatorVI In that case I reference specific states and not the parent folder so I didn't create the init.sls
23:38 PredatorVI so when I call it I do dbarmor.dbarmor-processor
23:40 PredatorVI I think my top.sls is wrong but won't be the normal case.  I'll try changing it to see if that makes a difference.
23:40 VR-Jack2 normally the file top.sls is only needed for highstate, but an error might cause other issues. dunno
23:41 PredatorVI The current issue is when I do `salt 'rjv-test02*' state.sls dbarmor.dbarmor-processor saltenv=dev`, I get the error `No matching sls found for 'dbarmor.dbarmor-processor' in env 'dev'`.  It's like state.sls loads ONLY the dev environment and nothing else
23:41 PredatorVI Even though my master config has both file roots
23:42 VR-Jack2 restarted master after changing config?
23:42 PredatorVI hmm...I think so ... restarting again to be safe
23:43 nzero joined #salt
23:46 MatthewsFace joined #salt
23:46 Aidin left #salt
23:46 zer0def joined #salt
23:48 PredatorVI now I get the  RuntimeError: maximum recursion depth exceeded regardless...time to go home...:(
23:50 jeddi joined #salt
23:53 VR-Jack2 PredatorVI: if using includes and stuff you might be hitting a few bugs
23:56 nethershaw joined #salt
23:57 PredatorVI thanks...I'll sleep on it and see if that help :)
23:57 VR-Jack2 sleep? amateur. :P

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