Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-06-24

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

All times shown according to UTC.

Time Nick Message
00:39 dxiri joined #salt
00:56 Armageddon joined #salt
01:00 major joined #salt
01:02 drewbert Does cachedir on the minion need to persist between reboots?
01:04 dxiri joined #salt
01:08 whytewolf not really. but if you are deleting it between reboots you should sync any custom modules or what not againt when it starts up
01:09 whytewolf also going to slow down things a lot
01:15 major joined #salt
01:19 Trauma joined #salt
01:26 drewbert hrmm, I have a read-only linux partition, a tmp directory, and a /persist partition. I can put it in persist.  /var/run/salt is writeable, naturally.  I stuck the pki_dir in the persist partition. I guess I'll stick the cache in the persist as well.  I think I'll dump the logs in /tmp
01:28 nineteen joined #salt
01:46 timoguin joined #salt
02:00 ahrs joined #salt
02:01 pbandark joined #salt
02:07 ahrs joined #salt
02:08 asyncsec joined #salt
02:10 ahrs joined #salt
02:10 onlyanegg joined #salt
02:23 asyncsec joined #salt
02:26 vegasq joined #salt
02:26 hemebond left #salt
02:28 Bock joined #salt
02:32 flowstategames joined #salt
02:33 debian112 joined #salt
02:49 onlyanegg joined #salt
03:00 debian112 joined #salt
03:09 AvengerMoJo joined #salt
03:11 Bock joined #salt
03:13 Bock joined #salt
03:15 evle joined #salt
03:18 Bock joined #salt
03:24 donmichelangelo joined #salt
03:32 jwarren_ joined #salt
03:37 beardedeagle joined #salt
03:38 jwarren_ Hey folks, I just upgraded to 2016.11.5 and I'm running into an issue with git.latest. I have local changes in the git repo on my server, but I want to do a force checkout/reset to my origin branch. My old state was using force_reset, force_checkout and force. Force was deprecated and replaced by force_clone, so I updated that. But Salt is failing on that step the first time, but succeeds if I rerun it.
03:39 jwarren_ I think what's happening is it's trying to do a --ff-only, fails, then does a force reset and exits with a 1.
03:39 jwarren_ After the first run all local changes in the repo are wiped (which is what I want), but it still thinks it failed because for whatever reason it's trying to do a --ff-only at the beginning of the state. Is this a known bug?
03:40 dxiri joined #salt
03:43 jwarren_ Here's the log output: https://bpaste.net/show/d5a829f7acec
03:45 beardedeagle joined #salt
03:48 beardedeagle joined #salt
03:49 onlyanegg joined #salt
03:51 beardedeagle joined #salt
03:59 zerocoolback joined #salt
04:00 zerocoolback joined #salt
04:04 armyriad joined #salt
04:05 cliluw joined #salt
04:11 mpanetta_ joined #salt
04:19 cgiroua joined #salt
04:50 onlyanegg joined #salt
04:51 dxiri joined #salt
05:18 dxiri joined #salt
05:36 aldevar joined #salt
05:43 aldevar left #salt
05:54 justanotheruser joined #salt
05:56 pbandark joined #salt
06:04 justanotheruser joined #salt
06:05 armyriad joined #salt
06:25 gmoro_ joined #salt
06:34 seffyroff joined #salt
06:43 mpanetta joined #salt
06:43 armyriad joined #salt
06:45 CEH joined #salt
06:51 onlyanegg joined #salt
07:01 Trauma joined #salt
07:20 dxiri joined #salt
07:26 wryfi joined #salt
07:37 dxiri joined #salt
08:08 salty_grains joined #salt
08:13 salty_grains boop
08:18 fritz09 joined #salt
08:36 inad922 joined #salt
08:48 xet7 joined #salt
08:51 dxiri joined #salt
08:52 onlyanegg joined #salt
08:53 preludedrew joined #salt
09:14 NNew joined #salt
09:18 dxiri joined #salt
09:28 nocaberi joined #salt
09:36 inad922 joined #salt
09:49 dxiri joined #salt
09:50 pbandark joined #salt
10:00 Trauma joined #salt
10:19 Praematura joined #salt
10:20 Inveracity joined #salt
10:22 dxiri joined #salt
10:44 mpanetta joined #salt
10:52 onlyanegg joined #salt
10:55 canorebi joined #salt
11:04 nocaberi joined #salt
11:14 ninjastrong joined #salt
11:17 LeProvokateur joined #salt
11:18 ninjastrong left #salt
11:26 cyborg-one joined #salt
11:27 bluenemo joined #salt
11:30 Praematura joined #salt
11:48 qwertyco joined #salt
12:00 qwertyco joined #salt
12:02 onlyanegg joined #salt
12:11 qwertyco joined #salt
12:14 qwertyco joined #salt
13:01 Xenophon1 joined #salt
13:15 fritz09 joined #salt
13:16 inetpro joined #salt
13:24 vegasq joined #salt
13:31 cyteen joined #salt
13:35 systeem joined #salt
13:38 stack joined #salt
13:38 stack hi, is that possible to have "real time" logs of salt state apply and not a summary report at the end?
13:45 inetpro joined #salt
13:48 asyncsec joined #salt
14:03 onlyanegg joined #salt
14:13 CEH joined #salt
14:33 fritz09 joined #salt
14:36 inetpro joined #salt
14:52 scarcry joined #salt
14:56 XenophonF stack: one way might be to run `salt-call state.apply --log-level debug` on the minion itself
14:57 XenophonF run `man salt-call` for additional log levels
14:58 cgiroua joined #salt
15:01 cgiroua joined #salt
15:02 cgiroua joined #salt
15:03 onlyanegg joined #salt
15:09 nicksloan joined #salt
15:27 heyimawesome joined #salt
15:27 dxiri joined #salt
15:47 mikecmpbll joined #salt
15:59 FreeSpencer joined #salt
15:59 FreeSpencer joined #salt
16:06 absolutejam Hey, anyone got any insights into how beacons work?
16:07 absolutejam Could I have a long running watcher and the beacon event run every 5,10,etc seconds to check on it?
16:07 absolutejam Looking at inotify now but I'm not familiar with inotify python module. Want to see if I can emulate with a file system watcher or registry watcher dot net class
16:18 aldevar joined #salt
16:37 aldevar joined #salt
17:01 inetpro joined #salt
17:04 onlyanegg joined #salt
17:06 dxiri joined #salt
17:34 Praematura joined #salt
17:39 flowstategames joined #salt
17:39 dxiri joined #salt
17:40 absolutejam If not, I guess I could use a runner to do so but it doesn't seem right
17:40 absolutejam I mean an engine
18:01 dxiri joined #salt
18:05 onlyanegg joined #salt
18:20 timoguin joined #salt
18:30 johnkeates joined #salt
18:30 dxiri_ joined #salt
18:31 johnkeates salt postgres practically always fails when setting a database owner
18:31 johnkeates it's so annoying
18:32 cyborg-one joined #salt
18:33 sjorge joined #salt
18:41 aldevar joined #salt
18:48 timoguin joined #salt
19:06 onlyanegg joined #salt
19:06 dxiri joined #salt
19:12 whytewolf stack: you can use event driven info. thought there was a way to do it for all states. https://docs.saltstack.com/en/latest/ref/states/requisites.html#fire-event-notifications and just watch the event bus
19:13 timoguin_ joined #salt
19:25 oida joined #salt
20:12 dxiri joined #salt
20:22 CEH joined #salt
20:22 absolutejam Alright, I dropped my query into salt-users: https://groups.google.com/forum/#!topic/salt-users/9o1Cf2Rqnkk
20:23 absolutejam Feel free to drop in any nuggets of wisdom ;)
20:36 onlyanegg joined #salt
21:11 timoguin joined #salt
21:18 callmecabman joined #salt
21:37 onlyanegg joined #salt
21:38 flowstategames joined #salt
22:09 cgiroua joined #salt
22:23 dxiri joined #salt
22:33 jeddi joined #salt
22:42 whytewolf absolutejam: you want an engine for what you want to do. beacons are not long running processes. the inotify one you are trying to compare against is actually a linux kernel module and the python module just checks if the kernel has noticed any changes since the last time it ran.
22:48 EmuleKadtorrent joined #salt
22:49 EmuleKadtorrent left #salt
22:57 absolutejam I thought it might be the case. I couldn't tell if somewhere the inotify beacon was starting an inotify process or something, but thanks for clarifying
22:58 whytewolf there are times i wish windows had something like inotify
22:58 whytewolf https://en.wikipedia.org/wiki/Inotify
23:36 asyncsec joined #salt
23:38 onlyanegg joined #salt
23:47 pcdummy joined #salt

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