Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-03-16

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

All times shown according to UTC.

Time Nick Message
00:00 jrgochan thanks for the help today! cya cya!
00:01 whytewolf have a good one
00:04 PatrolDoom joined #salt
00:06 dev_tea joined #salt
00:06 woodtablet left #salt
00:07 scsinutz joined #salt
00:10 brousch__ joined #salt
00:15 sikander joined #salt
00:16 jdipierro joined #salt
00:20 Rumbles joined #salt
00:20 desku joined #salt
00:23 giany left #salt
00:32 sikander joined #salt
00:49 pipps joined #salt
00:59 pipps joined #salt
01:04 dev_tea joined #salt
01:05 brakkisath joined #salt
01:10 brakkisath joined #salt
01:14 nZac joined #salt
01:15 ahrs_ joined #salt
01:23 Jimlad joined #salt
01:38 druonysus_ joined #salt
01:45 druonysus_ joined #salt
01:45 pipps joined #salt
01:45 druonysus_ joined #salt
01:46 jas02 joined #salt
01:47 onlyanegg joined #salt
01:47 Nahual joined #salt
01:52 scsinutz joined #salt
01:54 oaken_chris joined #salt
01:57 DEger joined #salt
01:58 antpa joined #salt
01:59 DEger joined #salt
02:04 ahrs joined #salt
02:15 Nahual1 joined #salt
02:25 antpa joined #salt
02:46 cowyn joined #salt
02:48 ilbot3 joined #salt
02:48 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.3.5, 2016.11.3 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ (please don't multiline paste into channel) <+> See also: #salt-devel, #salt-offtopic <+> Ask with patience as we are volunteers and may not have immediate answers
02:48 debian112 joined #salt
02:50 debian1121 joined #salt
02:55 debian112 joined #salt
02:58 zwhset joined #salt
02:59 zwhset hello
03:00 debian1121 joined #salt
03:01 djgerm joined #salt
03:01 shoemonkey joined #salt
03:04 ahrs joined #salt
03:05 evle joined #salt
03:06 debian112 joined #salt
03:17 debian112 joined #salt
03:17 pipps joined #salt
03:18 DEger joined #salt
03:22 debian112 joined #salt
03:24 debian1121 joined #salt
03:24 FredFoo joined #salt
03:27 debian112 joined #salt
03:33 scsinutz joined #salt
03:33 debian112 joined #salt
03:40 debian112 joined #salt
03:51 debian1121 joined #salt
03:59 oaken_chris joined #salt
04:00 jas02 joined #salt
04:01 Klaus_Dieter joined #salt
04:04 k_sze[work] joined #salt
04:08 debian112 joined #salt
04:18 djgerm joined #salt
04:26 fracklen joined #salt
04:27 debian112 joined #salt
04:29 PatrolDoom joined #salt
04:30 PatrolDoom joined #salt
04:30 debian112 joined #salt
04:31 scoates joined #salt
04:31 Klaus_D1eter_ joined #salt
04:32 pipps joined #salt
04:38 debian1121 joined #salt
04:46 scsinutz joined #salt
04:46 pipps joined #salt
04:46 debian112 joined #salt
04:48 Praematura joined #salt
04:49 debian112 joined #salt
04:50 antpa joined #salt
04:53 hillna joined #salt
04:54 DEger joined #salt
04:59 debian1121 joined #salt
05:02 scoates joined #salt
05:03 debian112 joined #salt
05:04 scoates joined #salt
05:06 jas02 joined #salt
05:12 debian1121 joined #salt
05:19 debian112 joined #salt
05:20 tercenya joined #salt
05:26 sh123124213 joined #salt
05:26 raininja joined #salt
05:27 debian1121 joined #salt
05:31 debian112 joined #salt
05:33 DEger joined #salt
05:33 debian112 joined #salt
05:34 onlyanegg joined #salt
05:36 debian1121 joined #salt
05:40 debian112 joined #salt
05:44 debian1121 joined #salt
05:54 impi joined #salt
05:54 debian112 joined #salt
06:01 debian112 joined #salt
06:06 debian112 joined #salt
06:10 debian112 joined #salt
06:13 debian112 joined #salt
06:15 ashmckenzie joined #salt
06:21 rdas joined #salt
06:24 k_sze[work] joined #salt
06:25 debian112 joined #salt
06:30 debian1121 joined #salt
06:32 onlyanegg joined #salt
06:36 pipps joined #salt
06:45 debian112 joined #salt
06:47 onlyanegg joined #salt
06:47 gnomethrower joined #salt
06:48 debian112 joined #salt
06:48 djgerm joined #salt
06:53 debian112 joined #salt
06:59 candyman88 joined #salt
06:59 sh123124213 joined #salt
07:02 Rumbles joined #salt
07:05 debian1121 joined #salt
07:07 scoates joined #salt
07:07 debian1122 joined #salt
07:09 debian112 joined #salt
07:10 jas02 joined #salt
07:13 debian112 joined #salt
07:14 felskrone joined #salt
07:14 Ricardo1000 joined #salt
07:18 sgo_ joined #salt
07:18 fracklen joined #salt
07:19 sh123124213 joined #salt
07:21 debian112 joined #salt
07:24 sh123124213 joined #salt
07:26 muxdaemon joined #salt
07:28 jas02 joined #salt
07:28 jhauser joined #salt
07:28 debian112 joined #salt
07:30 Ricardo1000 Hello wolrd
07:30 Ricardo1000 *world
07:31 debian112 joined #salt
07:32 wwalker joined #salt
07:33 Ricardo1000 Does any developers of salt present here ?
07:33 hemebond There are sometimes some core Salt developers around.
07:34 debian112 joined #salt
07:36 fracklen joined #salt
07:41 Rumbles joined #salt
07:41 Ricardo1000 Strategy decisions of salt development accepts one person(architector) or collegially ?
07:42 lionel joined #salt
07:42 debian1121 joined #salt
07:44 mpanetta joined #salt
07:46 mpanetta joined #salt
07:48 fracklen joined #salt
07:48 hemebond Uh.
07:48 debian112 joined #salt
07:48 hemebond Pass. No idea how strategy is discussed.
07:49 fracklen joined #salt
07:50 fracklen joined #salt
07:54 sh123124213 joined #salt
07:57 debian1121 joined #salt
08:00 Ricardo1000 hemebond: As I can see, here absent active discussions all the time, like on the other channels :)
08:00 o1e9 joined #salt
08:01 Ricardo1000 hemebond: It is good :)
08:01 hemebond Yeah, it's pretty quiet tonight (if that's what you're saying)
08:01 impi joined #salt
08:02 debian112 joined #salt
08:03 Ricardo1000 hemebond: Where are people mostly here from?
08:03 Ricardo1000 hemebond: US ?
08:03 hemebond Mostly? Probably mostly from the US.
08:05 debian112 joined #salt
08:08 scoates joined #salt
08:13 sh123124213 joined #salt
08:16 JohnnyRun joined #salt
08:18 babilen .oO( Just because Europeans are just getting up )
08:20 gnomethrower i'm from australia
08:21 rylnd 9am. getting coffee and then start the work day
08:21 Ricardo1000 gnomethrower: What time is it, in your location ?
08:23 debian1121 joined #salt
08:23 gnomethrower Ricardo1000: 4:23pm...
08:26 rylnd gnomethrower lives in the future. can you give me the lotto numbers? ;)
08:27 debian112 joined #salt
08:27 gnomethrower rylnd: 32 1 4 16 12 13 11
08:28 rylnd awesome! thanks. we split 50/50. we should do some sport bets too
08:28 debian1121 joined #salt
08:28 dariusjs joined #salt
08:29 sh123124213 joined #salt
08:30 debian1121 joined #salt
08:32 gnomethrower rylnd: bet on Thomason
08:32 gnomethrower and Free Rider
08:32 debian112 joined #salt
08:33 debian1121 joined #salt
08:35 netcho_ joined #salt
08:36 dariusjs joined #salt
08:38 debian112 joined #salt
08:38 jas02 joined #salt
08:41 chowmeined joined #salt
08:42 pipps joined #salt
08:44 debian112 joined #salt
08:49 debian1121 joined #salt
08:49 impi joined #salt
08:49 jhauser joined #salt
08:50 debian1121 joined #salt
08:53 jhauser_ joined #salt
09:01 debian112 joined #salt
09:02 Rumbles joined #salt
09:02 antpa joined #salt
09:02 hemebond Anyone else managed to automate their salt-minion upgrade? I see this error every time "salt-minion : Depends: salt-common (= 2016.3.5+ds-1) but 2016.11.3+ds-1 is to be installed"
09:03 AndreasLutro sounds like you have an apt problem
09:03 hemebond Yeah, but why? Manually installing works fine.
09:03 hemebond And salt-common is installing with the correct version (2016.3.5)
09:04 hemebond I get the error even after I remove the explicit salt-common install from the state.
09:04 hemebond Maybe I should just run the commands directly instead of using pkg.installed.
09:05 debian112 joined #salt
09:06 AndreasLutro wait are you trying to upgrade salt-common with salt?
09:06 AndreasLutro why not just upgrade salt-minion/salt-master?
09:06 hemebond Because it was failing.
09:06 hemebond So I added an explicit install of it to try and fix that. Didn't help.
09:07 hemebond Chances are my particular setup is breaking it somehow.
09:07 hemebond I have the packages held so I only get the version I explicitly set.
09:07 hemebond But even unholding first didn't help.
09:07 AndreasLutro right...
09:07 PhilA joined #salt
09:07 AndreasLutro holding packages just causes headaches in my experience, you can specify the version in the apt source file instead
09:08 AndreasLutro or do what we do, host our own salt-stable apt repo which mirrors whatever specific verison we know will work for us
09:08 hemebond Yeah but then when I do pkg.upgrade it breaks Salt :-)
09:08 hemebond This is my attempt to prevent me from breaking things.
09:08 AndreasLutro why would it?
09:08 hemebond Because it tries to upgrade to 2016.11
09:09 impi joined #salt
09:09 hemebond Which is broken for me (AWS/EC2 bugs)
09:09 AndreasLutro deb http://repo.saltstack.com/apt/debian/8/amd64/2016.3 jessie main
09:09 AndreasLutro or deb http://repo.saltstack.com/apt/debian/8/amd64/archive/2016.11.3 jessie main
09:09 AndreasLutro you can lock to whatever version you want without holding/pinning
09:10 scoates joined #salt
09:11 debian1121 joined #salt
09:11 hemebond I already have "deb http://repo.saltstack.com/apt/debian/8/amd64/2016.3 jessie main"
09:11 AndreasLutro then pkg.upgrade would never upgrade to 2016.11
09:12 hemebond "Get: 1 http://repo.saltstack.com/apt/debian/8/amd64/latest/ jessie/main salt-minion all 2016.11.3+ds-1 [26.6 kB"
09:13 hemebond Wait.
09:13 hemebond Found another file.
09:15 hemebond cloud_config_sources.list
09:16 hemebond Looks like cloud-init is adding its own source.
09:16 debian112 joined #salt
09:17 ronnix joined #salt
09:19 AndreasLutro yeah that's why we host our own stable salt repo, so we don't have to update cloud-init all the time
09:20 hemebond This gets added automatically when I use the cloud-init Saltstack automation I guess.
09:20 hemebond How are you initially installing salt-minion?
09:20 debian112 joined #salt
09:21 AndreasLutro add our salt apt repo, apt-get install... standard stuff
09:22 hemebond What platform?
09:22 hemebond or provider
09:23 AndreasLutro mutliple. doesn't really matter does it?
09:23 debian112 joined #salt
09:24 hemebond I struggled quite a bit with cloud-init to install salt.
09:24 hemebond Apart from this little issue it's now working well for me.
09:24 AndreasLutro yeah I don't like cloud-init very much
09:24 hemebond But I think I tried to do it "manually", rather than using the built-in salt install.
09:24 AndreasLutro I'd rather just use a plain shell script to have more control over steps
09:27 debian1121 joined #salt
09:27 hemebond I'm still fighting to set a hostname without rebooting to get it applied.
09:29 debian112 joined #salt
09:29 ronnix joined #salt
09:30 jhauser joined #salt
09:31 s_kunk joined #salt
09:32 debian112 joined #salt
09:32 nikdatrix joined #salt
09:34 nikdatrix Europe Up?
09:35 hemebond LOL,crap, my minions just upgraded to 2016.11
09:35 hemebond Lucky this is a test environment.
09:35 debian1121 joined #salt
09:37 hemebond Even after removing that file and refreshing.
09:38 antpa joined #salt
09:38 debian112 joined #salt
09:39 ravenx joined #salt
09:40 ravenx hi guys, there seems to be a problem with supervisord salt state not restarting my application
09:40 ravenx does anyone else have this problem?
09:40 jas02 joined #salt
09:41 debian112 joined #salt
09:41 babilen Which problem is that?
09:41 ravenx https://docs.saltstack.com/en/latest/ref/states/all/salt.states.supervisord.html
09:41 jhauser joined #salt
09:41 ravenx this state right here
09:42 babilen That's not a problem per se :)
09:42 ravenx i'm using the supervisord.running, and i have passed a restart: True
09:42 ravenx and it doesn't doesn't do that.
09:42 onlyanegg joined #salt
09:42 Jimlad joined #salt
09:42 ravenx of course, when i go into the box and do it manually,l it works
09:42 ravenx so i'm trying to figur eout why.
09:42 babilen hemebond: "apt-cache policy salt-minion" should tell you where it's from and "head -v -n -0 /etc/apt/sources.list{,.d/*}" shows all your sources
09:43 debian112 joined #salt
09:43 hemebond babilen: Yeah, I didn't know cloud-init was adding another source so worked around it by trying to hold packages.
09:43 gmoro joined #salt
09:43 babilen I thought you removed that file?
09:43 nikdatrix joined #salt
09:43 babilen (or rather: entry)
09:43 hemebond I thought I had but apparently it didn't apply to all minions.
09:43 hemebond So now I will manually remove the file and reinstall.
09:43 babilen Ah .. okay
09:44 Rumbles joined #salt
09:44 pipps joined #salt
09:45 Rumbles is it possible to have a top file /srv/salt/top.sls which has an include statement, so you could include the top files in /srv/salt/top.d (for example) I want to seperate out our top files so we have differnet files for different types of machines (servers in one laptops in another)?
09:46 babilen ravenx: Is the process in state RUNNONG or STARTING ?
09:46 netcho_ joined #salt
09:46 ravenx babilen: the process is in a running state
09:47 babilen So "supervisorctl status" gives RUNNING ?
09:49 ravenx absolutely
09:49 ravenx with an uptime that's quit elong
09:50 babilen What's the state debug output if you run it with salt-call ?
09:50 ravenx let's see:
09:50 ronnix joined #salt
09:51 debian1121 joined #salt
09:52 nikdatrix Rumbles: I dunno if you can have an include clause but you can include different evniroments and separate your top files
09:52 nikdatrix Rumbles: check https://salt.readthedocs.io/en/stable/ref/states/top.html
09:52 ravenx interesting
09:52 ravenx i'm getting this error:  https://paste.debian.net/920351/
09:53 antpa joined #salt
09:53 ravenx the .ini file..i don't remember supervisor needing one in the first place.
09:53 debian112 joined #salt
09:54 ravenx and even in my /etc/supervisor/supervisord.conf i have the [supervisorctl] section
09:54 Rumbles thanks nikdatrix
09:54 babilen So, just making sure: You ran "supervisorctl status" earlier and it is not giving you that error and shows the process as RUNNING ?
09:55 paant joined #salt
09:55 nikdatrix np
09:56 ravenx babilen: correct.  under the user which is allowed to run supervisorctl
09:56 ravenx supervisorctl status shows that it is RUNNING.
09:57 debian112 joined #salt
09:58 babilen ravenx: Does the same happen if you run "/usr/bin/supervisorctl -c /etc/supervisor/conf.d/connect-app.conf status" ? As which user are you running it and what happens if you run it as root?
09:58 ravenx babilen:  let me try it
09:58 babilen Ah, no .. run it as "the-user"
09:58 ravenx babilen:  i get the same error regarding the Error . ini file, if i run it as root
09:58 babilen With /home/the-user as pwd
09:59 ravenx now, running it as "the-user":
09:59 ravenx exact same message.
09:59 ravenx so both of these give the same message
10:00 babilen Could you paste your exact state?
10:00 debian1121 joined #salt
10:01 babilen My impression so far is that supervisorctl overrides the "normal" configuration file with "-c /etc/supervisor/conf.d/connect-app.conf" and that the latter doesn't contain the required [supervisorctl] section.
10:03 ravenx sure thing
10:03 ravenx i will post the exact one
10:03 ravenx babilen: give me on sec.
10:04 Praematura joined #salt
10:04 babilen Do you define "conf_file" ?
10:04 ravenx https://paste.debian.net/920352/
10:04 ravenx i sure did! :D
10:05 babilen You set it to /etc/supervisor/conf.d/connect-app.conf ?
10:05 ravenx correct
10:05 babilen And that configuration does, in fact, not contain a supervisorctl section?
10:05 igor_ joined #salt
10:06 debian112 joined #salt
10:06 ravenx that connect-app.confg does NOT contain a supervisorctl section
10:06 babilen There you go then :)
10:06 ravenx as i thought that the [suprevisorctl] section belongs in the /etc/supervisor/supervisord.conf
10:06 ravenx T_T what the heck since when was that needed in the per-app conf?!
10:06 babilen But you are telling supervisorctl not to use that file, but to use /etc/supervisor/conf.d/connect-app.conf
10:06 debian1122 joined #salt
10:07 ravenx hang on though, is the conf_file the one for the SUPERVISORD config
10:07 ravenx or the for the APP's config
10:07 babilen It's only needed if you configure supervisor to use a specific configuration file *only*
10:07 babilen I believe that it would work if you just remove the "conf_file" bit of your state
10:07 ravenx AAAAAAAAAAAAAH
10:07 ravenx lemme try
10:08 ravenx omfg
10:08 ravenx you're right
10:08 ravenx christ!
10:08 ravenx https://docs.saltstack.com/en/latest/ref/states/all/salt.states.supervisord.html
10:08 ravenx i think this doc, under conf_file, for the running state
10:08 babilen As that would allow supervisor to fall back to the default (i.e. /etc/supervisor/supervisord.conf + /etc/supervisor/conf.d/*) while you identify the process per "name: connect-app"
10:08 ravenx shoudl say "path to the supervisord config file"
10:08 debian112 joined #salt
10:09 igor_ hi all - has anyone used Salt to create aws route53 failover records? I could not find support for route53 failover, looks like it's not implemented
10:12 debian1121 joined #salt
10:13 ravenx babilen: thanks a million babilen
10:13 ravenx saltstack is nothing without you on irc
10:19 babilen You're welcome :)
10:22 oaken_chris joined #salt
10:24 debian112 joined #salt
10:26 teclator joined #salt
10:26 Deuns joined #salt
10:26 Deuns left #salt
10:28 debian112 joined #salt
10:30 catpig joined #salt
10:30 debian112 joined #salt
10:31 honestly I have a file.managed that says "The file ... is set to be changed" in test mode, but the "Changes" section is empty
10:31 jhauser joined #salt
10:31 honestly it can't really be ownership or permissions because it only happens on some files out of a group that all have the same permissions
10:32 honestly if it was whitespace changes, there'd still be a diff, it'd just look weird
10:32 honestly but there's no diff at all
10:32 debian112 joined #salt
10:34 DEger joined #salt
10:37 debian112 joined #salt
10:40 debian1121 joined #salt
10:43 debian112 joined #salt
10:46 pipps joined #salt
10:47 debian1121 joined #salt
10:52 debian112 joined #salt
10:56 sp0097 joined #salt
10:59 honestly huh, they're new file.
10:59 honestly files.
11:00 fracklen joined #salt
11:01 debian1121 joined #salt
11:02 Miouge joined #salt
11:04 debian112 joined #salt
11:07 debian1121 joined #salt
11:07 ronnix joined #salt
11:10 debian112 joined #salt
11:13 jhauser joined #salt
11:16 CeBe joined #salt
11:18 debian112 joined #salt
11:22 debian1121 joined #salt
11:24 jhauser joined #salt
11:29 sh123124213 joined #salt
11:32 jhauser joined #salt
11:38 debian112 joined #salt
11:41 sgo_ joined #salt
11:43 onlyanegg joined #salt
11:44 shambat joined #salt
11:47 pipps joined #salt
11:47 sh123124213 joined #salt
11:48 shambat I'm using the dockerng.running state to run my docker registry. I have set up the registries in pillar, but that makes the registry attempt to use itself as the source when downloading the registry images. Is there a way to specify which registry to use for its image?
11:51 debian112 joined #salt
11:51 _Cyclone_ joined #salt
11:53 debian112 joined #salt
11:55 Reverend joined #salt
11:59 sh123124213 joined #salt
12:10 antpa joined #salt
12:11 debian1121 joined #salt
12:12 s_kunk joined #salt
12:12 s_kunk joined #salt
12:15 Praematura joined #salt
12:17 debian112 joined #salt
12:19 shoemonkey joined #salt
12:23 debian1121 joined #salt
12:23 shoemonkey joined #salt
12:23 czeq joined #salt
12:25 debian1122 joined #salt
12:26 jhauser joined #salt
12:28 Rumbles joined #salt
12:30 debian112 joined #salt
12:36 evle1 joined #salt
12:37 debian112 joined #salt
12:40 s_kunk joined #salt
12:40 s_kunk joined #salt
12:41 debian112 joined #salt
12:43 debian112 joined #salt
12:44 sh123124213 joined #salt
12:47 dendazen joined #salt
12:49 pipps joined #salt
12:49 ssplatt joined #salt
12:50 scristian joined #salt
12:50 s_kunk joined #salt
12:50 s_kunk joined #salt
12:50 numkem joined #salt
12:51 antpa joined #salt
12:51 debian1121 joined #salt
12:53 jhauser joined #salt
12:56 sh123124213 joined #salt
13:01 sh123124213 joined #salt
13:03 ronnix joined #salt
13:04 debian112 joined #salt
13:04 sh123124213 joined #salt
13:05 debian112 joined #salt
13:07 candyman89 joined #salt
13:07 debian1121 joined #salt
13:07 jhauser joined #salt
13:08 WKNiGHT joined #salt
13:10 debian112 joined #salt
13:10 antpa joined #salt
13:12 debian1121 joined #salt
13:14 scoates joined #salt
13:16 paant joined #salt
13:17 gableroux joined #salt
13:17 shoemonkey joined #salt
13:17 s_kunk joined #salt
13:22 debian112 joined #salt
13:25 Tanta joined #salt
13:27 impi joined #salt
13:27 afics joined #salt
13:28 debian1121 joined #salt
13:28 nZac joined #salt
13:31 debian112 joined #salt
13:32 brousch__ joined #salt
13:32 jhauser joined #salt
13:35 catpig joined #salt
13:38 jhauser_ joined #salt
13:42 debian1121 joined #salt
13:43 jhauser joined #salt
13:43 onlyanegg joined #salt
13:47 cyborg-one joined #salt
13:48 swills joined #salt
13:50 candyman88 joined #salt
13:50 shambat how can I tell dockerng which repo to pull  an image from in the "running"-state?
13:52 debian112 joined #salt
13:54 oaken_chris joined #salt
13:54 XenophonF joined #salt
13:54 debian1121 joined #salt
13:55 manji shambat, you need a pillar key
13:55 manji that will end in -docker-registries
13:55 manji for instance:
13:56 jhauser joined #salt
13:57 debian112 joined #salt
13:57 manji shambat, https://gist.github.com/manjiki/7c6511a3f22c1801ca51cb86307f2b71
13:59 shambat manji: thank you. I already have a couple of those specified, which I think is the problem. I would like the salt-state that governs the machine that runs the actual docker repository to use a different repository, since it shouldn't pull from itself.
14:00 swills joined #salt
14:00 manji shambat, then you should add an "if" somewhere there
14:00 shambat can I then maybe set up an "dockerio-docker-registries" entry as well, and then somehow get dockerng for the repository-state to use that one?
14:00 manji so if the role of the machine is for instance 'docker_registry"
14:01 manji not to include that pillar data
14:01 shambat right, that makes sense
14:01 manji by default, iirc if something is not found in a local registry
14:01 manji the next step is docker.io
14:02 vegasq joined #salt
14:02 shambat manji: I will give that a shot. thanks!
14:03 debian112 joined #salt
14:04 onlyanegg joined #salt
14:05 manji cheers
14:06 jdipierro joined #salt
14:09 jhauser joined #salt
14:09 debian1121 joined #salt
14:12 debian112 joined #salt
14:14 jhauser_ joined #salt
14:17 debian1121 joined #salt
14:17 Praematura joined #salt
14:20 sh123124213 joined #salt
14:21 debian112 joined #salt
14:21 jdipierro joined #salt
14:23 jhauser joined #salt
14:26 debian1121 joined #salt
14:26 brakkisath joined #salt
14:26 shambat manji: so, that will perhaps work, but I want the solution to be a bit more smooth :) Right now it seems that if I specify my own repo, I will have to use that repo forever. It would be nice if the default repo was docker.io
14:27 manji shambat, you can always monkey patch dockerng  :p
14:30 tehsu is there a way to make a formula always run in batch? or anyone got a good quick workaround for the netapi losing batch
14:35 fracklen joined #salt
14:37 debian112 joined #salt
14:40 debian112 joined #salt
14:41 fracklen joined #salt
14:50 pipps joined #salt
14:53 guanophobic joined #salt
14:55 debian1121 joined #salt
14:56 debian112 joined #salt
14:56 keltim joined #salt
14:57 oeuftete joined #salt
14:57 jauz Is there a way to have the Salt Minion register it's %PATH% under a user setting as well as the system environment variable during installation?
14:57 jauz (Windows)
14:59 debian1121 joined #salt
15:00 guanophobic joined #salt
15:03 PhilA joined #salt
15:03 sarcasticadmin joined #salt
15:08 Praematura joined #salt
15:11 debian112 joined #salt
15:12 mpanetta joined #salt
15:12 debian112 joined #salt
15:13 jhauser joined #salt
15:14 jhauser_ joined #salt
15:14 sh123124213 joined #salt
15:20 debian1121 joined #salt
15:22 ronnix joined #salt
15:23 debian112 joined #salt
15:26 jdipierro joined #salt
15:35 debian1121 joined #salt
15:38 tiwula joined #salt
15:39 debian112 joined #salt
15:40 Karunamon Possibly dumb question - can you write an SLS file to trigger salt.cloud states?
15:41 Karunamon having trouble finding a syntax example
15:42 ssplatt i’d guess an orchestration can do that
15:42 debian112 joined #salt
15:43 ssplatt thinking of autoscaling. haven’t tried it myself.
15:43 Karunamon in my case to effect an environment-wide upgrade.. a lot easier than dinking around in the VMWare UI
15:44 debian112 joined #salt
15:45 Karunamon i'd imagine that you'd be able to salt-call or salt-run it though, and that's just giving me not available messages
15:45 Karunamon (since salt-cloud the program uses different syntax)
15:46 ssplatt https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.cloud.html
15:46 ssplatt so yeah, you can use that in ractors and orchestrations
15:46 ssplatt reactors.
15:46 Karunamon yes! that is exactly what I needed.
15:47 debian1121 joined #salt
15:48 ssplatt https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cloud.html#module-salt.modules.cloud
15:49 debian112 joined #salt
15:51 Vaelatern Hm, how do I tell a minion that the master has changed and to trust the new one?
15:51 debian112 joined #salt
15:52 ping0ra joined #salt
15:52 ssplatt you’d have to delete the old key in /etc/salt/pki
15:52 ssplatt and have it reattach to the new one
15:53 debian1121 joined #salt
15:55 ping0ra I am curious if anyone is using git lfs with their saltstack git repo? I am just wondering about how to manage large egg style assets that needs to be fetched by minions. Or ... at least looking to improve upon our implementation
15:56 debian112 joined #salt
15:59 ping0ra joined #salt
16:02 fracklen joined #salt
16:03 pipps99 joined #salt
16:03 debian112 joined #salt
16:04 Karunamon kind of easy to get lost in the docs :)
16:06 debian1121 joined #salt
16:07 Karunamon so if the docs show 'salt.modules.cloud.action', inside an SLS to stop a VM, i'd have cloud.action -name 'stop' ?
16:07 scsinutz joined #salt
16:07 Karunamon (the translation between command line syntax and SLS syntax has always been a bit unclear to me)
16:14 debian112 joined #salt
16:15 whiteinge the distinction is the CLI calls execution modules (which are just called "modules" in the index), and SLS files call state modules.
16:15 woodtablet joined #salt
16:16 BadgerOps joined #salt
16:16 debian112 joined #salt
16:16 Karunamon nono, i mean the actual syntax used
16:17 debian1121 joined #salt
16:19 Karunamon you can do file.managed from the cli just as easily as from within an SLS, but the invocation is different :)
16:19 rem5_ joined #salt
16:20 whiteinge that's a common stumbling point. those are two separate functions that happen to have the same name.
16:20 BadgerOps hey all, I've got a salt-cloud -S (select query) question, not sure how to use it, not a lot of information in the docs/code. Anyone have experience with it?
16:20 whiteinge one is an execution function (CLI) and one is a state function (SLS)
16:21 whiteinge Karunamon: you can't call execution functions from SLS files directly. BUT there is a state function that can call execution functions: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.module.html#salt.states.module.run
16:21 whiteinge whenever you're reading the docs, be sure to pay careful attention what what kind of module it is because that dictates where and how you can call it.
16:22 babilen And state modules are typically built "on top of" execution modules and simply add the logic as to what actually needs to be done
16:23 PatrolDoom joined #salt
16:24 pipps joined #salt
16:26 scoates joined #salt
16:29 Karunamon good info - thanks
16:29 onlyanegg joined #salt
16:31 scsinutz joined #salt
16:31 debian112 joined #salt
16:31 oaken_chris joined #salt
16:32 DEger joined #salt
16:32 brakkisa_ joined #salt
16:36 snc joined #salt
16:37 scsinutz joined #salt
16:38 scsinutz joined #salt
16:38 antpa joined #salt
16:38 debian112 joined #salt
16:39 ronnix joined #salt
16:41 debian1121 joined #salt
16:43 ssplatt joined #salt
16:45 debian112 joined #salt
16:47 DEger joined #salt
16:47 netcho_ joined #salt
16:51 paant joined #salt
16:53 debian112 joined #salt
16:56 netcho_ joined #salt
17:01 gableroux joined #salt
17:01 scsinutz joined #salt
17:02 scoates joined #salt
17:02 q1x hello! Is there a way to use pillar data recursively? I have some parameters in Foreman (ext_pillar) that I would like to use to override settings in some formulas.
17:03 debian1121 joined #salt
17:04 Karunamon whiteinge: if you're still around, having trouble getting the syntax right for module.run - example sls here https://gist.github.com/Karunamon/2d02fe7c1c0596c5e400d12af64403e4
17:04 Karunamon getting a "action() got multiple values for keyword argument 'instance'"
17:04 DEger joined #salt
17:06 debian112 joined #salt
17:07 guanophobic joined #salt
17:07 muxdaemon joined #salt
17:08 guanophobic left #salt
17:09 eldad joined #salt
17:10 eldad Hi all :) can I use the grains system from the master with Salt's python api?
17:11 eldad I have some python code that using the *Client api and I would like to add/remove grains that my high state will later use
17:11 debian112 joined #salt
17:12 impi joined #salt
17:13 Edgan joined #salt
17:13 debian112 joined #salt
17:14 whiteinge Karunamon: commented
17:16 whiteinge eldad: the easiest way is to use LocalClient to call the grains module to set values as normal.
17:16 whiteinge oh, or are you asking about setting grains on the master?
17:16 eldad yes
17:16 eldad LocalClient will only allow me to set grains for minion
17:16 DEger joined #salt
17:17 whiteinge ah, to set grains on the master i'd recommend the same thing except use the Caller class with `file_client: local` in its opts dict.
17:17 debian112 joined #salt
17:17 whiteinge there's an example for that in the Caller docstring.
17:18 eldad Ok, I'll try that , thanks!
17:20 debian1121 joined #salt
17:21 Karunamon whiteinge: that gives me an "invalid action", almost as if it's interpreting the instance name as the action to execute.. added to the gist.
17:22 debian112 joined #salt
17:24 Whissi Mh, in states I can have "include:\n  - .foo" to include foo.sls in the same dir. Doing the same in Pillar doesn't work.
17:25 whytewolf Karunamon: commented on your gist
17:25 debian1121 joined #salt
17:27 ssplatt joined #salt
17:28 debian1122 joined #salt
17:29 pipps joined #salt
17:31 debian112 joined #salt
17:32 Karunamon whytewolf, whiteinge: replied again - that didn't work either
17:33 debian1121 joined #salt
17:34 whiteinge looks like salt-cloud is complaining about the vm name and not the action.
17:35 Karunamon you'd think that, but using the runner from the command line, it executes fine
17:35 Karunamon salt-run cloud.action stop instance=somevm - and in any case, there's a different error, not "invalid action" if you give it a bogus vm name
17:37 whytewolf instead of using the runner try the module. [since that is what you are trying to use with module.run
17:37 whytewolf ]
17:37 whiteinge salt-run executes on the master. are you calling that execution module on a minion? if so, the minion won't have access to your salt-cloud config files.
17:38 Karunamon everything so far has been executed on the master
17:38 whytewolf so you are targetting the master?
17:38 Karunamon i'm invoking the sls file with salt-call --local state.sls (filename)
17:38 Karunamon ...which is a minion command
17:38 Karunamon hm
17:40 numkem joined #salt
17:41 whiteinge you can run that on a master. i'm not sure how salt-cloud reads in its config files (without code-diving)
17:41 Karunamon right, i mean salt-call is executing in a minion context, where 'salt' executes in a master context
17:42 Karunamon i only have the provider profile for salt-cloud, and I think it's being pulled correctly since the error i'm getting references vmware
17:42 Karunamon *one provider profile
17:42 whytewolf again have you tried just running the module.
17:43 debian112 joined #salt
17:43 Karunamon as in salt 'masterhost' state.run etc? No, because I have a git backend and would need to commit every single test..
17:44 swills joined #salt
17:45 whytewolf no as in salt-call cloud.action fun=start instances=somevm
17:45 lclemens joined #salt
17:45 debian112 joined #salt
17:46 whytewolf since this is what your module.run state is trying to do. might be best to actionly find out what is going on
17:47 whiteinge ^^ good suggestion. i looked at the code for the runner and the execution module and they read the config in the same way so i would expect salt-call --local to work here.
17:47 Karunamon trying that now..
17:47 lclemens joined #salt
17:47 ronnix joined #salt
17:48 whytewolf also, is this minion on the master?
17:48 Karunamon yes
17:48 Karunamon "Passed invalid arguments: start() got multiple values for keyword argument 'call'." ..
17:49 Karunamon salt-call cloud.action fun=start instance=somevm
17:50 whytewolf add an -l debug between salt-call and cloud.action
17:50 eldad joined #salt
17:51 Trauma joined #salt
17:52 DEger joined #salt
17:52 Karunamon looks like it checked  the name I gave it against every single profile in cloud.profiles.d before bailing out
17:53 Karunamon [DEBUG   ] vm:some-other-vm in provider:vmware is not in name list:'set(['somevm'])'
17:54 whytewolf do you have a vm with the name somevm?
17:54 debian1121 joined #salt
17:54 Karunamon yes. again, this works when used with the runner
17:55 Karunamon salt-run cloud.action stop instance=somevm. => works
17:55 Karunamon salt-call cloud.action fun=stop instance=somevm => doesn't
17:56 debian1122 joined #salt
17:57 whiteinge since you're doing this all via the master anyway it may just be better to call the runner from an sls file. that way it'll match what you're doing on the cli
17:57 whytewolf in that case I would say open a bug report against cloud.action module. and use saltutil.runner [which will only work on the master]
17:58 debian112 joined #salt
17:59 nixjdm joined #salt
17:59 Karunamon darn. Alright. What's the right syntax inside an sls file to call a runner?
17:59 Karunamon rather than an sls module
18:00 whytewolf humm sorry not saltutil.runner. that is exacution module. salt.runner should work
18:00 whytewolf works pretty much exactly like module.run
18:05 scsinutz joined #salt
18:06 Karunamon that worked - thanks
18:06 ahrs joined #salt
18:07 Karunamon so something's borked in the state module that isn't in the runner.. this is a new one on  me
18:07 Karunamon but for now, to github :D
18:07 whytewolf exacution module not state module
18:07 whytewolf :P
18:07 Karunamon blah. it's hard to keep this straight.
18:08 whytewolf if it is cli it is exacution module. if it is sls without needing module.run it is state module
18:08 debian112 joined #salt
18:10 debian112 joined #salt
18:14 debian112 joined #salt
18:19 dRiN joined #salt
18:21 debian1121 joined #salt
18:25 s_kunk joined #salt
18:28 debian112 joined #salt
18:30 pipps joined #salt
18:30 Yoda left #salt
18:32 catpig joined #salt
18:35 debian1121 joined #salt
18:35 brakkisath joined #salt
18:36 debian112 joined #salt
18:37 debian1121 joined #salt
18:39 chowmein__ joined #salt
18:40 brakkisath joined #salt
18:42 pipps joined #salt
18:43 ronnix joined #salt
18:44 fracklen joined #salt
18:45 DammitJim joined #salt
18:46 debian112 joined #salt
18:48 sh123124213 joined #salt
18:49 debian112 joined #salt
18:49 djgerm joined #salt
18:53 sh123124213 joined #salt
18:53 IdoKaplan joined #salt
18:54 debian1121 joined #salt
18:56 IdoKaplan Hi, I need help with Jinja please. How can I config "set" with multiple grains? for example {% set configpath = grains.env|capitalize grains.id|upper %}
18:58 whiteinge ~ is the string concat operator in jinja
18:59 PhilA joined #salt
19:00 IdoKaplan whiteinge: thanks. can you please give me an example how I should write this "set"?
19:00 scsinutz joined #salt
19:01 ssplatt IdoKaplan: http://jinja.pocoo.org/docs/2.9/templates/#other-operators
19:02 IdoKaplan thank you  all!
19:04 prg3 joined #salt
19:07 debian112 joined #salt
19:10 cyborg-one joined #salt
19:11 debian1121 joined #salt
19:14 DEger joined #salt
19:17 debian112 joined #salt
19:18 pipps joined #salt
19:19 debian112 joined #salt
19:23 antpa joined #salt
19:28 aldevar joined #salt
19:29 pipps joined #salt
19:30 debian112 joined #salt
19:31 sjorge joined #salt
19:31 sjorge joined #salt
19:31 sh123124_ joined #salt
19:32 ChubYann joined #salt
19:35 paant joined #salt
19:36 debian112 joined #salt
19:37 impi joined #salt
19:41 Renich joined #salt
19:42 debian112 joined #salt
19:42 sjorge joined #salt
19:42 sjorge joined #salt
19:43 DammitJim how do I know what minions I have assigned to get a state?
19:44 DammitJim my top file is huge!
19:44 DammitJim (I know it shouldn't be)
19:44 DammitJim but there are states that require other states and so on...
19:45 cscf DammitJim, if state A requires state B, have it include: - stateB and - require: sls: stateB , rather than putting it all in top.sls
19:46 mpanetta joined #salt
19:46 DammitJim I know
19:46 DammitJim but there is no command in salt that will say.... ok, for this state, all these minions are going to get it
19:46 mpanetta joined #salt
19:47 whytewolf state.show_highstate will show you what states will run on a minion
19:47 DammitJim right, I want the opposite LOL
19:48 debian112 joined #salt
19:48 Renich joined #salt
19:48 q1x Hi all, if I look at this jinja template in the zabbix formula https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/files/default/etc/zabbix/zabbix_agentd.conf.jinja
19:49 q1x I'm having a bit of a hard time figuring out these lines:
19:49 q1x {% if settings.get('logfile', false) %}LogFile={{ settings.get('logfile', '/var/log/zabbix/zabbix_agentd.log') }}{% endif %}
19:49 q1x the way I'm reading it, is if the logfile variable is set it will print the line, otherwise it won't print that line
19:50 debian112 joined #salt
19:50 cscf DammitJim, salt '*' state.highstate | grep state ? lol
19:50 whytewolf q1x: you are reading that correctly.
19:50 whytewolf not sure that needs the if statement
19:51 q1x and, the line will be populated with the variable hold in logfile or, if it is empty, it should set the file to /var/log/zabbix/zabbix_agentd.log
19:51 whytewolf because the default of '/var/log/zabbix/zabbix_agentd.log' will never been used
19:51 q1x whytewolf: right, that was what was causing my confusion
19:52 q1x whytewolf: the only way I could see it being used, is if logfile would be set to True, right?
19:52 whytewolf q1x: well no cause then Logfile=True
19:52 debian112 joined #salt
19:52 q1x there is no concept of boolean vs string at work here?
19:53 whytewolf no, .get just gets the varible, what ever it is
19:53 q1x well, that's...weird
19:53 whytewolf the default is used if it isn't set
19:55 cscf Getting a strange cache error from archive.extracted: https://gist.github.com/lordcirth/9caa75e1f1fc89bc1e000a1ae0fd5cdc
19:55 q1x whytewolf: what could be the reason to include /var/log/zabbix/zabbix_agentd.log in that line then?
19:56 whytewolf q1x: because the formula designer wasn't thinking?
19:56 q1x in that case probably overthinking :)
19:56 cscf It repeatedly tries to load the tarball from cache even though it's not there.  Why doesn't it download it?  Worked on another box
19:57 whytewolf or the default was there before they put in the if statment
19:57 q1x whytewolf: hmm, it could indeed be a historic reason
19:59 whytewolf cscf: that is an ... interesting file name you got there :P i have no idea why it isn't downloading though... time to add a -l debug into your workflow to see what is happening
19:59 cscf whytewolf, well the filename is netboot.tar.gz
20:00 cscf But - source: 'http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/netboot.tar.gz'
20:01 ckonstanski joined #salt
20:02 Vaelatern joined #salt
20:02 mavhq joined #salt
20:03 pipps joined #salt
20:04 Inveracity joined #salt
20:05 cscf whytewolf, got some debug info: https://gist.github.com/lordcirth/9caa75e1f1fc89bc1e000a1ae0fd5cdc
20:05 amcorreia joined #salt
20:06 armyriad joined #salt
20:06 cscf It seems like a checksum error, but I'm not using checksums
20:08 whytewolf that is correct. it is trying to compare the hash and unable to find the hash. what version of salt?
20:08 debian1121 joined #salt
20:09 whytewolf havn't seen that error in a while.
20:10 ckonstanski I have a need to create a value and store it in a variable exactly once per state run. (It's a randomly generated password.) Every jinja template in my project needs to see the same value. My current attempt is not working. I created a custom module in which I generate the value and store it in a variable. I thought that the module would only be loaded once, therefore it would keep the same value throughout the run. But it's not
20:10 ckonstanski working. Is there another way?
20:10 whytewolf ckonstanski: that seems like a usecase fo sdb
20:10 ckonstanski Let me look that up.
20:11 whytewolf s/usecase fo/use case for
20:11 whytewolf https://docs.saltstack.com/en/latest/topics/sdb/
20:12 Renich joined #salt
20:12 debian112 joined #salt
20:12 raspado joined #salt
20:12 whytewolf cscf: here is a issue that lists the same error. but it is for 0.17.4 https://github.com/saltstack/salt/issues/8653
20:12 saltstackbot [#8653][MERGED] random traceback with file.managed: KeyError: 'hsum' | ```...
20:12 muxdaemon joined #salt
20:12 whytewolf check the version on your minion.
20:13 netcho_ joined #salt
20:13 cscf whytewolf, odd. I have hash_type: sha256 on both sides, and I've already checked, all are Carbon
20:14 Vaelatern joined #salt
20:14 debian112 joined #salt
20:15 cscf whytewolf, should I re-open the issue?
20:15 whytewolf I would open a new one.
20:15 cscf Theirs is non-deterministic, mine always happens on this minion
20:16 whytewolf yeah. plus there has been enough releases between then and now, that it would be difficult to tie them together
20:16 Renich_ joined #salt
20:19 Renich__ joined #salt
20:19 netcho_ joined #salt
20:20 debian1121 joined #salt
20:20 scsinutz joined #salt
20:21 debian112 joined #salt
20:26 cscf whytewolf, https://github.com/saltstack/salt/issues/40092
20:26 saltstackbot [#40092][OPEN] archive.extracted failing with traceback in file.managed | Description of Issue/Question...
20:26 cscf Am I missing anything?
20:26 debian1121 joined #salt
20:27 whytewolf nope, looks good. they may ask for more info. but i think you pretty much have everything to at least let them know what is happening
20:27 sp0097 joined #salt
20:29 debian1122 joined #salt
20:29 cscf I don't know why it works with one minion and not another
20:30 hemebond Not just a bad install?
20:30 hemebond (I haven't followed any of this discussion, btw)
20:31 cscf hemebond, bad install in what sense? corrupt salt minion pkg?
20:31 hemebond Don't know, but I'd just try reinstalling.
20:31 hemebond If it's only a problem on a single minion,
20:31 hemebond But as I say I haven't followed any of the discussion.
20:31 debian112 joined #salt
20:31 * whytewolf shrugs. couldn't hurt. might also check salt 'minion' test.versions matches salt-minion --versions
20:34 debian112 joined #salt
20:35 pipps joined #salt
20:42 vindy joined #salt
20:43 NEOhidra joined #salt
20:44 vindy hey all.  Newish user here
20:44 debian1121 joined #salt
20:45 vindy Is there any common trick to deal with flakey cache problems on file.managed?   Pointing at an S3 resource that was removed and can't see a clean way to tell salt to ignore it.
20:45 vindy ah, but also: The target file was updated to a new file that IS present.
20:48 debian112 joined #salt
20:48 cscf hemebond, debsums is all fine
20:49 hemebond Is that the same as a purge and reinstall?
20:49 cscf hemebond, it checksums all files to see if they are corrupt
20:49 hemebond Sure.
20:50 debian1121 joined #salt
20:52 debian1121 joined #salt
20:55 debian112 joined #salt
20:55 cscf purged and reinstalled, same
20:56 fracklen joined #salt
20:58 debian112 joined #salt
21:02 MTecknology this salt stack is stacked so poorly that I'm taking random guesses at entry points and hoping the right states get generated...
21:02 hemebond D-:
21:03 whytewolf wow. :(
21:03 debian112 joined #salt
21:04 djgerm joined #salt
21:12 nixjdm joined #salt
21:15 debian1121 joined #salt
21:17 vegasq_ joined #salt
21:19 MTecknology There were about 11 .{sls,jinja} files involved in understanding the typical user states. Turns out, the user I need to modify isn't being created from any of that, but it's also not in the other state..
21:19 debian112 joined #salt
21:21 scsinutz joined #salt
21:22 relidy joined #salt
21:22 debian1121 joined #salt
21:23 vindy Anyone have ideas?  http://imgur.com/a/IOSM6
21:24 sh123124213 joined #salt
21:25 ckonstanski left #salt
21:25 sh123124213 joined #salt
21:25 muxdaemon joined #salt
21:25 ckonstanski joined #salt
21:27 debian112 joined #salt
21:28 hemebond vindy: Where is your state?
21:28 hemebond Have you pasted the state somewhere?
21:28 hemebond Not sure about your S3 issue. I don't really understand your problem there. I've never had problems with the cache.
21:28 vindy sorry, one moment and I will
21:30 vindy Figured out the problem with the service start.  PEBKAC.  I was referencing a variable for the service that wasn't the actual service name on the box.
21:30 vindy The self-referential thing was confusing
21:31 vindy I've seen a few weird behaviors with the S3 bit
21:31 vindy Seems you're forced to use a source_hash with S3.
21:31 debian1121 joined #salt
21:31 vindy setting verify to false just throws weird errors
21:32 Laladila joined #salt
21:33 hemebond Yeah you have to use source_hash with any source that isn't salt://
21:33 hemebond If you don't care about security then just use s3.get to fetch the file.
21:33 hemebond But that will happen every time.
21:34 vindy No middle ground?
21:35 debian112 joined #salt
21:35 hemebond What would be the middle ground?
21:35 vindy off the cuff?
21:35 Laladila joined #salt
21:35 vindy I'd guess with verify false the behavior would be cache the hash and only update when that changes but not refuse to update because of it
21:36 candyman89 joined #salt
21:37 debian112 joined #salt
21:37 mfilotto joined #salt
21:37 mfilotto Hello
21:37 mfilotto Here is my question
21:37 hemebond vindy: Then you still need to fetch the file to check the hash.
21:37 hemebond s3.get to a local file then file.managed
21:38 hemebond That's how people get around it.
21:38 hemebond They wget the file and then file.managed.
21:38 debian112 joined #salt
21:39 mfilotto I have a cmd.run state creating files on my minion, then a for jinja loop doing a salt['file.find'], how can I be sure to trigger the find once the cmd.run is finished ?
21:41 whytewolf mfilotto: you can't.
21:41 mfilotto arf
21:42 whytewolf order of operations. jinja rendering, state ordering, state exacution
21:42 vindy That should work pretty well, thanks for the tip. :)
21:42 vindy Though I guess it still pulls the file every time
21:43 debian112 joined #salt
21:43 mfilotto @whytewolf: it makes sense
21:44 whytewolf mfilotto: however. if your triggering is doing something to the states you could use unless and onlyif or a state with file.exists as a require
21:44 vindy hemebond: gotta run but thanks for the assist.  I'll play with it.
21:44 mfilotto So the only way would be to transform my jinja code into python function ?
21:44 debian1121 joined #salt
21:45 whytewolf unless and onlyif use shell commands and check for retcode
21:46 whytewolf https://docs.saltstack.com/en/latest/ref/states/requisites.html#unless https://docs.saltstack.com/en/latest/ref/states/requisites.html#onlyif or https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.exists
21:48 debian112 joined #salt
21:49 debian1121 joined #salt
21:52 Drunken_Panda joined #salt
21:52 Flying_Panda joined #salt
21:52 Flying_Panda Hi Guys quick question im trying to set a config for a runner however the salt master dont seem to like the config for this runner here https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html
21:52 mfilotto @whytewolf: the cmd.run creates files I want to move somewhere else with a for loop, so I'm not sur onlyif, unless, or file.exists are usefull
21:53 Flying_Panda im right in thinking I can pop these in /etc/salt/master.d/loadbalancer.conf ?
21:53 mfilotto @whytewolf I'm afraid I reached limits of jinja code
21:53 debian112 joined #salt
21:53 hemebond Flying_Panda: Yes
21:54 cingeyedog joined #salt
21:55 whytewolf mfilotto: what exactly are you doing? I might be able to parse it out into a split between jinja and states that works
21:56 debian1121 joined #salt
21:57 mfilotto @whytewolf: My use case is to take a docker-compose file, generate units systemd from it then deploy and start these services on the minion
21:59 whytewolf what does your file.find currently look like?
22:02 mfilotto @whytewolf: here is my sls : https://gist.github.com/mfilotto/2a27ae15c08625193da89434c57b21c1
22:03 pipps joined #salt
22:04 etnbrd joined #salt
22:06 whytewolf okay, you are right that you can't just split that into jinja and states. however you CAN split that into an orchestration ... everything before {% for service_path in salt['file.find'](['/srv/', service_group_name, '-deploy/']|join, name=['*', service_suffix]|join) %} being one state file. then everything after being another.
22:07 whytewolf this will split up the jinja rendering
22:07 hemebond Ah, Docker.
22:07 * whytewolf has never been a fan of Docker
22:08 amcorreia joined #salt
22:10 debian112 joined #salt
22:11 mfilotto @whytewolf: yes that would work
22:13 whytewolf Grrr, this new laptops keyboard throws me off
22:13 mfilotto @whytewolf: Thanks ;)
22:13 whytewolf mfilotto: no problem thats why I'm here ;)
22:13 scoates joined #salt
22:14 whytewolf now to see how i want to design my laptops salt intergration
22:15 debian1121 joined #salt
22:15 Tanta joined #salt
22:16 debian1122 joined #salt
22:18 ahrs joined #salt
22:20 debian112 joined #salt
22:20 whytewolf humm. this is kind of annoying "Masterless orchestration supports only the salt.state command in an sls file; it does not (currently) support the salt.function command."
22:21 hemebond >:-( is there a problem with schedule in 2016.3.5? It doesn't seem to be removing schedule tasks when using pillars.
22:24 hemebond Argh, it is broken.
22:28 ckonstanski Is there a PPA for a newer version of salt for ubuntu xenial?
22:28 ckonstanski root@docker-build-slave:~# cat /etc/issue
22:28 ckonstanski Ubuntu 16.04.2 LTS \n \l
22:28 ckonstanski root@docker-build-slave:~# salt --version
22:28 ckonstanski salt 2015.8.8 (Beryllium)
22:28 ckonstanski
22:28 hemebond ckonstanski: Use the official saltstack repos
22:29 aldevar left #salt
22:30 debian112 joined #salt
22:31 ckonstanski Manually managed packages == boo, but OK
22:31 hemebond What>
22:31 hemebond ?
22:31 hemebond Manually managed?
22:31 ckonstanski https://repo.saltstack.com/index.html
22:31 ckonstanski Looks pretty manual to me
22:31 ckonstanski Is this not the right directions?
22:32 hemebond Oh you mean manually adding the repo?
22:32 hemebond That's not manually managing packages.
22:32 ckonstanski I would like to be able to use apt if at all possible. Manually adding a source is fine, but manually installing salt is not.
22:32 hemebond All a PPA does is accept the key for you.
22:32 hemebond It is apt.
22:33 debian1121 joined #salt
22:33 ckonstanski https://repo.saltstack.com/#ubuntu
22:33 ckonstanski ah here we go
22:34 hemebond Oh you hadn't clicked on Ubuntu?
22:36 debian112 joined #salt
22:37 pipps joined #salt
22:38 whytewolf also, the bootstrap script on the front page. does install the repos and keys. and unless you tell it not to pretty much everything is done through the "package manager of $os"
22:38 hemebond That's true.
22:38 ckonstanski good to know
22:39 debian1121 joined #salt
22:41 ckonstanski root@docker-build-slave:/srv# salt --version
22:41 ckonstanski salt 2016.11.3 (Carbon)
22:41 ckonstanski
22:41 ckonstanski good to go. Thanks!
22:44 jdipierro joined #salt
22:47 hemebond Is there a way to use Salt minion targeting rules/functions in Jinja?
22:47 whytewolf yes
22:48 whytewolf https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.match.html
22:48 hemebond Oh beautiful. Thanks whytewolf
22:51 whytewolf Grrr, who the hell thought unity was a good idea?
22:51 hemebond Unity? The desktop manager or the game SDK?
22:51 whytewolf the desktop manager
22:52 ckonstanski It makes a nice spyware platform for Canonical.
22:52 hemebond I do dislike the recent move toward having the window decorations as part of the applications, rather than the window/desktop manager.
22:53 hemebond Now, just like Windows users, we too can have immovable windows when the application hangs.
22:55 djgerm hello! does anybody have a working example of setting a cookie name for AppCookieStickinessPolicyType with https://docs.saltstack.com/en/latest/ref/states/all/salt.states.boto_elb.html
22:59 mavhq joined #salt
22:59 debian112 joined #salt
23:00 pipps joined #salt
23:02 debian1121 joined #salt
23:02 cyteen joined #salt
23:03 whytewolf djgerm: wouldn't your policy section be something like this https://gist.github.com/whytewolf/e2a3f72c8b0d2990f8ab0baeb5eafb10
23:03 whytewolf [with of coarse your other pocies]
23:03 djgerm maybe ^_^ that's what I was looking for! I'll test that!
23:05 whytewolf just took reading two docs and combining the info . https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb-policy.html & https://docs.saltstack.com/en/latest/ref/states/all/salt.states.boto_elb.html
23:06 djgerm thank you. I definitely need to get better at that
23:06 djgerm as always, I appreciate this channels support and patience ^_^
23:10 debian112 joined #salt
23:15 fracklen joined #salt
23:16 debian1121 joined #salt
23:25 pipps joined #salt
23:28 oaken_chris joined #salt
23:30 debian112 joined #salt
23:33 LordOfLA joined #salt
23:35 debian1121 joined #salt
23:38 debian112 joined #salt
23:39 IdoKaplan joined #salt
23:41 gableroux joined #salt
23:41 IdoKaplan Hi, I'm trying to configure "Windows Software Repository" and it's looks like that the state in the example are no yaml. Can you please explain? I get an error " State 'X' in SLS 've' is not formed as a list"
23:45 hemebond IdoKaplan: It means a state is not written properly.
23:45 hemebond You'll have to show us your state.
23:49 IdoKaplan hemebond: http://pastebin.com/a05Qcy2Y
23:49 IdoKaplan Copied from "https://docs.saltstack.com/en/latest/topics/windows/windows-package-manager.html"
23:50 hemebond Is that your X state?
23:50 hemebond in file ve
23:50 hemebond You have a file ve.sls with state X that is incorrect.
23:50 IdoKaplan i have a folder ve and init.sls
23:51 IdoKaplan State 'firefox' in SLS 've' is not formed as a list
23:52 debian1121 joined #salt
23:53 hemebond Are you trying to use this as a regular state?
23:53 hemebond I don't think that's what this is for.
23:53 hemebond This is like a package registry.
23:53 IdoKaplan yes, on regular state.
23:53 IdoKaplan Do you know how to use it?
23:53 hemebond I think this 'firefox' definition goes under winrepo directory or something.
23:54 hemebond I haven't used the Windows repo stuff since it changed.
23:54 whytewolf actually it doen'st go in the state tree at all.
23:54 hemebond Yeah it's not a state.
23:55 hemebond I don't know where the new repo puts its definitions.
23:55 whytewolf https://docs.saltstack.com/en/latest/topics/windows/windows-package-manager.html#maintaining-windows-repo-definitions-in-git-repositories
23:55 whytewolf and https://docs.saltstack.com/en/latest/topics/windows/windows-package-manager.html#repository-location
23:56 whytewolf honestly should check the built in win_repo make sure you want to define that
23:56 dendazen joined #salt
23:56 hemebond Yeah I thought it downloaded package definitions from github now.
23:57 whytewolf read that page from the top. it describes how to sync the win_repo default from github
23:57 whytewolf salt-run winrepo.update_git_repos
23:57 whytewolf salt -G 'os:windows' pkg.refresh_db
23:57 Renich__ joined #salt
23:58 fxhp joined #salt
23:59 pipps joined #salt

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