Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-08-07

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

All times shown according to UTC.

Time Nick Message
00:05 sh123124213 joined #salt
00:05 mosen joined #salt
00:20 jthunt joined #salt
00:25 onlyanegg joined #salt
00:30 edrocks joined #salt
00:36 mTeK joined #salt
01:07 edrocks joined #salt
01:15 yidhra joined #salt
01:16 brianthelion joined #salt
01:51 ilbot3 joined #salt
01:51 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.6, 2017.7.0 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic <+> We are volunteers and may not have immediate answers <+> The call for speakers for SaltConf17 is now open: http://tinyurl.com/SaltConf17
01:56 nixjdm joined #salt
02:21 zerocool_ joined #salt
02:45 JPT- joined #salt
02:49 zenchiken joined #salt
02:54 hemebond joined #salt
02:57 edrocks joined #salt
02:59 zenchiken joined #salt
03:17 evle joined #salt
03:22 Ni3mm4nd joined #salt
03:35 edrocks joined #salt
04:02 mbuf joined #salt
04:13 mbuf joined #salt
04:26 swills joined #salt
04:34 cyborg-one joined #salt
04:37 PsionTheory joined #salt
04:41 Ni3mm4nd joined #salt
04:53 zenchiken joined #salt
04:55 golodhrim|work joined #salt
05:09 zulutango joined #salt
05:14 impi joined #salt
05:26 aphor_ joined #salt
05:31 felskrone joined #salt
05:48 lorengordon joined #salt
05:52 oida_ joined #salt
05:58 donmichelangelo joined #salt
05:59 pualj joined #salt
06:02 edrocks joined #salt
06:03 sh123124213 joined #salt
06:14 Yoda-BZH joined #salt
06:14 Yoda-BZH joined #salt
06:15 sgo_ joined #salt
06:15 preludedrew joined #salt
06:17 DarkKnightCZ joined #salt
06:28 do3meli joined #salt
06:28 do3meli left #salt
06:39 edrocks joined #salt
06:39 darioleidi joined #salt
06:40 Ricardo1000 joined #salt
06:46 darioleidi joined #salt
06:51 _KaszpiR_ joined #salt
06:51 high_fiver joined #salt
07:01 Kelsar joined #salt
07:13 CrummyGummy joined #salt
07:18 sh123124213 joined #salt
07:18 Hybrid joined #salt
07:29 usernkey joined #salt
07:37 jhauser joined #salt
08:11 impi joined #salt
08:14 Tucky joined #salt
08:16 Naresh joined #salt
08:17 kiorky joined #salt
08:19 Anatoliy_ joined #salt
08:19 mike25de joined #salt
08:20 * mike25de have a great start in the week everyone
08:22 Tucky joined #salt
08:29 edrocks joined #salt
08:31 Mattch joined #salt
08:34 citaret joined #salt
08:47 _KaszpiR_ joined #salt
08:48 darioleidi joined #salt
09:01 av__ joined #salt
09:04 kiorky joined #salt
09:05 _KaszpiR_ joined #salt
09:13 Miouge joined #salt
09:15 TyrfingMjolnir_ joined #salt
09:24 om2 joined #salt
09:28 frdm joined #salt
10:14 smartalek joined #salt
10:15 smartalek joined #salt
10:17 miruoy joined #salt
10:20 edrocks joined #salt
10:23 Tucky joined #salt
10:24 cablekevin joined #salt
10:25 gmacon joined #salt
10:26 johnkeates joined #salt
10:29 simon_c joined #salt
10:32 sgo_ joined #salt
10:34 cablekevin joined #salt
10:35 gmoro joined #salt
10:37 johnkeates joined #salt
10:42 pbandark joined #salt
10:46 saltsa joined #salt
10:57 edrocks joined #salt
11:08 simon_c Hi all. Still new to salt, and having problems getting my custom grains (in /srv/salt/_grains) to sync over to a minion. It looks like they are just not seen. running saltutil.sync_all doesn't show them being updated at all. Any ideas what I'm missing ?
11:13 brianthelion joined #salt
11:15 XenophonF simon_c: anything in either the minion or master error logs?
11:16 XenophonF can you post the code for your grain?  if not here's a custom grain I wrote that works: https://github.com/irtnog/active-directory-formula/blob/master/_grains/windows_installation_type.py
11:17 simon_c XenophonF: I've got a broken pillar, (which is why I'm looking at a custom grain for this)
11:17 simon_c XenophonF: It's the sample grain in the docs.
11:22 gmoro_ joined #salt
11:29 simon_c XenophonF: disabling my broken pillar doesn't make any difference. no errors in the server or client, even when running with -l debug
11:29 Ssquidly joined #salt
11:30 simon_c in fact, nothing about grains at all on the server when I run a sync_grains, it's almost as if it doesn't see the /srv/salt/_grains dir
11:32 sh123124213 joined #salt
11:49 pbandark1 joined #salt
11:49 cablekevin Hi
11:49 cablekevin Does anyone know why i get this error? "debconf.set is not available"
11:50 zerocool_ joined #salt
11:53 zerocool_ joined #salt
11:54 aldevar joined #salt
11:57 sgo_ joined #salt
11:58 babilen cablekevin: Did you install the Python module?
11:58 babilen (or debconf utils)
11:58 babilen Should be documented in the module docs
12:00 babilen My guess would be that you didn't install debconf-utils (do so in a state with reload_modules: True)
12:02 cablekevin I'm using the same state as this: https://www.snip2code.com/Snippet/310663/Salt-state-to-install-java-8-(Oracle-rep
12:02 cablekevin It worked before the weekend...
12:04 tacoboy joined #salt
12:07 babilen Yes, I don't see debconf-utils in there, could you verify that it is installed on the minion? Could you execute that state on the minion with salt-call -ldebug ?
12:08 simon_c *finally* manged to figure out why my grains we're synching. Once I removed execute permisions from the file, it worked....
12:08 cablekevin babilen: gimme a sec, i'll deploy a new minion
12:10 edrocks joined #salt
12:12 babilen simon_c: grmml, should have mentioned it earlier
12:17 skeezix-hf joined #salt
12:19 numkem joined #salt
12:19 cablekevin Here is the output babilen https://pastebin.com/kwYaCmuQ
12:19 cablekevin I'm baffled why it fails
12:20 babilen https://pastebin.com/raw/kwYaCmuQ (for people who don't like ads)
12:20 cablekevin hehe
12:20 babilen cablekevin: What does "apt-cache policy debconf-utils" give you?
12:21 babilen And what about the "salt-call -ldebug ..." output on the minion?
12:22 babilen Do you have /usr/bin/debconf-set-selections ?
12:22 cablekevin https://pastebin.com/raw/N96cd9Ph
12:22 cablekevin Yep i have that
12:23 babilen Ah, yeah ... so as expected. You are missing "debconf-utils" on the minions. Install it in a state and set reload_modules: True in it
12:23 cablekevin I'll go and check, thanks! (i'll report back once i'm done)
12:23 babilen Also check the value of the "os_family" grain, it should be "Debian"
12:24 babilen Apart from that I can't see anything at the moment
12:24 cablekevin Thnx for the pointers
12:24 nona_ joined #salt
12:24 hemebond left #salt
12:26 babilen cablekevin: https://github.com/saltstack/salt/blob/develop/salt/modules/debconfmod.py#L26-L39 -- is the code that decides if "deconfmod" is available or not
12:26 babilen (i.e. if the salt execution module is loaded)
12:27 babilen The __virtual__ function is typically the first place I check whenever I get a foo is not available error
12:30 simon_c babilen: no worries. I'm sure I originally put the execute permissions on there cos it wasn't synchnig, but that could have been for some other silly reason.
12:34 cablekevin babilen: does salt from apt-get install "debconf-utils" and does the git version of salt doesnt?
12:45 magicmicky joined #salt
12:49 zerocool_ joined #salt
12:49 babilen cablekevin: Quite likely, we have a "salt-minion ? debconf-utils" chain in the Debian packages
12:49 babilen (recommends)
12:50 babilen My suggestion is still to install it explicitly and set "reload_modules: True" in that state
12:50 cablekevin Yeah, we're stuck with the git solution for the moment, some thing are not running smoothly when getting the 2017 of salt.
12:50 zerocoo__ joined #salt
12:51 babilen We're mostly on 2016.11 still
12:53 cablekevin For now the debconf-utils pkg install is sufficient for us now
12:53 cablekevin Thanks for your help babilen! :) much appreciated!
12:54 zerocoo__ joined #salt
12:54 kedare joined #salt
12:54 kedare Hello :)
12:55 kedare Question, what could be the reason for a job to returns : Minion did not return. [No response]
12:55 kedare Is there any kind of timeout ? It’s usually quite long running jobs
12:55 simon_c So, I want to make the default_route, a grain. the data is there in the salt module network.default_route[0]['gateway'], but how do I access that from a custom grain script ?
12:59 simon_c I could use the data in a pillar, (where it seems to be salt.network.,default_route().0.gateway) but I can't seem to use that as a key for a lookup table in jinja. Maybe I can, but I was struggling there too.
13:02 babilen simon_c: You can't use salt execution modules in grains
13:03 babilen https://docs.saltstack.com/en/latest/topics/development/dunder_dictionaries.html
13:03 simon_c babilen: Ahh. that would explain why I have problems trying to use them...
13:03 babilen Grains are quite "low" and used by a lot of other things, like modules
13:03 babilen s/low/low-level/
13:04 simon_c babilen: so is there a better way of using the output of a salt module as a key for a lookup table to set some data in a state ?
13:05 simon_c Ultimatly, I'm trying to identify what subnet a minion is in, to set some locational specific items in various states.
13:06 babilen Do you need data from other minions as well?
13:06 babilen Pillars are perfectly fine for this, but I tend to mostly use the mine for information like these, as I might need it on other minions also
13:07 simon_c babilen: no. I do have some use case for mine, but I wanted to understand the easy stuff first.
13:10 babilen simon_c: This information feels right in grains, but you would have to port the module code to your custom grain in order to make it work
13:11 babilen To me "grains == information *from* the minion" and "pillars == information *for/about/assigned to* the minion"
13:11 XenophonF simon_c: cf. https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#salt.modules.network.in_subnet
13:11 XenophonF you can also do things like using CIDR matches in top.sls
13:11 babilen What are you trying to do in the larger picture?
13:11 babilen Feels a bit like a X/Y Problem
13:12 XenophonF I use CIDR matches in Pillar's top.sls to set different snmpd configs based on location.
13:12 simon_c large picture, port my puppet config to salt :)
13:12 simon_c Smaller picture, I want to set a the resolv.conf name server to be dependent on the subnet a minion is in.
13:13 * XenophonF coughs and it sounds awfully like "DHCP".
13:13 coredumb why do you cough?
13:14 simon_c XenophonF: yeh, but we don't DHCP servers.
13:14 simon_c XenophonF: and it's a pattern that I'll use in other modules too when I figure it out.
13:14 XenophonF understood
13:14 simon_c First tried putting the logic in jinja, but that seemed hard..
13:14 simon_c https://gist.github.com/anonymous/a2039207eec88da9879efc39d4b86715
13:14 XenophonF so let's say you have a file.managed state controlling /etc/resolv.conf
13:14 XenophonF there are tons of different ways you could slice and dice this
13:16 XenophonF you could have jinja in the SLS file that chooses different source files based on the minion's subnet ID
13:16 sh123124213 joined #salt
13:16 XenophonF you could have jinja in the resolv.conf source file
13:16 coredumb you could set them in pillars loaded per "subnet"
13:16 XenophonF you could write different states or different pillars and use CIDR targeting
13:16 coredumb etc etc
13:16 XenophonF yup
13:16 coredumb the list goes on
13:16 coredumb :D
13:17 XenophonF it's probably simplest to just have an if/elif/elif/elif/etc. in the source resolv.conf file
13:17 simon_c My aim is to keep the state jinja files as clean as possible.
13:17 XenophonF then just set template=jinja in the file.managed state
13:17 simon_c I had considered trying to get hiera working as an external pillar, as I have the login in there from my puppet setup. but figured that wasn't the "salt" way to go...
13:17 XenophonF so let's look at your gist
13:18 coredumb XenophonF: been there done that ... gets unreadable quickly the more you grow in subnets
13:18 XenophonF true
13:18 XenophonF same here
13:18 simon_c this jist is in the nameserver.sls pillar,
13:18 babilen Always the case .. easy for 2 or 3, but gets ugly fast
13:19 simon_c I thought the best bet was trying to emulate the pattern used for filter_by_grains, and then use a hash for the lookup, but my jinja looks like a poor imitation of that.
13:19 coredumb simon_c: I personnaly use the pillars method
13:19 XenophonF yeah that's simpler
13:20 simon_c coredumb: pillar per subnet, ?
13:20 coredumb with something like my saltclass module
13:20 coredumb simon_c: yes
13:20 XenophonF so simon_c you can have targets that look like `'S@10.1.0.0/16': [resolv.office-a]`
13:20 simon_c thought about that too, but then DNS data is spread around many files. But it's an option.
13:20 XenophonF and `'S@10.2.0.0/16': [resolv.office-b]`
13:20 XenophonF and so on and so forth
13:21 coredumb like there's a default configuration that can be overriden by subnet datas
13:21 coredumb https://github.com/saltstack/salt/pull/42349/ the module in question if there's any interest :)
13:22 XenophonF and /srv/pillar/resolv/office-a.sls (and friends) can just be something like `{'resolv': {'nameservers': ['10.1.1.100', '10.1.1.200']}}`
13:23 XenophonF and then you can have a state like /srv/salt/resolv/init.sls + template file /srv/salt/resolv/files/resolv.conf (which is how I always lay these things out on the file system)
13:23 simon_c XenophonF: but the 'S:10.2.0.0/16':  etc are in the top.sls ?
13:23 XenophonF yup
13:23 XenophonF /srv/pillar/top.sls
13:24 simon_c XenophonF: right, so it would be
13:24 simon_c S@10.2.0.0/16:
13:24 simon_c - reoslv.office-b
13:24 simon_c - othermod.office-b
13:24 simon_c - etc.office-b
13:24 XenophonF yes you could absolutely do that
13:24 XenophonF or you could condense all of the office-b settings into a single Pillar SLS
13:24 XenophonF whatever makes the most sense
13:25 XenophonF you're going for the principle of least astonishment
13:25 simon_c I want to keep DNS data in the resolv directory, so that the pillar data for a module is where you'd expect to find it.
13:25 XenophonF sure
13:25 XenophonF makes sense
13:25 XenophonF i do it the same way
13:26 XenophonF but the salt state itself, `resolv`, is completely dumb
13:26 simon_c XenophonF: yep
13:26 simon_c XenophonF: if there's more than a loop in my basic states, it's too complex IMHO.
13:26 racooper joined #salt
13:26 XenophonF and the resolv.conf source file is a jinja template that just loops over salt.pillar.get('resolv:nameservers', ['10.0.0.100', '10.0.0.200'])
13:27 XenophonF that's a good rule of thumb
13:27 simon_c {% for nameserver in pillar.dns.servers %}
13:27 XenophonF you could use that too
13:27 XenophonF i prefer to use pillar.get b/c then i can set sensible default values
13:28 simon_c if I need more complex logic, I try to break that out into the init.sls, and have the jinja's dumb.
13:28 XenophonF if you want to clean up whitespace use {%- for ... %} and {%- endfor %}
13:28 simon_c yeh.
13:30 simon_c XenophonF: so for me, I want to set the default values from pillar, at the '*' level, override by subnet, and finally override by specific hostname.
13:30 simon_c I think I can do that now.
13:30 simon_c thanks all.
13:30 XenophonF yup!
13:33 simon_c XenophonF: what are the docs to look at for the 'S@10.2.0.0/16 ' syntax ?
13:33 XenophonF https://docs.saltstack.com/en/latest/ref/states/top.html#advanced-minion-targeting
13:35 cgiroua joined #salt
13:42 simon_c XenophonF: yeh, I can see targetting by grains etc, couldn't see S@ kind of syntax. Tried it and it worked though..
13:43 XenophonF oh
13:43 XenophonF sorry that's the compound match
13:43 XenophonF https://docs.saltstack.com/en/latest/topics/targeting/compound.html
13:43 simon_c ahh.
13:43 simon_c thanks
13:44 XenophonF in top files compound matches are the default
13:48 tapoxi joined #salt
13:51 noobiedubie joined #salt
13:54 kedare Question about the Slack engine : https://docs.saltstack.com/en/latest/ref/engines/all/salt.engines.slack.html
13:54 kedare How do I specify a target on the commands I’m sending ?
13:55 kedare For example !test.ping works fine, but I tried : test.ping “my-host” and it doesn’t work
13:56 kedare Ok nothing I found :)
13:56 kedare Like !test.ping target=xxx
13:57 v0rtex joined #salt
13:57 spiette joined #salt
14:03 tapoxi joined #salt
14:08 ssplatt joined #salt
14:16 ashmckenzie joined #salt
14:34 jtb Hello, I've got a problem where salt doubles my backslash from a pillar
14:34 jtb https://pastebin.com/vFchaSSA
14:35 jtb anyone had this problem earlier ?
14:35 Kelsar joined #salt
14:40 darioleidi joined #salt
14:56 izrail hi
14:57 izrail i created a custom module, but i am not able to use it ...
14:57 izrail i created the module in /srv/salt/_modules
14:57 izrail and called salt * saltutil.sync_all
14:58 izrail but, the module doesn't even show up on the minion under /var/cache/salt/minion/extmods
14:58 izrail any help? :)
14:59 simon_c izrail: does it show up under /var/cache/salt/minion/files/[environment]/_modules/
15:00 izrail no, it doesn't
15:00 simon_c what's the permissions of the file on the master ?
15:00 izrail root:root rw-r-r
15:01 izrail in the master conf i already tried to set "extension_modules: /srv/salt/_modules"
15:01 simon_c izrail: ahh. not the issue I ran into this morning (didn't sync if it had execute permissions on it)
15:01 izrail but still nothing
15:02 izrail oh, still an important info! :)
15:02 simon_c izrail: anything helpful in the master or minion logs ?
15:02 sarcasticadmin joined #salt
15:03 _JZ_ joined #salt
15:03 Brew joined #salt
15:08 PsionTheory joined #salt
15:08 izrail hmmm
15:09 izrail Rendering SLS 'network' failed, render error: Jinja variable 'salt.utils.templates.AliasedLoader object' has no attribute 'includeAll'
15:09 izrail includeAll is my module
15:10 simon_c izrail: not sure (I'm still learning) . My setup would sync a 0 size file once I had the permissions right....
15:11 izrail oh, doesn't sound right either :)
15:12 jtb for my problem earlier, solved it with replace
15:12 jtb {% if args.logformat is defined -%}LogFormat {{ args.logformat|replace('\\\\','\\') }}{% endif %}
15:16 preludedrew joined #salt
15:16 Heartsbane joined #salt
15:16 Heartsbane joined #salt
15:31 evle1 joined #salt
15:35 heaje joined #salt
15:39 simon_c left #salt
15:42 fatal_exception joined #salt
15:45 iggy izrail: on the minion try `salt-call -l debug saltutil.sync_all` and see if you see anything out of the ordinary
15:57 onlyanegg joined #salt
16:00 fritz09 joined #salt
16:03 patrek joined #salt
16:04 sgo_ joined #salt
16:05 whytewolf izrail: what is your file_root setting on you master? and when you did the saltutil.sync_all was your module listed
16:19 o1e9 joined #salt
16:20 nixjdm joined #salt
16:25 Edgan joined #salt
16:29 Inveracity joined #salt
16:34 ChubYann joined #salt
16:34 Edgan joined #salt
16:37 wendall911 joined #salt
16:40 usernkey joined #salt
16:41 shanth___ joined #salt
16:42 iggy there's also cp.list_master | grep <modulename>
16:42 shanth___ im trying to insert an ip into a text file using grains - IP is {{ grains['ip_interfaces']['vlan60'] }} but it's returning it like this IP is ['10.10.60.110']
16:42 shanth___ i want it without the brackets and quotes
16:44 smartalek It's in list form. You can use jinja's 'join' to get it into a string.
16:44 whytewolf shanth___: grains['ip_interfaces']['vlan60'][0] or grains['ip_interfaces']['vlan60']|first
16:45 shanth___ should it be in list form when there is only one result?
16:45 whytewolf shanth___: yes
16:45 shanth___ interesitng
16:45 shanth___ thanks whytewolf
16:45 smartalek shanth___: yes. And follow whytewolf's example. Way better since you just want the one result.
16:46 shanth___ works great now
16:48 amiskell joined #salt
16:52 sturlik joined #salt
16:53 overyander joined #salt
16:54 sturlik Maybe someone can help, currently writing custom salt state module. And would like to find out how to get job id in module
16:58 hoonetorg joined #salt
17:00 ahrs joined #salt
17:01 impi joined #salt
17:12 snc joined #salt
17:14 XenophonF sturlik: is that even possible, since state functions run on the minion (not the master)?
17:15 Edgan joined #salt
17:15 whytewolf n thoery it should be, minion should be aware of the jid
17:15 whytewolf just not sure of the function call to do it
17:16 whytewolf or what good it would do on a minion
17:16 izrail iggy, whytewolf got it synced to the minions now ... i put it in /srv/salt/_modules, but my file_roots was /srv/salt/state
17:16 izrail it is now listed in the output, and i can call it using "salt '*' module.function"
17:17 izrail but ... should i be able to call the module from within a pillar? this still does not work ...
17:18 sturlik XenophonF, for now I got to point that I can run `salt-call saltutil.running` and get current running jobs and on point of time on one job with applying state can be running so we can find current job id
17:18 sturlik But I think there maybe another good way to find jid
17:19 XenophonF the source for saltutil.running seems like the obvious place to check
17:21 LeProvokateur joined #salt
17:27 ssplatt joined #salt
17:32 sgo_ joined #salt
17:36 nixjdm joined #salt
17:38 stevednd anyone know of a way to get a definitive list of minions based on a pillar or grain matcher? Regardless of whether the minion is up, down, or non-responsive?
17:38 high_fiver joined #salt
17:39 stevednd it might be because I was on an older version, but I will have times where some minions will not respond. I know they're there, and should be responding, but in terms of output there's no record of their existence.
17:39 _KaszpiR_ joined #salt
17:48 onlyanegg joined #salt
17:57 LeProvokateur joined #salt
17:58 whytewolf only way to get a list of minions is using a runner manage.status which will give the up/down status of all minions. or using the wheel [or salt-key]
17:59 whytewolf manage.status does accept tgt and tgt_type
18:00 cyborg-one joined #salt
18:08 noobiedubie joined #salt
18:08 Deliant joined #salt
18:18 brianthelion joined #salt
18:18 usernkey joined #salt
18:19 noraatepernos joined #salt
18:20 saltysalty joined #salt
18:23 Brew joined #salt
18:24 sp0097 joined #salt
18:26 sp0097 left #salt
18:26 iggy izrail: no, because pillars are rendered on the master
18:26 Lionel_Debroux_ joined #salt
18:28 Ni3mm4nd joined #salt
18:29 XenophonF the docs need a proper block diagram showing the order of operations at a high level
18:30 XenophonF lot of people get stuck on what happens where and when
18:30 whytewolf that block diagram would have a lot of blocks that connect to nothing because they are different processes that happen at different times compleatly indapendent of what you do
18:31 XenophonF true
18:33 whytewolf would also need a few. one discribing typicall master/minion one that describes masterless and one that describes the odd balls. like salt-ssh and salt-cloud
18:33 iggy yeah, it can take a little while to get your head wrapped around what's what
18:35 nixjdm joined #salt
18:36 rathier joined #salt
18:39 tacoboy joined #salt
18:39 astronouth7303 XenophonF: i know that feel
18:39 astronouth7303 you figure it out eventually, but yeah
18:40 coredumb when you hit the sls injections it gets funky ^^
18:41 whytewolf sls injections?
18:41 whytewolf never heard that one before
18:42 XenophonF this is one of my favorite explications of different "times": https://groups.google.com/forum/#!msg/comp.lang.lisp/n5mNoooaXZM/we_APC8lzxIJ
18:42 XenophonF in Salt parlance, there's Pillar render time (at the master) and State render time (on the minion) and State execution time (also on the minion)
18:46 whytewolf well, it can get more complex then that if you need minedata but in essence yeah.
18:55 astronouth7303 ... `webhook_disable_auth` isn't working?
18:55 kikikarabi joined #salt
19:35 nixjdm joined #salt
19:42 drawsmcgraw joined #salt
20:09 colabeer joined #salt
20:10 aldevar1 joined #salt
20:13 aldevar2 joined #salt
20:13 breadmerchant joined #salt
20:27 jhauser joined #salt
20:37 nixjdm joined #salt
20:37 brianthelion joined #salt
20:43 Hybrid joined #salt
20:44 high_fiver joined #salt
20:47 onlyanegg joined #salt
20:56 JPT joined #salt
20:57 sturlik joined #salt
21:03 Hybrid joined #salt
21:05 Ni3mm4nd joined #salt
21:16 colabeer joined #salt
21:16 socket-_ hey all, I'm using the bootstrap-salt.sh script hosted on the saltstack github page. It looks like I can pass a json dict file to overwrite the default minion config. I'm having troubling finding an example of one of these, can anyone share a link with an example of this custom config?
21:19 socket-_ -j Replace the Minion config file with data passed in as a JSON string
21:23 whytewolf socket-_: don't think it is too complicated. as it is pretty standard json string {"master": "master address"} or if you needed a list of masters {"master": ["master_addr_1","master_addr_2"]} and just add items as needed.
21:23 whytewolf and just put in options you need to change the default for
21:24 whytewolf you could also build a yaml and convert that to json
21:28 socket-_ ok so it would be like curl -O http://s3-configs/custom_minion.json ; curl http://github/bootstrap | bash -j custom_minion.json
21:29 socket-_ and then upload custom_minion.json to have the single change from the default file.. EG: {"log_level_logfile": "debug"}
21:30 whytewolf just craft the json the way you want from the begining. don't try doing a compare. honestly make it as minimal as you can and use salt to change it after the fact.
21:31 stevednd whytewolf:  is `require` in orchestration not the same as states?
21:32 whytewolf depends on what you mean by the require in orchestration.
21:32 stevednd I have a salt.state: that has a require on a previous state, and while the previous state runs, the other state kicks off, and then fails because the original state is still running
21:32 whytewolf it shouldn't do that.
21:33 stevednd https://gist.github.com/dnd/c8326ab0a5648a0ad6999204f96aa372
21:34 stevednd I'm pretty sure there's nothing dumb in there
21:34 stevednd but maybe you can spot something I'm not seeing
21:35 stevednd basically deploy-app starts running while migrate-db is still working
21:37 nixjdm joined #salt
21:37 whytewolf i don't see a problem with it. i would file a bug report cause it really should wait for migrate-db to finish. only thing i can think of is the - throwing it off but it should throw an error for that
21:37 stevednd whytewolf: what's interesting is that it's not started immediately after. There's maybe a 10-15 second delay
21:38 stevednd which -?
21:38 stevednd do you mean in the state name?
21:38 whytewolf yeah
21:39 whytewolf but like i said that would be throwing an error if that was the issue
21:40 stevednd bummer, guess I will file a bug then
21:40 stevednd do whiteinge and basepi hang out in here anymore at all?
21:41 whytewolf basepi is here in spirt only and i see whiteinge every now and then
21:42 stevednd okay, thanks
21:44 socket-_ I'm getting json malformed errors with the custom json, any ideas?  http://apaste.info/3oBe
21:47 whytewolf you sure that takes a file and not say. the json string
21:50 whytewolf aka bash bootstrap-salt.sh -j '{"log_level": "info"}'
21:51 whytewolf [although with that config i hope your master exists at salt.<search domain>
21:51 socket-_ great, that worked, thanks for the clarification
21:51 socket-_ yeah the master ie reachable via salt
21:52 whytewolf also, why are you going that deep instead of say using saltify from salt-cloud?
21:52 whytewolf just wondering
21:56 socket-_ never heard of saltify, looking at it now
21:58 socket-_ basicaly i create AMI's every night with a patched OS from cloudinit, then add an rc.local with a snippit of code to ensure that the machine has the latest version of saltstack running each boot. I would like to have logs of the initial highstate, but i wanted to capture it in warning instead of info log level
21:59 socket-_ so, all I should need to do is modify my AMI bootstrap script to do the curl, then pass the json string with -j
22:01 socket-_ not sure how i would tell saltify when a new AMI is created.
22:01 whytewolf well, you wouldn't put salt in the ami when using salttify.
22:02 whytewolf not sure how you are getting around key generation with that setup to begin with]
22:02 socket-_ yeah, i don't have salt in the AMI now, I have logic to install salt in the AMI on first boot
22:02 socket-_ and then reactors in place to accept minion based on data requirments
22:03 noraatepernos joined #salt
22:04 whytewolf since saltify is a cloud item you can use the cloud settings to trigger it. how are you launching the instances now? boto_*? salt-cloud [in which case it auto does the saltify step anyway]
22:05 whytewolf anyway. i was just wondering not saying you were going about it wrong and not to work with what you got
22:06 socket-_ well, these AMI's are shared with our customers, and whenever they launch an instance in our environment, the minion makes a request to salt.searchdomain, and we accept the minion and make sure it's got our CM
22:06 whytewolf ahhh so you have process outside of salt launching the instances. in that case yeah you are best with how you are going about it
22:06 socket-_ here is the bootstrap I'm currently using, it's a little ugly, but it seems to work for ubuntu/centos/amazonlinux/fedora  http://apaste.info/4onl
22:07 socket-_ yah
22:08 onlyanegg joined #salt
22:09 whytewolf develop version of bootstrap? humm. i would fork that and use one that you have compleate control over the updates of. that way you don't get caught by surprises in changes
22:11 socket-_ yeah, i was torn on that, i do the same thing for windows
22:11 whytewolf or if say someone grabs control of the saltstack repo and puts a trojan in the bootstrap.
22:11 whytewolf also might want to lock down the version. that it is installing instead of just going with "stable"
22:12 whytewolf lots of pain comes when the minion installed is higher version then the master in a lot of cases
22:12 socket-_ whytewolf: yeah, i'll probably clone it to our internal repo, and setup something for scheduled sync with qa testing and security approval, but thats just how it is at the moment ;)
22:13 whytewolf other wise it isn't the worst cloud-init user script i have seen
22:14 socket-_ lol thanks
22:15 socket-_ good idea on the minion version lock down, i'v heard that can be troublesome.
22:16 basepi stevednd: whytewolf: I LIVE
22:16 basepi But yeah, mostly in spirit. :)
22:17 onlyanegg joined #salt
22:21 LeProvokateur joined #salt
22:22 whytewolf yay!
22:33 keldwud joined #salt
22:33 keldwud joined #salt
22:35 nixjdm joined #salt
22:42 ssplatt joined #salt
23:19 cliluw joined #salt
23:21 Deliant joined #salt
23:33 hemebond joined #salt
23:35 nixjdm joined #salt
23:36 pabloh007fcb joined #salt
23:39 pabloh007fcb hey everyone having some problems with salt state for docker_network.present
23:41 pabloh007fcb https://gist.github.com/pabloh007/df28da12c0f3e1dec9b01d7843dd25c5 I get this error and it seems to reference the last container on the list all the time  Failed to connect container '79ffb6c918df5f4' to network 'devnetwork' Error 500: {"message":"endpoint with name web_service already exists in network devnetwork"}
23:44 pabloh007fcb joined #salt

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