Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2018-03-18

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

All times shown according to UTC.

Time Nick Message
00:00 rjc MTecknology: copy pasted the example as is
00:02 rjc well, apart from changing the 60 to 20, obviously ;)
00:07 megamaced joined #salt
00:07 zer0def have you restarted the master since adding those changes, rjc?
00:08 rjc zer0def: I've done the change weeks ago - restarted all machines dozens of times, only noticed by accident due to a different thing
00:11 zulutango joined #salt
00:11 rjc rather than all of us guessing :^) I'm just going to ask one questions: is anyone using highstate scheduling as desribed in the above link with frequency <60 minutes?
00:12 rjc if so, I'd greatly appreciate if you could share that part of your config, please
00:12 rjc :)
00:13 zer0def i mean, there's no need to guess, you'd see an event on the event bus whenever a job's scheduled (like periodic highstates)
00:16 zer0def i'd try with a different schedule name and possibly add `enabled: true` to the schedule's dictionary
00:16 cgiroua joined #salt
00:17 zer0def also, ref here for kwargs for a schedule: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.schedule.html#salt.states.schedule.present
00:18 rjc zer0def: OK, so are you trying to say that "as is", the example provided *is wrong* and won't work?
00:19 zer0def the example looks fine
00:20 zer0def there's probably an XY problem somewhere in your scenario
00:20 rjc also, from the example itself, and the documentation around schedule, it's not terribly obvious where to put the config
00:20 rjc I added it to the pillar
00:21 zer0def so the highstate runs, just not at a rate you've set? i'd try refreshing the pillar
00:21 rjc zer0def: anything's possible - my question is "why an example in the official documentation doesn't work?"
00:22 rjc zer0def: pillar gets refreshed at each highstate, right?
00:22 zer0def no?
00:22 zer0def read the docu.
00:23 zer0def as mentioned, this is probably a XY problem, where you think something was done, when in fact it wasn't; or something of the sort, anyway.
00:28 hemebond I do wish the master was better at refreshing pillar data on highstate.
00:35 rjc zer0def: seeing bug reports from 2013 regarding pillar refresh and highstate, I thought that would have been fixed by now
00:36 rjc regardless, I obviously did refresh it manually dozens of times
00:38 MTecknology are the bugs closed?
00:45 rjc https://github.com/saltstack/salt/issues/5716
00:45 rjc https://github.com/saltstack/salt/pull/7630
00:46 rjc pull request references the issue, which is closed
00:46 MTecknology so then the follow-up becomes- Can you confirm that this is indeed the bug you're hitting?
00:46 MTecknology Considering a manual refresh isn't helping, I would suspect your problem is elsewhere.
00:48 hemebond That suggests an error in the pillar data itself. No errors in the master log?
00:48 hemebond Does pillar.items return all the info?
00:48 hemebond (I haven't followed this conversation at all, just poking my nose)
00:49 hemebond *nose in)
00:50 rjc hemebond: yes, both pillar.date and pillar.items return the info
00:51 hemebond Does pillar.get return the correct info?
00:55 rjc that's interesting - I'm getting two different reading: one with _ and one without
00:55 rjc i.e. _run_on_start:
00:55 rjc False
00:55 rjc run_on_start:
00:55 rjc True
00:55 rjc wtf?
00:56 hemebond Which one is returning which?
00:56 rjc _seconds:
00:56 rjc 1200
00:56 rjc minutes:
00:56 rjc 20
00:56 MTecknology rjc: use a pastebin service next time
00:56 rjc for two lines at a time?
00:56 rjc ;)
00:56 MTecknology I'm counting 8 lines of spammy paste
00:57 MTecknology Yes, use pastebin for >1 line
00:57 rjc ok, will do next time
00:57 exarkun joined #salt
00:59 rjc http://ix.io/YGQ
01:07 rjc ok, so the _ values seem to be coming from /etc/salt/minion.d/_schedule.conf
01:07 rjc http://ix.io/YF4
01:08 MTecknology https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.schedule.html#salt.modules.schedule.reload
01:12 rjc ok, not entirely sure what should happen now
01:14 MTecknology Did you read what it does?..
01:15 rjc sure
01:16 rjc I can't find any information on _schedule.conf though and no idea where these values come from - reload doesn't change them there
01:18 rjc I like salt, more than I liked puppet
01:18 rjc scheduling highstate shouldn't be so hard
01:19 MTecknology it's not
01:19 rjc as in "do everything I asked you to do every 10 minutes", and boom, it works... except it doesn't
01:19 rjc :(
01:20 hemebond You've done a sync_all, yeah?
01:22 rjc how many other incantations do I need to do between each, supposedly, scheduled highstate?
01:23 MTecknology that's an invalid question considering you still don't know what's wrong
01:24 * hemebond should probably read the full conversation or butt out
01:24 MTecknology hemebond: nah, we're all still just guessing because we don't yet have a complete picture of what's going on
01:25 hemebond Has the actual pillar been pasted somewhere?
01:25 MTecknology not that I saw
01:26 rjc hemebond: copy-pasted from official documentation - 60 changed to 20
01:26 rjc MTecknology: I have sent a link to the official doc at the very beginning
01:27 rjc https://docs.saltstack.com/en/latest/topics/jobs/#scheduling-highstates
01:27 MTecknology yes, you did.. that wasn't his question
01:27 hemebond I stopped using the scheduler a while back. I'll go refresh.
01:28 rjc the qestion was about the pillar - this *is* the pillar + s/6/2/
01:28 rjc http://ix.io/LFs
01:29 justanotheruser joined #salt
01:30 hemebond I don't have any scheduled jobs :-(
01:31 rjc hemebond: ok, I clearly don't get it - this is a copy-pasted example from official documentation
01:31 hemebond Can you put up a paste with 'cat /etc/salt/minion.d/_schedule.conf', schedule.list, pillar.get schedule
01:31 hemebond rjc: Sure, it should work, but something is broken somewhere, that's all. We'll find it :-)
01:32 rjc run highstate every 60 minutes - I want it to run every 20 minutes
01:32 hemebond To be honest, I stopped using the scheduler a while back because of a bug that meant it wouldn't remove old jobs.
01:32 hemebond Oh, I wonder if that bug is still open.
01:33 MTecknology I stopped using it because the processes kept getting wedged.
01:33 hemebond wedged?
01:34 hemebond rjc: Please include the commands in your paste so I can identify where the output is from.
01:34 MTecknology tasks wouldn't execute because something in the scheduler broke, which also kept me from being able to gracefully restart the minion process.
01:35 rjc hemebond: schedule.list http://ix.io/YI3
01:35 hemebond rjc: Can you pop them all into the same paste?
01:35 rjc the other two are already included above
01:35 hemebond The other pastes didn't include the command.
01:36 * MTecknology is always intrigued when people asking for help demand to be helped in a certain way.
01:36 hemebond Also, which version of salt are you running?
01:38 rjc hemebond: pillat.get schedule http://ix.io/YF4
01:39 hemebond :-|
01:40 rjc that was the _schedule, sorry - I'm basically copy pasing links which are two screens up
01:40 hemebond Right, what I need is you to run those commands again and paste the results, along with the commands, into a single paste.
01:41 hemebond I have a lot of stuff open right now so it's difficult to keep track of random tabs tied to a line in IRC.
01:41 MTecknology not to mention you've asked that repeatedly..
01:42 rjc one sec - I'll concatenate it all into as singe one with commands above, how's that?
01:42 hemebond I'll also add `pillar.items schedule` to the list of commands.
01:42 rjc :)
01:43 rjc MTecknology: I also don't like to repeat myself - links were there, short and self-explanatory
01:43 MTecknology rjc: We also do not like repeating ourselves. It helps when you do what was asked the first time.
01:43 MTecknology Stop expecting us to help you as you see fit.
01:45 rjc MTecknology: hemebond asked for it, not you, and I'm sending it now
01:45 rjc :)
01:45 * MTecknology blinks
01:45 rjc BTW, thanks for your help
01:54 rjc http://ix.io/YIH
01:54 rjc salt 2017.7.4 (Nitrogen)
01:55 hemebond 👍
01:55 rjc :)
01:55 hemebond What is that third part? Just the pillar text?
01:56 hemebond From the pillar file itself?
01:56 shiranaihito joined #salt
01:57 rjc oops - I cut pillar.get from it
01:58 rjc fixed http://ix.io/YIW
01:58 rjc :)
01:58 hemebond And the actual pillar data in the file is literally two lines/parameters?
01:58 rjc yup
01:58 rjc keeping it to the minimum - recreating my puppet configuration step by step
01:59 rjc first, I'd like to get everything applied every 20 minutes, without ay manual intervention or putting salt commands into a cron job
01:59 hemebond Can you add `schedule.list show_all=True show_disabled=True`
01:59 rjc sure
02:00 hemebond Aside: that scheduled update was one of the reasons I ditched Puppet.
02:02 rjc http://ix.io/YJ6
02:03 hemebond And the problem is: highstate still only runs every 60 minutes?
02:03 MTecknology schedule.list looks like what you'd expect it to..
02:03 hemebond Yeah, things look fine to me.
02:04 MTecknology rjc: What do you have that shows it not working as expected?
02:05 hemebond Yeah, is there anything in the master event bus?
02:05 hemebond Oh, I wonder if salt-call returns the same data.
02:05 hemebond `salt-call schedule.list`
02:05 hemebond On the minion itself.
02:11 rjc MTecknology: like I've mentioned before, I had noticed it by chance - seen this in my logs once and hour:
02:11 rjc Neither 'source' nor 'contents' nor 'contents_pillar' nor 'contents_grains' was defined, yet 'replace' was set to 'True'. As there is no source to replace the file with, 'replace' has been set to 'False' to avoid reading the file unnecessarily.
02:12 rjc right, time to get some sleep - it's a bit leate/early here :)
02:12 hemebond 👋
02:12 rjc thanks a lot for all your time
02:12 rjc will need to resume tomorrow
02:12 hemebond Tomorrow check that stuff from the minion, instead of the master.
02:12 hemebond i.e., salt-call
02:12 rjc will do
02:12 rjc thanks again
02:14 hemebond Next step after that would be to add some other more frequent scheduled jons.
02:14 hemebond *jobs
02:15 rjc ok, one last question before I go - how do people ensure their system are compliant if not running highstate via schedule?
02:15 rjc I'm using Puppet analogy here so my view is obviously skewed :)
02:16 hemebond I'm not particularly worried about it. If I really wanted to I'd monitor `state.apply test=True`
02:17 MTecknology I use cron
02:17 rjc right, that's paramount here hence looking at schedukle
02:17 rjc schedule
02:17 hemebond I would still only monitor it.
02:18 rjc MTecknology: given that schedule exists, using cron feels kinda wrong - after all, I could just script the whole thing and have all the basic salt functionality there ;)
02:18 rjc I always try using built-in features as much as possible
02:19 MTecknology I have a daily state.highstate as well as state.highstate scheduled when I do a push to certain git repos.
02:19 rjc I like things to be self-contained
02:19 rjc fewer external dependencies the better
02:19 MTecknology you seem like someone that likes docker
02:19 rjc haha
02:19 rjc :)
02:19 rjc never used it
02:20 MTecknology look at bottle.py docs and tell me how to read the contents of an uploaded file!!
02:20 MTecknology (please)
02:21 MTecknology D'OH!!
02:21 MTecknology I had it, but when I was assigning the variable, I used == instead of =
02:23 rjc I couldn't use docker even if I wanted to (and I don't) :)
02:33 exarkun joined #salt
02:56 mateothegreat joined #salt
02:58 ilbot3 joined #salt
02:58 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.9, 2017.7.4 <+> RC for 2018.3.0 is out, please test it! <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic, and https://saltstackcommunity.herokuapp.com (for slack) <+> We are volunteers and may not have immediate answers
04:03 zerocoolback joined #salt
04:12 exarkun joined #salt
04:37 ln55SNTQE joined #salt
04:40 indistylo joined #salt
05:34 jab416171 joined #salt
05:45 AvengerMoJo joined #salt
05:50 indistylo joined #salt
05:53 exarkun joined #salt
05:59 mikecmpbll joined #salt
06:43 indistylo joined #salt
07:16 s0undt3ch_ joined #salt
07:17 andrew1 joined #salt
07:17 phtes joined #salt
07:17 doriftoshoes____ joined #salt
07:18 tcolvin joined #salt
07:18 czchen joined #salt
07:18 hillna joined #salt
07:18 petems joined #salt
07:18 czchen joined #salt
07:18 tcolvin joined #salt
07:18 hillna joined #salt
07:18 petems joined #salt
07:18 v0rtex_ joined #salt
07:19 inetpro joined #salt
07:19 vexati0n joined #salt
07:20 aviau joined #salt
07:20 fxhp joined #salt
07:21 shakalaka joined #salt
07:29 nickadam_ joined #salt
07:31 nledez joined #salt
07:31 nledez joined #salt
07:32 exarkun joined #salt
07:56 zer0def rjc: when you get an opportunity, you can check whether the scheduled highstates actually run by running https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.jobs.html#salt.runners.jobs.list_jobs and substituting `search_function`'s value for `state.highstate`, should list all `state.highstate` executions you have in your job cache, so it might be a little verbose
08:13 cyteen joined #salt
08:50 rjc zer0def: OK, so I've found a discrepancy pillar.data/pillar.items vs pillar.get
08:50 rjc between
08:51 zer0def `.items()` and `.get()` are essentially python dictionary functions, so if there's a discrepancy between those, it would be _pretty_ serious - care to present?
08:53 evle joined #salt
08:54 rjc well, I've done further tests and change the value again - .data and .items return the value I had just changed
08:54 rjc .get shows me the old value
08:54 zer0def have you refreshed the pillar?
08:54 rjc old = current
08:55 zer0def as far as i can tell, they are periodically refreshed, just not frequently
08:55 rjc zer0def: that's the crux of it all - some stuff seems to be refreshed automatically during highstate but doesn't seem like schedule is one of those things
08:56 zer0def does refreshing them manually achieve the schedule refresh?
08:59 rjc yes
08:59 rjc :"
08:59 rjc :@
09:00 rjc The in-memory pillar data is generated on minion start, and can be refreshed using the saltutil.refresh_pillar function:
09:00 zer0def well, that's good
09:00 rjc from https://docs.saltstack.com/en/latest/topics/pillar/
09:00 indistylo joined #salt
09:00 zer0def yes, i'm aware; to double-check your schedule is in effect, i'd probably use the job cache inspection function i've linked an hour ago
09:00 zer0def just to be as positive about it as possible
09:01 rjc well, I had to will check in an hour - should now see 4 vs 3 jobs :)
09:01 zer0def well, if you updated your schedule, i imagine there will be more results
09:01 zer0def more than +1, that is
09:02 rjc I need to do some more digging - at first glance it seems like adding data to pillar works straight away
09:03 rjc I've tested it on Friday by adding a direct link to a package there
09:03 rjc got installed straight away
09:03 rjc no refresh necessary
09:04 rjc now, I'll need to check whether substituting it for a different package/version would still work
09:04 rjc it probably will - after all there's a state which calls pillar['package_name']
09:04 rjc will double-check regardless
09:05 rjc it seems like schedule is special
09:05 rjc anyway
09:05 zer0def well, given how there are particular pillars affecting current configuration, it might be somewhat reasonable to not apply those changes immediately and require an additional step
09:06 zer0def would need to go through the code and check (or someone more competent could chime in on) this behavior
09:09 rjc sure - however, if I didn't want to make the changes immediately, I would not have change the data in the pillar ;)
09:11 zer0def so you basically have different expectations on default behavior - i'd just develop a habit of "whenever a pillar value can be set through actual master/minion config options, it'd be a good idea to refresh"
09:13 rjc zer0def: that's exactly what is taking place here :)
09:13 exarkun joined #salt
09:14 zer0def i figure it's reasonable to reload whenever i change my service config
09:14 rjc I think I'll just tart using entr(1)
09:14 rjc start
09:15 rjc watch pillar and refresh it every time it changes - regardless whether change would actually require the compilation step or not
09:21 rjc zer0def: anyway, thanks for all your help - thanks go to MTecknology and hemebond, too
09:21 rjc sorry for wasting your time in a way
09:23 rjc zer0def: that habbit might be a good one - I will do some more digging and try to figure out whether schedule is special
09:24 zer0def well, hopefully you got your things sorted now
09:24 Guest73 joined #salt
09:24 rjc "*always* run pillar refresh" is my mantra now.... until I figure out whether this is a bug ;)
09:25 zer0def i'd narrow it down to "always run `saltutil.refresh_pillar` whenever it's a configuration option"
09:25 rjc I *will* use entr(1), too - just in case - two steps is one too many for a mere human being at times ;)
09:26 zer0def that is assuming you want that configuration in effect when you do refresh
09:33 rjc like we have both agreed - different approach :) if I didn't, I would not have changed the value in pillar ;)
09:42 aruns__ joined #salt
09:54 colegatron joined #salt
09:54 colegatron left #salt
09:56 cewood joined #salt
10:08 aldevar joined #salt
10:25 mikecmpbll joined #salt
10:27 indistylo joined #salt
10:31 tuxawy joined #salt
10:37 colegatron joined #salt
10:54 exarkun joined #salt
11:07 Guest73 joined #salt
11:14 zerocoolback joined #salt
11:16 upb joined #salt
11:37 mnieber joined #salt
11:48 evle1 joined #salt
11:49 zerocoolback joined #salt
12:33 exarkun joined #salt
12:37 cyteen joined #salt
12:40 exarkun joined #salt
13:04 systeem[m]1 joined #salt
13:08 Deadhandd left #salt
13:08 Deadhand joined #salt
13:22 lionel joined #salt
13:23 zerocoolback joined #salt
13:45 zerocoolback joined #salt
13:46 zerocoolback joined #salt
13:47 zerocoolback joined #salt
13:47 zerocoolback joined #salt
13:48 oida joined #salt
13:48 zerocoolback joined #salt
14:10 johnkeates joined #salt
14:13 johnkeates sudo salt-call state.apply prometheus.exporter.node.install gives a JINJA error about .version not being an attribute but .version doesn't exist in install.sls, and -ltrace doesn't show a partial render
14:13 exarkun joined #salt
14:15 johnkeates relevant file: relevant file: https://github.com/johnkeates/prometheus-formula/blob/split-formulas-wip/prometheus/exporter/node/install.sls
14:32 ztux joined #salt
14:33 ztux left #salt
14:34 XenophonF joined #salt
14:35 tiwula joined #salt
14:43 justanotheruser joined #salt
14:46 om2 joined #salt
14:48 qwe joined #salt
14:48 qwe left #salt
14:56 tyx joined #salt
14:59 tyx joined #salt
15:05 tyx joined #salt
15:08 tyx joined #salt
15:23 johnkeates joined #salt
15:26 johnkeates joined #salt
15:30 dkehn joined #salt
16:28 JPT joined #salt
16:33 Guest73 joined #salt
16:38 Guest73 joined #salt
16:41 yidhra joined #salt
17:27 tiwula joined #salt
17:31 oida joined #salt
17:33 ffledgli1g left #salt
17:33 onslack <scub> Is there a way for file.serialize to preserve the capitalization of pillar objects? Presumably this is dependent on the serializer module thats used, in which case specifically with the ‘configparser’ serializer<https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.serialize>
17:36 mikecmpbll joined #salt
17:37 MTecknology What's your actual state? I wouldn't expect it to remove case unless the encoding is case insensitive.
17:39 Deliant joined #salt
17:51 onslack <scub> <https://gist.github.com/scub/2d01605975733a1077449377fb04abe3>
17:51 onslack <scub> The state and corresponding pillar structure
17:52 onslack <scub> its preserving the top-level keys and values, but nested keys are having the case stripped
17:52 MTecknology I suspect that's probably a symptom of configparser itself. Have you tried spitting it out to a yaml file where we could expect case to not change?
17:53 MTecknology I also wanna ask why you're not just using file.managed since it would probably be way easier and have less overhead.
17:55 onslack <scub> Was suspecting as much, yaml does indeed render as you expect with the case preserved. I could write a jinja template and use file.managed, but if your config is json/yaml/configparser format why bother writing jinja at all? It’s less to maintain and easier to work with in the event that it works >;.<;
17:57 MTecknology that question makes my brain hurt
17:59 onslack <scub> lol, if you stare too long at the jinja… sometimes it stares back into you…. o.o
18:00 MTecknology The last time I stared too long at jinja, I was refactoring this-> https://github.com/saltstack/salt/blob/develop/salt/templates/debian_ip/debian_eth.jinja
18:00 MTecknology afaict- you don't even need templating.
18:04 onslack <scub> That structure is a bit simplified to showcase the problem, but its not entirely DRY so the elasticity will prove useful down the road. Dropping flat files out of a file root always makes me feel dirty anyways lol
18:05 MTecknology What does "Dropping flat files out of a file root" mean?
18:05 zer0def dumb idea, have you tried applying the `yaml` or `json` filters onto the jinja template var, scub?
18:05 onslack <scub> <https://docs.python.org/2/library/configparser.html#ConfigParser.RawConfigParser> arg.
18:05 onslack <scub> >; All option names are passed through the optionxform() method. Its default implementation converts option names to lower case.
18:05 MTecknology zer0def: he has, yes
18:06 MTecknology zer0def: it's the configparser serializer that's changing case
18:06 onslack <scub> For lack of a better way of describing it, having “pre-rendered” content provided through a file.managed call
18:07 MTecknology I have one repo for templates, the directory structure mimics where they'll end up on the system.
18:07 onslack <scub> Sounds like you need more formulas in your life
18:08 MTecknology formulas are for people that don't want to know how anything they're deploying works..
18:08 MTecknology it does sound like you found a legitimate bug, though
18:09 zer0def substitute "formula" for "cookbook" and you're already making me giggle
18:09 MTecknology an easily fixed one :)
18:10 onslack <scub> well yea, the question is do they want it fixed, lol <https://github.com/saltstack/salt/blob/develop/salt/serializers/configparser.py#L96>
18:10 onslack <scub> cause that looks like it needs a comment to me ;)
18:11 onslack <scub> <https://media.giphy.com/media/3ohs4iqMAM1299ozw4/source.gif>
18:14 MTecknology I don't see SafeConfigParser for py3
18:14 zer0def wouldn't it be py2?
18:15 zer0def oh, nevermind, you were probably looking for the same class *in* py3
18:15 zer0def scub: luckily, you can easily override serializers on your own
18:16 MTecknology if ! py3, it should already be using SafeConfigParser
18:16 MTecknology but maybe that changed and isn't fixed in the version scub is using?
18:17 onslack <scub> im on 2017.7.4
18:17 onslack <scub> (just btw)
18:18 onslack <scub> I think i’ll just eat my pride and flat file it, lol
18:18 onslack <scub> thanks for the help gents <3
18:18 zer0def honestly? you're probably better off overriding the serializer on your end
18:18 zer0def especially given how small of a fix that would be
18:19 MTecknology keeping case is going to be harder in py3 it seems
18:20 zer0def oh?
18:22 MTecknology https://docs.python.org/3/library/configparser.html#ConfigParser.RawConfigParser
18:23 MTecknology I guess it's not harder.. just more effort than swapping a function name.
18:25 onslack <scub> It shouldn’t matter which really, that functionality is replicated in salt and wrapped outside of ConfigParser in _read_dict. The behavior of ConfigParser.set doesn’t change <https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.set>
18:28 onslack <scub> We force the optionxform on option keys when building the object they flush to disk, could add a switch to expose the ability to avoid that call and preserve the case but in the end consul should really just have a package instead of making me replicate the behavior of one in salt, lol.
18:29 onslack <scub> its been a fun adventure, im going to finish this formula up XD
18:30 MTecknology I still say that's the wrong solution, but glad you got it working
18:31 onslack <scub> what is?
18:33 zer0def MTecknology: what are you worried about in regards of py3? something's definitely blowing over my head
18:41 MTecknology scub: writing a file like that using file.serialize from pillar.
18:42 MTecknology zer0def: the configparser serializer uses SafeConfigParser for py2 and ConfigParser for py3.
18:42 zer0def which, from what i'm reading the docu, exhibit largely the same behavior
18:45 onslack <scub> ah, it’s fairly stylistic, but the module exists so why not use it when you can?  ¯\_(ツ)_/¯
18:47 onslack <scub> I’m certainly not going to write some jinja to write out a yaml/ConfigParser config
18:57 MTecknology "why not use it when you can" sounds like someone that's looking for the most complicated solution they can come up with in an effort to ensure future generations have no idea what's going on.
19:11 zer0def "why not use it when you can" also sounds like having little regard for sane solutions
19:12 AstraLuma Can salt urls refer to different saltenvs?
19:14 MTecknology not that I've ever seen
19:42 cewood joined #salt
19:42 onslack <scub> MTecknology: By that logic why make any modules when simple cmd.run statements will do it all? I’m not sure why looking at a pure salt implementation of simple configuration rendering is being conveyed as “complicated” or having little regard for sane implementations, but I am just a walrus so what do I know :3
19:44 MTecknology scub: You like formulas, so we already fundamentally disagree on every deployment we'll ever come across.
19:45 onslack <scub> Curious, is there a better way to write a standard json configuration without ‘file.serialize’?
19:45 onslack <scub> Formulas aside
19:45 MTecknology that seems like an appropriate use, but there's also the jinja filter for json output.
19:51 onslack <scub> I would agree. But if you can avoid writing jinja altogether with file.serialize, the jinja just adds additional complexity, wouldn’t you say?
19:52 zer0def i certainly wouldn't
19:53 MTecknology My argument was that it doesn't look like you really need much jinja in the first place, it looks like that file is quite static.
19:53 MTecknology just a simple text file, pushed across, cached, lightly templated, and ever-unchanging, vs. always xmiting the whole pillar structure many times throughout the day.
19:54 MTecknology and adding lots of extra cpu cycles for what really isn't needed
19:54 MTecknology "lots" ... maybe not seconds worth, but definitely microseconds..
19:54 zer0def well, given how that's a systemd service, yeah, one wouldn't expect it to change frequently
19:56 onslack <scub> Its a valid argument too, I’d say I wouldn’t need any jinja at all if systemd parsed ConfigParser to spec.
19:56 MTecknology systemDipshit
19:56 onslack <scub> haha
19:57 MTecknology systemDuhrr
19:57 zer0def you're probably overblowing this, defining an untemplated service file would suffice
19:57 onslack <scub> For what its worth, that structure was actually nested within the state, any pillar transmitted would be overriding the structure provided
19:58 onslack <scub> I definitely dont disagree with you there, I just went with the template at the end of the day
19:58 onslack <scub> cant blame a guy for trying ;)
19:58 wych joined #salt
19:58 zer0def oh, sure i can
19:58 MTecknology I try to convince people that the more a person knows, the more simply they can build generic solutions.
20:00 MTecknology complications come from someone just learning and trying to find a way to use everything they've ever learned when .... There's a picture for this!!!
20:00 zer0def as far as i'm aware of systemd, you can define reverse dependencies, anyway, so there ought to be no reason to template service files
20:00 MTecknology https://i.imgur.com/9R7mPue.png
20:02 onslack <scub> Im right there with ya, file.serialize is as generic as it gets. Look ma, no jinja! :P
20:02 zer0def i'm getting the impression of missing the forest for the trees
20:02 zer0def that's also a convenient excuse to eject from the conversation
20:03 onslack <scub> thumbsup
20:04 MTecknology scub: I'd be less opposed to keeping a yaml file next to the state for defaults and merging that with overrides from pillar and then using file.serialize from there.
20:04 MTecknology I still think it's wicked overkill, but I'd like that more than what you have now.
20:06 zer0def i'd argue that if you need to have any sort of dynamic behavior, be it jinja or `file.serialize` in something that equates to an init script, you're doing something horribly wrong
20:06 zer0def especially when you're clearly defining ways for parameterizing $service without the need for those
20:07 onslack <scub> MTecknology: what you are describing is what i’ve shown, just change pillar.sls to defaults.yml
20:08 onslack <scub> Real overrides would come through pillar, and its definitely overkill, but i’ve gotta wrap what I can when I don’t have a say in the software development process.
20:09 onslack <scub> whether its through file.serialize or file.managed, using salt to manage an init script is where this went wrong, it should be provided in a package
20:10 MTecknology There's nothing wrong with needing to manage init scripts
20:10 onslack <scub> other than when you do it without jinja, it would seem
20:10 zer0def you realize you're using systemd, right? overriding can be done as a separate file
20:11 MTecknology I've never added jinja to init stuff, it's just static files that don't need overrides
20:12 zer0def in fact, despite it being what it is, it provides you with loads of avenues to never have dynamic behavior relating to the basic init script
20:12 zer0def s/dynamic/templating/
20:12 onslack <scub> I do, and overrides are super useful, especially if you actually have an existing unit file. However with Hashicorp’s consul they don’t provide one, you just get a zip with a statically compiled binary with lots of hopes about backwards compatibility: <https://www.consul.io/docs/install/index.html#precompiled-binaries>
20:14 zer0def Hashicorp's issues aside, that doesn't imply a lack of a bundled init script means there couldn't have as well been one
20:15 Guest73 joined #salt
20:15 zer0def s/one/a static one/
20:16 onslack <scub> I am unaware of any magic that will generate an sysv init script or systemd unit file automatically and without instructions
20:16 onslack <scub> you can crack open that zipfile if you don’t believe me that it contains a single static binary and nothing else
20:16 zer0def still going on about generating/dynamic/templating
20:16 onslack <scub> not sure im tracking
20:19 MTecknology scub: Wanna help me write a supybot module?!
20:21 onslack <scub> Im down
20:21 onslack <scub> whats it do? lol
20:22 mavhq joined #salt
20:22 tiwula joined #salt
20:23 MTecknology It needs to send an api request with a configured token to a service, if the user is authorized to use the command, and return a message to the user that ran the command.
20:24 MTecknology I have a pastebin service that relays messages to an IRC channel and I'm writing the API for blocking spam. I haven't done much more than think up what I just said as far as bot interaction goes.
20:25 tiwula joined #salt
20:34 onslack <scub> on message return would it be a direct message or published back into the channel that initiated the action
20:34 MTecknology pm, not channel
20:35 MTecknology it's going to return an IP address of the offender so it can be cross-referenced with users in the channel.
20:37 onslack <scub> seems straightforward enough, what part is giving you trouble
20:37 MTecknology I haven't started
20:37 onslack <scub> hah
20:37 MTecknology I'm working on the API
20:37 onslack <scub> usually seems to be the hardest part doesn’t it
20:37 onslack <scub> nice
20:38 onslack <scub> is the offender just the person that made the request to the api?
20:38 MTecknology I was asking for help writing it, not figing out anything tricky
20:41 onslack <scub> it sounds like 3 lines of python plugged in their template generator: `import requests; res = requests.get('api_url'); ircReply( res.content )`.
20:41 MTecknology I think there's a chance I just finished writing the API and the entire block system.
20:41 MTecknology does supybot have a template generator?
20:41 onslack <scub> believe so, you just plug and play
20:41 MTecknology that's exciting
20:42 onslack <scub> Do I still get the author credit ;)
20:42 onslack <scub> lol
20:42 MTecknology man, bottle.py is sexy bizness
20:43 tiwula joined #salt
21:15 tiwula joined #salt
21:39 tiwula joined #salt
21:41 tiwula joined #salt
22:16 MTecknology scub: I'm not seeing any plugin generator. Do you have a link?
22:27 mechleg joined #salt
22:55 jkleckner joined #salt
23:32 Darcidride__667 joined #salt
23:55 mk-fg joined #salt
23:55 mk-fg joined #salt

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