Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2016-01-19

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

All times shown according to UTC.

Time Nick Message
00:02 calculon joined #salt
00:03 cedwards joined #salt
00:05 justanotheruser joined #salt
00:08 hal58th_ joined #salt
00:20 yuhlw joined #salt
00:22 oida joined #salt
00:34 digitalhero joined #salt
00:36 bhosmer_ joined #salt
00:38 ageorgop joined #salt
00:41 brianfeister joined #salt
00:45 CheKoLyN joined #salt
00:56 yuhlw joined #salt
01:02 digitalhero joined #salt
01:04 jeddi joined #salt
01:08 rocket joined #salt
01:19 zmalone joined #salt
01:21 yuhlw joined #salt
01:24 hasues joined #salt
01:25 hasues left #salt
01:30 zmalone joined #salt
01:31 malinoff joined #salt
01:32 malinoff joined #salt
01:35 zmalone1 joined #salt
01:36 tmclaugh[work] joined #salt
01:45 lompik joined #salt
01:48 digitalhero joined #salt
01:48 blckbit10 joined #salt
02:09 rem5 joined #salt
02:12 yuhlw joined #salt
02:13 XenophonF where can i find this mythical xml_badgerfish renderer for salt?
02:17 donmichelangelo joined #salt
02:18 otter768 joined #salt
02:24 bhosmer_ joined #salt
02:27 XenophonF https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#sane-defaults
02:27 XenophonF just noticed that the state in question is file.serialize
02:28 XenophonF https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.serialize
02:29 XenophonF and i found xmljson
02:29 XenophonF https://pypi.python.org/pypi/xmljson
02:30 XenophonF brb gonna rtfs of salt.states.file
02:37 XenophonF man, this reference to an xml_badgerfish is so tantalizing
02:39 XenophonF the list of valid formatters is hard-coded in serialize()
02:39 XenophonF but it doesn't look like patching in a new format is difficult
02:43 dimeshake joined #salt
02:47 catpigger joined #salt
02:50 yuhlw joined #salt
02:50 brianfeister joined #salt
02:53 digitalhero joined #salt
02:56 jimklo joined #salt
03:00 otter768 joined #salt
03:03 jimklo joined #salt
03:11 yuhlw joined #salt
03:16 anotherZero joined #salt
03:17 evle joined #salt
03:18 rem5 joined #salt
03:18 bhosmer joined #salt
03:18 digitalhero joined #salt
03:19 yuhlw joined #salt
03:25 racooper joined #salt
03:31 yuhlw joined #salt
03:31 jimklo joined #salt
03:34 cedwards left #salt
03:42 Tyrm joined #salt
03:48 k_sze[work] joined #salt
03:51 favadi joined #salt
03:52 jimklo joined #salt
03:58 anotherZero joined #salt
04:03 yuhlw joined #salt
04:03 jimklo joined #salt
04:12 bhosmer joined #salt
04:14 Tyrm joined #salt
04:14 rem5 joined #salt
04:18 ramteid joined #salt
04:24 nethershaw joined #salt
04:25 neogenix joined #salt
04:26 anotherZero joined #salt
04:30 malinoff joined #salt
04:39 yuhlw joined #salt
04:40 jimklo joined #salt
04:43 brianfeister joined #salt
04:45 jimklo joined #salt
04:49 Pie_Mage i wrote a function to generate some salt id functions in python, to use the py renderer
04:50 Pie_Mage and I can't seem to import it
04:51 Pie_Mage I tried 'import sls_func', and it says that the module isn't there... thoughts?
04:51 Pie_Mage (sls_func is the name of the generator module)
04:52 geekatcmu importing of Python code has to be in the PYTHONPATH.
04:52 geekatcmu or sys.path
04:54 geekatcmu However, you can fake it.  At least with pyobjects, if you put the functions/classes you want into, e.g. map.sls, you can "import salt://states/base/map.sls" and it'll be pulled in
04:55 cyborglone joined #salt
04:56 jimklo_ joined #salt
04:56 Pie_Mage that's kinda cool
04:56 Pie_Mage I think you've put me on a path! (no pun intended)
04:56 Pie_Mage thanks geekatcmu
04:59 yuhlw joined #salt
05:02 geekatcmu I'm kind of hooked on the whole object-oriented programming thing (been doing Python for <mumble> years), so I love whipping up convenience objects and throwing them into various places.
05:03 geekatcmu If more of my team were pythonistas, I'd probably put together a library of re-usable classes that could then make composing states much easier.
05:03 jimklo joined #salt
05:04 geekatcmu For instance, we have a "java" directory.  It contains states for 7 different JDKs, each of which differ from each other by 3 bytes, because Jinja.
05:08 pcn We started with a convention of "role" states that compose other states that actually do heavy lifting.
05:09 pcn So the role becomes an API that selects an appropriate state to implement e.g. cassandra version based on the pillars that are defined for the node in question.
05:09 jimklo joined #salt
05:10 Bryson joined #salt
05:14 geekatcmu yeah, we do that.
05:14 geekatcmu But sometimes it's hard to avoid amazing amounts of copy-paste
05:15 geekatcmu Particularly when versioning is involved.
05:15 geekatcmu And we've got some systems that absolutely require 4 different JDKs to be installed.  Yes, that's every bit as crazy as it sounds.
05:23 jimklo joined #salt
05:24 wangofett joined #salt
05:25 yuhlw joined #salt
05:29 impi joined #salt
05:34 wangofett joined #salt
05:35 neogenix joined #salt
05:36 jimklo_ joined #salt
05:37 rdas joined #salt
05:50 jimklo joined #salt
05:50 pwalsh joined #salt
05:56 jimklo joined #salt
05:59 linjan joined #salt
06:00 wangofett joined #salt
06:00 bhosmer_ joined #salt
06:02 tristianc joined #salt
06:05 pcn sounds lik you can get some docker in tereh
06:07 jimklo joined #salt
06:32 brianfeister joined #salt
06:32 DanyC joined #salt
06:34 DanyC hi all, if i have defined a jinja variable on /srv/salt/kibana/init.sls is it possible to import it into /srb/salt/kibana/etc/foo.sls ?
06:35 lompik joined #salt
06:37 yuhlw joined #salt
06:43 XenophonF yes
06:44 DanyC XenophonF: thank you for reply. So if i have in init.sls defined {% set kibana_version = pillar['service-kibana']['version'].split('-')[0] -%} how would i import it into foo.sls ? (only this variable)
06:46 DanyC XenophonF: cause i've seen this https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html but that import the whole init.sls in my case which i'd like to avoid
06:47 neogenix joined #salt
06:54 DanyC i found it, thx
06:55 brianfeister joined #salt
06:57 calvinh joined #salt
06:59 rdas joined #salt
07:00 cberndt joined #salt
07:02 DanyC joined #salt
07:04 Garo_ I'm writing my own state module with python and I would need to also call other states (mount.mounted mainly) from that state. Is there a proper way to do that?
07:10 digitalhero joined #salt
07:15 yuhlw joined #salt
07:17 MTecknology iggy: HAPPY BIRTHDAY!
07:17 * MTecknology hands out spankings for the channel to use.
07:21 CustosLimen joined #salt
07:21 XenophonF heh
07:26 dariusjs joined #salt
07:30 Rumbles joined #salt
07:31 wangofett joined #salt
07:31 k_sze[work] joined #salt
07:36 pwalsh joined #salt
07:37 pwalsh joined #salt
07:39 otter768 joined #salt
07:47 blckbit10 joined #salt
07:49 bhosmer joined #salt
07:52 NV joined #salt
07:53 federicob joined #salt
07:55 dariusjs joined #salt
07:59 sectionme joined #salt
08:00 robbbb joined #salt
08:01 robbbb What's the best way to deploy a unique id to a file on different servers?
08:03 robbbb My current solution would be a pillar that looks like this: http://pastebin.com/Qp5Liv32 any better ideas?
08:04 linjan joined #salt
08:04 robbbb And use the value in a statefile like this: mesos['uuid']{{ grains['host'] }}
08:05 dariusjs joined #salt
08:08 jeddi I'm getting lsb_distrib_codename reporting one of my Debian jessie (8.2) boxes as 'sid' (which is the unstable branch).   Any hints on where to start investigating why this thinks this way?
08:09 robbbb jeddi: I'd do a naive: grep -rIs sid /etc
08:11 jeddi robbbb: good call .. /etc/debian_version contains "stretch/sid".  Stretch is current testing, I believe.
08:12 jeddi robbbb: hmm .. so something's gone whacky somewhere in the history of this VM.   oh well.
08:16 ITChap joined #salt
08:16 dgutu joined #salt
08:17 freeaks joined #salt
08:18 KermitTheFragger joined #salt
08:21 Guest95345 joined #salt
08:25 dariusjs joined #salt
08:27 AlberTUX1 joined #salt
08:39 GreatSnoopy joined #salt
08:40 netcho joined #salt
08:41 Grokzen joined #salt
08:43 pwalsh joined #salt
08:44 bhosmer joined #salt
08:44 pwalsh joined #salt
08:56 Rumbles joined #salt
08:57 kawa2014 joined #salt
09:02 XenophonF robbbb: the way i tend to do things like that is to have separate pillar files, each containing the same key but having different values
09:05 XenophonF e.g., in host1.sls i'd have {mesos: {uuid: 1}}, in host2.sls i'd have {mesos: {uuid: 2}}, and so on
09:06 XenophonF then in the corresponding state, i'd refer to the mesos:uuid pillar key only
09:07 XenophonF then in the pillar top.sls, assign the various host*.sls files to the appropriate minions
09:07 XenophonF i'm not sure i have a good example in my public configs, but let me check
09:10 XenophonF this is probably the closest to your use case - https://github.com/irtnog/salt-states/blob/development/postfix/pillar.example#L35
09:10 XenophonF my postfix formula doesn't need to know whether it's applying the config for mx1.irtnog.org or mx2.irtnog.org
09:11 XenophonF because pillar takes care of the distinction
09:12 ingslovak joined #salt
09:13 keimlink joined #salt
09:15 dariusjs joined #salt
09:16 rotbeard joined #salt
09:20 CeBe joined #salt
09:23 Hydrosine Hi, does anyone have a way to discover which interface is in an internal network through grains? i need as result ethX based on if it is in 192.168.0.0/16
09:26 opdude @hydrosine: That sounds like you want to make a custom grain https://docs.saltstack.com/en/latest/topics/targeting/grains.html#loading-custom-grains
09:26 Xevian joined #salt
09:28 Hydrosine opdude, the data is already there. 'grains.get ipv4_interfaces' now i want it to only return the internal interface
09:29 opdude but i mean you can use that grain info to make another grain that includes only the internal interfaces :)
09:29 opdude another option would be to just loop through the interfaces looking for something in that range but that might be a bit harder in jinja
09:30 slav0nic joined #salt
09:32 s_kunk joined #salt
09:32 s_kunk joined #salt
09:33 Hydrosine hmm i can work with that
09:37 av_ joined #salt
09:37 chiui joined #salt
09:37 robbbb XenophonF: Thanks! Looks like you're doing the same thing as me but in a different way.
09:37 bhosmer joined #salt
09:38 yannis joined #salt
09:40 larsfronius joined #salt
09:40 otter768 joined #salt
09:41 yannis hey everyone :) I'm trying to use a standalone minion and therefore have removed the "master:" property in its config, and done the things described in https://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html . However the minion repeatedly tries to authenticate with a master and throws "SaltClientError: Attempt to authenticate with the salt master failed"
09:43 larsfron_ joined #salt
09:44 dariusjs joined #salt
09:46 ITChap joined #salt
09:48 colegatron joined #salt
09:48 cberndt joined #salt
09:54 LondonAppDev joined #salt
09:57 kawa2014 joined #salt
10:32 bhosmer joined #salt
10:34 impi joined #salt
10:39 N-Mi are there any existing formula or state to configure systemd's journald.conf ?
10:41 babilen N-Mi: Not aware of any, but that doesn't mean that they don't exist
10:50 giantlock joined #salt
10:54 inmediaref joined #salt
10:55 dariusjs joined #salt
10:56 amcorreia joined #salt
10:56 blckbit10 joined #salt
10:56 N-Mi babilen: ok thx
10:58 denys joined #salt
11:10 aron_kexp joined #salt
11:14 dariusjs joined #salt
11:24 XqueZme joined #salt
11:25 XqueZme Hi all. I was wondering what do you guys use to test .sls or grains, etc. A dedicated environment or some other approach?
11:26 bhosmer joined #salt
11:30 slav0nic joined #salt
11:30 Grokzen joined #salt
11:30 joyrida08 joined #salt
11:41 otter768 joined #salt
11:44 dariusjs joined #salt
11:44 pkimber joined #salt
11:47 Rumbles joined #salt
11:48 wangofett joined #salt
11:51 babilen XqueZme: I develop them locally in Vagrant, push them upstream into git in a qa branch. If that goes well it is being merged into prod. Separate masters for both sets of minions (qa/prod)
11:54 XqueZme babilen: thanks for info. That means your Vagrant is a salt master and you have a test minion for testing it or any otherway? Currenty I'm adding files on salt-master and using state.sls to test them, but it seems akward to modify salt-master files directly.
11:56 babilen XqueZme: Yeah, I typically have a master and as many minions as the environment I'm modelling. I use landrush and ".test" as TLD on which I match to differentiate between "production/qa" and "vagrant testing"
12:00 XqueZme babilen: I see. Thanks. I'm new to salt and thought about running testing environment by using salt's ssh, and once that worked I would commit and push to qa/prod branches.
12:01 dariusjs joined #salt
12:04 babilen XqueZme: Not sure what salt-ssh buys you in this context, could you elaborate on that?
12:07 XqueZme babilen, you're right, does not buy me anything really since I still need to accept keys, etc. So I guess local master/minion will do the trick.
12:08 rm_jorge joined #salt
12:08 CeBe joined #salt
12:11 rominf joined #salt
12:12 rominf Are there any options to debug top.sls compilation on state.highstate execution?
12:17 neogenix joined #salt
12:18 AndreasLutro rominf: state.show_top maybe?
12:20 bhosmer_ joined #salt
12:30 rominf AndreasLutro: Thank you, this function helped me! I wish this function to show all states that are included via include recursively.
12:38 evle1 joined #salt
12:38 Rumbles joined #salt
12:40 fredvd joined #salt
12:42 AndreasLutro state.show_highstate is the closest you'll get to that
12:42 AndreasLutro or just state.highstate test=True
12:47 dariusjs joined #salt
13:01 digitalhero joined #salt
13:02 rominf AndreasLutro: state.show_highstate is better for debugging, than state.highstate test=True, because it shows filename as __sls__ value. Combination of state.show_top and state.show_highstate helped me to deduce, that the problem is include expression.
13:03 Rumbles joined #salt
13:03 MikeyYeahYeah joined #salt
13:17 cliluw joined #salt
13:18 wangofett joined #salt
13:22 tmclaugh[work] joined #salt
13:27 denys joined #salt
13:31 justanotheruser joined #salt
13:35 numkem joined #salt
13:39 dendazen joined #salt
13:40 rubendv joined #salt
13:42 otter768 joined #salt
13:50 subsignal joined #salt
14:02 gh34 joined #salt
14:05 racooper joined #salt
14:08 drawsmcgraw joined #salt
14:09 jav joined #salt
14:11 fxhp joined #salt
14:11 Rumbles joined #salt
14:14 numkem joined #salt
14:14 writtenoff joined #salt
14:19 anmol joined #salt
14:20 Tyrm joined #salt
14:22 pwalsh joined #salt
14:22 wangofett joined #salt
14:24 tmclaugh[work] joined #salt
14:25 drawsmcgraw joined #salt
14:26 rem5 joined #salt
14:28 mapu joined #salt
14:28 spaceSub I have multiple states depending on one repo beeing installed. How should I manage that?
14:29 spaceSub Right now I have a repos/whatever.sls and require that, wherever I need the repo. Is that a bad idea?
14:31 cpowell joined #salt
14:32 XenophonF spaceSub: i used to do things like that
14:33 XenophonF i changed my mind a while back
14:33 XenophonF now, i have a separate top-level SLS for my repo config: poudriere.client
14:34 XenophonF and i make sure that in each of my environments, it's one of the first SLSes assigned to my FreeBSD minions
14:35 XenophonF later states that make use of pkg.installed or pkg.latest do not include dependencies on any of the states in the poudriere.client SLS
14:35 XenophonF i did this because managing the dependencies across all of my states got to be too difficult
14:36 spaceSub And you just install the repos on all of your minions, no matter if they need them?
14:36 pwalsh joined #salt
14:36 bhosmer joined #salt
14:36 malinoff joined #salt
14:36 _JZ_ joined #salt
14:36 XenophonF esp. since i wanted to use the same states on different versions of Unix or different Linux distributions
14:36 XenophonF more like, i try to keep top-level SLSes self-contained
14:37 XenophonF and i don't (usually) have dependencies between them
14:37 mpanetta joined #salt
14:37 XenophonF instead i order things in top.sls
14:38 XenophonF if there was a specific repo that only a few minions needed, i'd create a top-level SLS for that
14:38 slav0nic joined #salt
14:38 XenophonF and i'd make sure that SLS got assigned in top.sls before any other SLSes that might use it
14:38 XenophonF here's what my top.sls looks like - https://github.com/irtnog/salt-states/blob/master/top.sls
14:39 XenophonF note lines 87 and 124-126
14:40 XenophonF those SLSes configure package repos for FreeBSD and RHEL respectively
14:40 spaceSub I'm so confused about when I can depend on states beeing executed as I write them.. Ughs. Salt is giving me existential crisis.
14:40 XenophonF let me back up
14:40 XenophonF when i add dependency info to a state, i only refer to other states within that SLS
14:40 XenophonF so like, if i have /usr/local/etc/salt/states/postfix/init.sls
14:41 XenophonF any requisites listed in that SLS file only refer to other states within that SLS file
14:42 XenophonF i don't create requisites referring to states outside of that folder
14:42 spaceSub never/
14:42 spaceSub ?
14:42 XenophonF well, if not "never", then "almost never"
14:42 spaceSub fair enough.
14:43 spaceSub Hmm, okay. I will try to stick to that idea.
14:43 spaceSub Thanks.
14:44 XenophonF here's a better example
14:44 XenophonF amavisd-new and clamav inter-operate
14:44 XenophonF so I have a top-level SLS named "amavisd" and another named "clamav"
14:45 dendazen joined #salt
14:45 XenophonF because i want to be able to install/manage one without installing/managing the other
14:45 XenophonF in a very specific instance i need to glue them together
14:45 spaceSub Sounds like you have just given up managing dependecies all together :P
14:45 XenophonF so I have a clamav.amavisd state
14:45 Tanta joined #salt
14:46 spaceSub Like do you really sometimes only use one and not the other?
14:46 XenophonF yes
14:46 spaceSub Hmm, okay.
14:46 XenophonF if i used them together always, i would just combine them into one top-level SLS
14:46 spaceSub I see.
14:46 spiette joined #salt
14:46 XenophonF i still use dependencies, just within top-level SLSes, not across them
14:47 XenophonF and here's part of the reason why
14:47 lothiraldan joined #salt
14:47 XenophonF it's awfully convenient to be able to run "salt-call state.sls amavisd" to apply a new config
14:47 teryx510 joined #salt
14:47 XenophonF instead of having to run a highstate
14:48 XenophonF b/c i have 100+ states that run, which complicates debugging
14:48 spaceSub Very good point.
14:48 spaceSub I think I need to get that salt doc out of my head. Everything just yells in me, that I have to make everything perfectly reusable which feels like writing tons and tons of boilerplate nobody will ever use anyway.
14:49 XenophonF if the amavisd SLS included dependencies on other SLSes, i'd have to reference them all in that state.sls command
14:49 XenophonF definitely!
14:49 XenophonF KISS
14:49 XenophonF keep it simple
14:49 spaceSub Salt feels like everything but.
14:49 spaceSub Having the state the grains and the pillar.
14:49 XenophonF states only need to be re-usable when you're going to re-use them, right?
14:50 XenophonF those are all really useful facilities but they aren't appropriate to every task always
14:50 spaceSub Yeah, that's pretty much what I realised now.
14:50 XenophonF sometimes, you just want to stick a file on every server and be done with it
14:51 spaceSub I mean I spend the last hour reading the salt formular to manage salt itself. I'm not sure it's really wort it having such a complicated formular which somebody needs to fully understand and keep up to date, when I only have like two different setups.
14:51 XenophonF oh sure!
14:51 XenophonF and i say that as someone who relies on salt-formula
14:52 LondonAppDev Do you guys typically store all your salt states in one git repo, and then clone that to /srv/salt ?
14:52 spaceSub Your setup looks pretty advanced though :D
14:52 XenophonF hah well it didn't start out that way!
14:52 drawsmcgraw LondonAppDev: I use the GitFS backend
14:52 XenophonF i started out just pushing some files to all my servers :)
14:53 XenophonF LondonAppDev: i too use the gitfs backend
14:53 LondonAppDev Oh cool.
14:53 LondonAppDev *googles it*
14:53 impi joined #salt
14:54 LondonAppDev Thanks drawsmcgraw and XenophonF... Looks like gitfs is the way forward.
14:56 hasues joined #salt
14:57 XenophonF spaceSub: my advice is to keep things simple, especially starting out
14:58 XenophonF only use requisites within a SLS
14:58 spaceSub Probably the best advice yet.
14:58 XenophonF rely on top.sls to order SLSes
14:58 mephx joined #salt
14:58 XenophonF i usually write one SLS per service or component
14:59 DammitJim joined #salt
14:59 XenophonF e.g., i have a mail relay, but i have SLSes for postfix, amavisd-new, and clamav
14:59 XenophonF e.g., i have a web app server, but i have SLSes for apache, php, and the app itself
15:00 XenophonF you can see from my github repo how i have things organized
15:01 XenophonF i'll admit that these are styllistic choices and that salt's flexible enough to accomodate other ways to manage configuration state
15:02 andrew_v joined #salt
15:02 spaceSub Doesn't the mail realy and the postfix overlap config wise?
15:03 dariusjs joined #salt
15:03 XenophonF it can
15:03 XenophonF i used to have two configs - a mail relay config and a generic client MTA config
15:04 spaceSub Hmm, doesn't that mean that salt tells you that things have changed on highstate all the time?
15:04 XenophonF a while back i realized that they both did a lot of the same things
15:04 XenophonF so i combined them into one
15:04 XenophonF and then i use pillar data to configure minions that use the postfix SLS
15:04 XenophonF not really
15:05 XenophonF if i were to run a highstate on my mail relays right now, they ought to show no (0) changes
15:06 kaptk2 joined #salt
15:07 oida joined #salt
15:07 FreeSpencer Using salt.client.Caller I thought I remembered you could set it to not connect to the master, but I can't find it now. Is that true or am I just imaging it
15:08 spaceSub Looking at your top.sls doesn't the clamav.amavisd overwride config previously written by the clamav and the amavisd state? If not what to the single states do?
15:09 XenophonF no, the clamav.amavisd SLS is very simple
15:10 XenophonF it just makes sure that the clamav user is a member of a group created by amavisd
15:10 XenophonF so it's just a group.present state
15:10 slav0nic joined #salt
15:10 XenophonF and it uses watch_in to mutate the dependencies of a single state
15:11 XenophonF https://github.com/irtnog/salt-states/blob/development/clamav/amavisd.sls
15:11 rory where are pillar values stored on the minion?
15:11 rory salt-call pillar.items works with no saltmaster, so they're obviously stored somewhere
15:11 spaceSub Oh, okay. Now I get it. Tahnks.
15:13 mephx joined #salt
15:14 bastion1704 joined #salt
15:16 bastion1704 Hello, we have lots of problem with salt at the moment, most of the time we have multiple salt-minion running at the same time. We saw that there are /etc/init/salt-minion.conf and /etc/init.d/salt-minion. Why 2 init scripts ? I am using ubuntu 15.04
15:16 bastion1704 14.04 sorry
15:19 subsigna_ joined #salt
15:20 DammitJim joined #salt
15:22 agend joined #salt
15:22 CheKoLyN joined #salt
15:23 zmalone joined #salt
15:23 dariusjs joined #salt
15:27 VR-Jack joined #salt
15:28 bhosmer joined #salt
15:33 spaceSub Another one: I want to install some basic stuff I want to have on all machines. At the moment I have a state called 'common' installing stuf like vim,wget,screen,mtr.. is that a bad idea?
15:33 Aleks3Y joined #salt
15:36 amcorreia joined #salt
15:37 digitalhero joined #salt
15:38 digitalhero joined #salt
15:40 slav0nic joined #salt
15:43 otter768 joined #salt
15:45 rocket joined #salt
15:45 lothiraldan joined #salt
15:52 Brew joined #salt
15:55 Shirkdog joined #salt
15:56 VR-Jack spaceSub: How you like to organize things isn't necessarily good or bad.
15:56 dfinn joined #salt
15:56 spaceSub okay!
15:57 VR-Jack the only issue with "common" is if you one day decide you want to have a machine that wants to deviate from it, but you can always split it at that time.
15:57 Shirkdog win 25
15:57 Shirkdog hah
15:57 giantlock joined #salt
15:58 colegatron joined #salt
15:58 murrdoc joined #salt
15:59 dariusjs joined #salt
16:01 yannis is it possible to always run another state before the one that is requested, like a global pre-hook?
16:04 Tanta yes, include them both in another meta-state
16:04 Tanta put one before the other
16:05 rory left #salt
16:07 yannis @tanta true.. I guess I'm kind of doing that already by including the "pre" state into my main state, my issue is I have to do this for a lot of states and maintenance is an issue..
16:08 mohae joined #salt
16:08 XenophonF spaceSub: what VR-Jack described is exactly how i started out
16:08 XenophonF i used to have a common SLS
16:09 yannis is there some sort of inheritance / aliasing of states I can take advantage of?
16:09 XenophonF about a year or two ago, i broke everything down into what i thought of as discrete components
16:10 XenophonF some of those top-level SLSes are two-liners, like the state that installs tcsh or the other one that installs the windows server admin tools
16:10 Tanta I use /common, & /modules
16:10 Tanta I have a third directory /roles that I use for meta-states that assemble custom collections of modules
16:11 VR-Jack XenophonF I started using common/blah states, just so top showed me at a glance what was used.
16:11 XenophonF yannis: i assign each minion a role using pillar, with that role pillar being used in targeting
16:11 rem5 joined #salt
16:14 SpX joined #salt
16:14 yannis XenophonF: thanks for the suggestion, my issue with that is that I'd like a state executed, without having to specify it for each run, prior to another that I've specified, e.g. I want "salt db1 state.apply db" to result in running a small pre-state which sends a notification that a deployment has started, for example
16:15 yannis and after sending that, proceeding to run the "db" state
16:16 yannis but I'm starting to lean towards using state templates which import all the things I need, as long as I can be as high level as possible and avoid maintenance on those imports
16:17 LondonAppDev I tried adding 'gitfs_remotes' to my masterless minion and then running salt-call state.highstate but I get "No top file or external data matches found". Can I use gitfs_remotes with a masterless minion?
16:17 Tanta that is essentially what I use roles for, i.e. roles/db.sls would have include: -modules.notify.start\n-modules.whatever
16:17 VR-Jack yannis: ordering is generally sequentially read unless requirements adjust it
16:19 yannis Tanta: I will look into that, I haven't written custom modules yet, perhaps they will be the lowest maintenance choice
16:19 yannis thanks!
16:20 beardedeagle joined #salt
16:26 rem5 joined #salt
16:26 pwalsh joined #salt
16:26 XenophonF yannis: here are concrete examples of my configs - https://github.com/irtnog/salt-states and https://github.com/irtnog/salt-pillar-example
16:28 freelock joined #salt
16:28 dgutu joined #salt
16:29 cyborg-one joined #salt
16:30 dft joined #salt
16:30 dft good day
16:31 morissette joined #salt
16:35 rihannon joined #salt
16:37 andrew_v_ joined #salt
16:39 XenophonF yannis: i just pushed some new stuff to my salt-pillar-example repo
16:42 tercenya joined #salt
16:51 anotherZero joined #salt
16:53 jimklo joined #salt
16:54 VR-Jack joined #salt
16:58 digitalhero joined #salt
16:58 rihannon joined #salt
16:58 elsmo joined #salt
17:00 _JZ__ joined #salt
17:00 RandyT good day all
17:00 RandyT getting back to an issue I asked about yesterday: https://gist.github.com/rterbush/68c767f31e8f891b0ffd
17:00 izibi joined #salt
17:00 RandyT trying to loop through all EC2 instances and setup cloudwatch alarms.
17:01 RandyT This has the effect that it is operating on each character of the returned instance-id
17:01 RandyT what am I doing wrong with the jinja here?
17:02 Bryson joined #salt
17:02 DanyC joined #salt
17:03 digitalhero joined #salt
17:03 impi joined #salt
17:04 DanyC Hi anyone can pls tell what is the meaning of [] in a state? so if you have user.absent: [] i get that is a list and it will uninstall the user but what it means/ how it works ? If that is explain in the doc pls point me there
17:04 pwalsh joined #salt
17:05 AndreasLutro DanyC: each state declaration consists of a list of arguments to pass to the state function, by passing an empty list you denote that you don't want to pass any arguments (just use the default)
17:06 DanyC AndreasLutro: superb explanation !! Any idea if this is part of the doc, if not i'd like to send a PR as is very good one
17:06 AlberTUX1 joined #salt
17:07 RandyT I suspect my issue is about not understanding what the grains.get returns for me. Appreciate any guidance here
17:07 AndreasLutro no idea
17:07 AndreasLutro it's probably there somewhere
17:07 `Puckel_ joined #salt
17:08 AndreasLutro RandyT: grains will only return values for the current minion, not all minions
17:08 AndreasLutro RandyT: you probably want to use the mine
17:08 Edgan joined #salt
17:09 AndreasLutro RandyT: to check what the grains.get function call actually returns, you can do salt '*' grains.get ec2:instance_id
17:09 RandyT AndreasLutro: salt-call grains.item ec2:instance_id does return the values for all minions.  Not available to me in this case?
17:09 foundatron joined #salt
17:10 AndreasLutro oh? how'd those grains get there then?
17:10 alemeno22 joined #salt
17:10 RandyT custom grain for ec2_info
17:11 AndreasLutro that seems very odd but ok, can you show me the output of salt-call grains.get ec2:instance_id ?
17:11 RandyT need to change my call from .get to .item in that jinja example then?
17:11 DanyC RandyT: the ec2_info custom grain does use the AWS metadata available on that EC2 instance not all EC2 instances you have in your VPC
17:12 Jarus joined #salt
17:12 AndreasLutro uuh no
17:12 AndreasLutro just show me the output please
17:12 RandyT AndreasLutro: standby..
17:13 Tyrm joined #salt
17:14 RandyT AndreasLutro: updated the gist to show what I get for each minion
17:14 RandyT changing to .item actually operates on the grain key, not value
17:15 AndreasLutro that doesn't look like a list of all instance ids to me
17:15 AndreasLutro like I said: grains will only return values for the current minion, not all minions
17:15 RandyT there is an entry for each minion id followed by the values as shown.
17:15 RandyT I just gave you one of them.
17:15 VR-Jack2 joined #salt
17:16 AndreasLutro yes, but that just means they're different for each minion
17:16 AndreasLutro not that they're all available
17:16 LondonAppDev When it says "By default, Salt updates the remote fileserver backends every 60 seconds.", does that mean it pulls the latest remote files and runs state.highstate or does it only pull the files down, and state.highstate must be ran manually?
17:16 RandyT Maybe I am not following, but I have a different value for each instance id for each minion
17:16 AndreasLutro LondonAppDev: no highstate is ran
17:16 RandyT just stanitized the output to show one of them
17:17 LondonAppDev AndreasLutro it runs state.highstate automatically?
17:17 AndreasLutro LondonAppDev: no, highstate is not ran
17:17 LondonAppDev Ahh ok. Thank you.
17:18 AndreasLutro RandyT: it's still just a single value, grains.get won't return a list of all minion instance ids
17:18 RandyT what about using grains.item ?
17:18 AndreasLutro no difference
17:18 AndreasLutro you need to use the mine
17:18 whytewolf RandyT: grains.* works on each minion not on a global
17:19 RandyT not being argumentative, just confused as to why salt-call grains.item ec2:instance_id is returning a list for every minion
17:19 RandyT and confused that is not available to me in this state in for loop.
17:20 whytewolf RandyT: so on one minion you see a list of every minion with out having to go to another minion?
17:20 linjan joined #salt
17:20 AndreasLutro there is no way salt-call returns for multiple minions...
17:20 RandyT assuming that salt-call, running on the master is doing that... I guess events would tell me
17:21 whytewolf is the master an instence?
17:21 RandyT I am sorry, of course you are all correct.
17:22 RandyT ok, going back to the mine...
17:22 RandyT mine should give me this info for all minions then?
17:22 zsoftich1 joined #salt
17:22 thetoolsmith joined #salt
17:23 whytewolf mine has a second level of targeting so that you can pick what servers you want to pull data from
17:24 agend joined #salt
17:24 Grokzen joined #salt
17:27 grumm_servire joined #salt
17:30 dft heh, does file.directory make a complete directory path if the entire path is missing?
17:31 LondonAppDev Would you guys recommend keeping the pillar in a git repo?
17:31 murrdoc if requested
17:31 dft murrdoc: are you answering me?
17:35 DammitJim joined #salt
17:35 bastion1704 joined #salt
17:38 onlyanegg joined #salt
17:41 drawsmcgraw LondonAppDev: yes :)   We keep ours in a separate 'salt-pillar' repo
17:42 drawsmcgraw Sensitive information stays on the Salt master at /srv/pillar/
17:42 LondonAppDev drawsmcgraw but it's that a bit annoying to manage two seperate repos?
17:43 whytewolf LondonAppDev: when you are used to managing hundreds. two doesn't seem that bad ;)
17:43 drawsmcgraw what whytewolf said
17:43 LondonAppDev lol
17:43 armguy its really no more work I do the same thing
17:43 drawsmcgraw Also, it's nice to separate 'data' from 'instructions'
17:43 LondonAppDev But would you store your pillar repo on a central repository like GitHub or BitBucket or would that not be advisable?
17:43 DanyC i'm looking at locking down access to Master. Questions: from a minion is it possible to refresh pillars/ clear git backend/ apply the highstate ?
17:44 otter768 joined #salt
17:44 drawsmcgraw LondonAppDev: We have an internal git repo so... a little spoiled there
17:44 LondonAppDev Sweet
17:44 drawsmcgraw Either way, you need *something* for version control / backup
17:46 oida joined #salt
17:51 RandyT Added comment to this gist: https://gist.github.com/rterbush/68c767f31e8f891b0ffd
17:51 RandyT Trying to setup the mine_functions: and not quite grasping something here...
17:53 RandyT mine_functions set via global pillar applied to all minions.
17:53 whytewolf RandyT: run two functions and try again. saltutil.pillar_refresh and mine.update
17:54 whytewolf looks like only one minion is responding to the mine
17:54 RandyT instresting, that fixed it.
17:54 RandyT I had already run a pillar_refresh and sync_all
17:54 RandyT that apparently was not enough
17:55 whytewolf mines only update once every 60 seconds . the mine.update forces that update
17:55 RandyT every minion now know's every other minion's instance_id
17:55 whytewolf [mine_interval can be changed in the minion config]
17:56 RandyT thanks, noted
17:56 RandyT so back to the jinja in that state...
17:56 RandyT {% for instance in salt[mines.get](instance_id) %} ?
17:57 RandyT that is not it
17:59 whytewolf {% for host, instance in salt['mine.get']('*', 'instance_id', expr_form='glob').items() %}
17:59 whytewolf try that
17:59 whytewolf [I'm not sure if that one will return a tuple]
18:01 RandyT whytewolf: looks like that does it. Thanks!
18:01 RandyT great exercise there. Now off and running with mine. :-)
18:02 RandyT interesting that the pillar references seem to blow up, passing value in char arrays...
18:02 RandyT any way to avoid that, or now have to go to putting that in mine as well?
18:05 larsfronius joined #salt
18:06 RandyT actually, that is not what is happening. Seems Amazon is complaining about the length of the arn...
18:12 ageorgop joined #salt
18:13 duckfez joined #salt
18:26 pwalsh joined #salt
18:28 denys joined #salt
18:29 _beardedeagle joined #salt
18:29 m4rx joined #salt
18:29 m4rx left #salt
18:31 grumm_servire joined #salt
18:33 buMPnet joined #salt
18:34 Rumbles joined #salt
18:34 Striki_ joined #salt
18:35 denys joined #salt
18:36 m0nky joined #salt
18:36 sjorge joined #salt
18:36 sjorge joined #salt
18:37 trave joined #salt
18:37 jirwin joined #salt
18:37 robinsmidsrod joined #salt
18:38 antonw joined #salt
18:38 bstaz joined #salt
18:41 FreeSpencer How would I create a startup state but for a salt.mine
18:42 beardedeagle joined #salt
18:42 baweaver joined #salt
18:42 beardedeagle joined #salt
18:43 _beardedeagle joined #salt
18:50 winsalt joined #salt
18:51 RandyT salt + boto rocks
18:51 RandyT just sayin...
18:51 XenophonF when it works
18:51 snarfy joined #salt
18:51 RandyT isn't that always the case... :-)
18:51 winsalt im trying to do a git.latest on rev='mybranch' but its failing with Comment: fatal: branch 'heads/origin/mybranch' does not exist, any ideas?
18:53 RandyT winsalt: credentials?
18:53 winsalt no I can checkout master branch fine
18:54 anotherZero joined #salt
18:54 RandyT winsalt: git provider?
18:55 XenophonF the complete error message would be helpful
18:55 RandyT have not used the gitfs stuff much, but did notice some varying behavior depending on the git provider I was using.
18:55 XenophonF my ESP isn't working today
18:56 FreeSpencer I always have issues with salt and boto for route 53, takes 60+ seconds to create a record and then get ratelimited by aws dns
18:56 winsalt this isnt gitfs, its git state module
18:56 baweaver joined #salt
18:57 RandyT FreeSpencer: have not yet used it for route53.. will be doing that soon after getting log aggregation completed...
18:58 RandyT winsalt: understood, not sure if you can control the provider for the state. pygit2 has been working for most things git that I am doing.
19:02 pwalsh joined #salt
19:02 winsalt should it be branch 'heads/mybranch' instead of 'heads/origin/mybranch' ?
19:03 Tanta show the code
19:06 winsalt https://gist.github.com/rmarcinik/0624ba4ff3674e75b0cd
19:09 buMPnet joined #salt
19:33 RandyT winsalt: I've seen some issues discussed on this topic.
19:33 RandyT Can you try adding https:// to your repo url?
19:35 RandyT You are also showing kind of a mix of an ssh url style and https style
19:35 RandyT trailing colon on hostname
19:36 winsalt thats the format in the docs
19:36 rihannon joined #salt
19:36 kawa2014 joined #salt
19:37 winsalt also to be clear it works without a rev argument
19:37 RandyT are you getting the mybranch, branch or the master in that case though
19:40 winsalt master
19:40 notnotpeter joined #salt
19:44 moogyver joined #salt
19:45 otter768 joined #salt
19:46 winsalt nvm I think I got it working
19:54 ajw0100 joined #salt
19:56 linjan joined #salt
19:56 jhauser joined #salt
19:56 PsionTheory joined #salt
20:02 Greylord joined #salt
20:06 onlyanegg joined #salt
20:07 digitalhero joined #salt
20:08 snarfy joined #salt
20:14 ajw0100 joined #salt
20:17 cberndt joined #salt
20:19 digitalhero joined #salt
20:25 KennethWilke joined #salt
20:26 RandyT winsalt: what was the issue?
20:27 digitalhero joined #salt
20:28 digitalh_ joined #salt
20:32 Tyrm_ joined #salt
20:33 snarfy i have a dumb question. when i look at debug logs, I see tons and tons of lines about reading configuration and missing configuration files. how many times does it need to read the config? why so much?
20:34 teryx510 joined #salt
20:34 irctc468 joined #salt
20:37 DammitJim joined #salt
20:38 zmalone joined #salt
20:39 oida joined #salt
20:40 giantlock joined #salt
20:43 keimlink joined #salt
20:45 digitalhero joined #salt
20:49 baweaver joined #salt
20:49 brianfeister joined #salt
20:51 baweaver joined #salt
20:54 Rumbles joined #salt
20:55 quasiben joined #salt
20:59 perfectsine joined #salt
21:00 quasiben1 joined #salt
21:02 winsalt i think in my madness I made a branch names 'origin/mybranch' and so checking out the real origin/mybranch was ambiguous?
21:07 fas3r joined #salt
21:07 fas3r Hello
21:07 moogyver snarfy : it's part of the master maintenance schedule it runs
21:07 strangecolor joined #salt
21:07 moogyver if you want to change it, you can modify the loop interval in the master config
21:08 strangecolor I am new to Salt.  Curious about the difference between salt.modules.virtualenv_mod and salt.states.virtualenv_mod
21:08 jhauser joined #salt
21:09 jimklo_ joined #salt
21:09 murrdoc one is a state
21:09 murrdoc other is a module
21:09 murrdoc state calls a module
21:09 murrdoc under the hood
21:10 moogyver strangecolor - states are things like 'i want my system to look like this'.   modules are more for 'go do this thing'.
21:10 strangecolor Beautiful. Thanks!
21:10 moogyver so alot of states use modules under the hood to configure the system how you defined
21:10 moogyver but you also have the option to just use modules to do stuff if you'd like
21:12 hal58th_ strangecolor: https://docs.saltstack.com/en/getstarted/overview.html
21:13 amcorreia joined #salt
21:16 RandyT I have chosen not to define environment in my filesystem layout (if I understand that concept correctly). Everything is base.
21:16 RandyT is there a best practice to store concept of envrironment globally for all minions?
21:17 RandyT trying to maintain portability between a production and staging environment that live in different cloud service accounts.
21:17 fas3r is it possible to list in a loop ( for /endfor ) of the targeted minions from the sls file/init file ?
21:17 RandyT I was setting a pillar variable in each environment for "staging" or "production" but finding that the pillar doesn't seem to always be available in places like orchestration runner
21:18 oida joined #salt
21:19 RandyT so net-net is that I want to be able to make orchestration states portable between production and staging by using jinja {% if environment == "production" %}
21:20 kevinqui1nyo joined #salt
21:20 kevinqui1nyo i have a particular SLS that during deployment of a cluster occassionally gets an error "Error: Error establishing a database connection" when it goes to create a mysql user / database, etc
21:20 scoates joined #salt
21:21 kevinqui1nyo what's the best way for me to have that state "try again" after a few seconds?
21:21 Drew_ joined #salt
21:21 kevinqui1nyo i know that's not the best solution overall, but it's sporadic and i can't figure out why it isnt able to establish a connection sporadically
21:21 kevinqui1nyo running the state again usually fixes it
21:22 Drew_ I am new to salt and started using it before 4 weeks in the new company...
21:22 Drew_ my boss wants me to upgrade salt to the latest version
21:23 murrdoc do u like the job ?
21:23 Drew_ yeah
21:23 Drew_ I do
21:23 murrdoc thats a tough problem
21:23 murrdoc do u have a pre prod
21:23 Drew_ so we have a master and around 80 minions registered to it
21:24 Drew_ we have dev and prod
21:24 gcorey joined #salt
21:25 Drew_ and I can n't take all minions off together. one at a time is the only way (if upgrade requires that)
21:25 Drew_ So, how do I upgrade salt?
21:27 Drew_ I am not seeing anything on salt docs either
21:28 Drew_ can anyone direct me on this?
21:29 moogyver Drew_ - it's generally the same process as installing salt - just do the masters first, then the minions
21:30 moogyver but you should be doing it in a dev/pre-prod env first to make sure that the newest version ( or whatever you're upgrading to ) doesn't cause some issue with your setup
21:30 moogyver you'd want to do sane things as well, like back up configs and other data.
21:30 whytewolf if you can do a dev system first so that you can test if your states need fixing for a newer version
21:30 moogyver but other then, it's generally just using whatever package distribution your OS has to install the new version.
21:31 Drew_ We are using Rhel 6.5 on physical servers
21:31 Drew_ and 7.1/2 for virtual
21:32 moogyver so you'd probably be either using the bootstrap script or just doing yum upgrades of the RPM.
21:32 moogyver just make sure to backup your data and configs first.
21:32 aron_kexp_ joined #salt
21:33 moogyver RandyT : you can define the environment in the minion config, although it's not considered a best practice - but there is a config item for it.
21:33 rem5 joined #salt
21:34 Drew_ so, running simply, yum install salt-master and yum install salt salt-minion would update it to the latest version.... It seems I am missing something
21:34 moogyver Drew_ : I'd run a yum 'update' instead of 'install' but yeah, that's about it.  As long as those packages are available in your configured yum repos.
21:35 surge_ joined #salt
21:35 moogyver I'd shut the master / minion down before I did the update, but yes..
21:35 moogyver ( + all the other stuff I mentioned )
21:35 surge_ has anyone successfully used the salt consul module for creating/deleting keys and sessions?
21:35 surge_ It refuses to work for me
21:35 whytewolf yum update on the master. then salt -b 5 '*' pkg.install salt-minion
21:35 Drew_ Back up the data and all is already done!!
21:36 moogyver surge_ : any specific error your getting?  I thought I had it working when I was testing between consul and etcd
21:36 moogyver Didn't remember having an issue
21:37 Drew_ @whytewolf.... in "salt -b 5 '*' pkg.install salt-minion" what is -b and 5 for?
21:38 whytewolf Drew_: batch. so it only does 5 at a time
21:38 moogyver https://docs.saltstack.com/en/latest/topics/targeting/batch.html
21:38 linjan joined #salt
21:39 baweaver joined #salt
21:39 edrocks joined #salt
21:39 surge_ moogyver: Well if I don’t pass in the consul_url option, it complains. When I do, it either provides basic help output or I get a stacktrace. The first with creating a session, the second with attempting to PUT a KV pair. http://pastebin.com/ZLLhsXPF
21:39 Drew_ oh... I just referred the link.... awesome
21:39 ajw0100 joined #salt
21:39 dft RandyT: we're battling with this particular case while we build our saltstatck
21:40 denys joined #salt
21:40 dft we were first going to push roles out via grains, but as mentioned not considered best practice
21:40 Drew_ Plus, taking the master/minion off means doing "systemctl stop salt-master/salt-minion" right?
21:41 dft all sorts of "what ifs" around using grains to define server roles that could really mess things up.
21:41 larsberg joined #salt
21:41 surge_ moogyver: The docs don’t really specifiy much in the way of having to create a session first before being able to write. I’m very green to Consul as well, so I’ve been reading the docs this morning to avoid any surprises, but it seems I still hit some.
21:41 moogyver dft - what sort of 'what ifs'?  like if people change the grain on the host?
21:41 Drew_ we shut the only salt service off???
21:42 moogyver surge_ - you don't really have to create sessions with consul, unless ( if I recall ), you're trying to do authentication or are trying to do key-expiration
21:42 surge_ Yeah, okay, in that case, I’m not.
21:42 moogyver If you're just trying to set keys, shouldn't need to worry about creating sessions.
21:43 surge_ I am taking baby steps towards service discovery so this is the first hurdle. Getting the damn thing to work lol. I can just as easily do this via curl, but the module is a much cleaner way to make it happen (if it works).
21:43 jerematic joined #salt
21:44 moogyver surge_ - so, for the url part - do you have the consul.url defined in the minion config?
21:44 surge_ No, I thought, maybe naively, that salt would assume localhost if it didn’t find a key for that.
21:44 moogyver unfortunately, not the way the module is written, no
21:45 surge_ It says I can pass consul_url though, so I thought it would be supported in the command line as well.
21:45 moogyver it wants either consul.url defined, or it requires you to pass it via the cmd line
21:45 moogyver so, you could be able to do it via cmd line
21:45 surge_ Well, I tried and then got the stack trace =/
21:46 moogyver yeah, looking at that.  what version of salt, btw?
21:46 otter768 joined #salt
21:46 surge_ 2015.8.3
21:47 DanyC joined #salt
21:47 dft moogyver: yes
21:48 brianfeister joined #salt
21:48 Drew_ To upgrade, 1. Make sure we have back of the data and config files 2. systemctl stop salt-master 3. yum update (on the master) 4. systemctl start salt-master 5. salt ‘*’ -b 5. pkg.install salt-minion (depending on my infrastructure)
21:48 moogyver dft - yeah, we are afraid of the same thing - we plan on putting the role into pillars, then creating the grain based off the pillar data and enforcing that every 30 min or so
21:48 cliluw Is it possible to attach pdb to Salt after having already started the process?
21:49 dft moogyver: I like it, like it alot.  I might steal this idea
21:49 Drew_ sorry
21:49 DanyC all, anyone knows if i can in any way check on a minion if a specific state name was applied ?
21:49 dft moogyver: I might pick your brain on how you're doing this as I investigate
21:49 moogyver dft - it's not perfect, but it hopefully gets around the concern that people might modify the grain
21:50 moogyver ours is more around external_auth and issues we have w/ it rather than using the grain for states and orchestrates
21:50 moogyver dft - sure
21:50 DanyC or is anyway i can set a grain to pull the state name applied ?
21:50 Drew_ @moogyver, Is that all I have to do to upgrade?
21:50 dft moogyver: ty
21:51 moogyver Drew_ - that's a good general summary, yeah.  I'd do it on dev or something first if you could though.
21:51 sgargan joined #salt
21:52 Drew_ moogyver: installing package on salt-minions is as same as yum update?
21:54 dgarstang joined #salt
21:54 dgarstang Does salt have something similar to chef's versioning of cookbooks?
21:55 murrdoc formulas
21:55 aurynn dgarstang, salt uses Git directly, so similar version semantics can be applied, but it's more work
21:55 aurynn in that you have to decide "what are my versioning sematics", whereas chef just hands that to you
21:55 jimklo joined #salt
21:57 moogyver surge_ : try and pass in 'http://127.0.0.1:8500' as your consul_url
21:57 moogyver or https that is
21:57 moogyver since I think consul runs on https by default
21:57 Tyrm joined #salt
21:58 moogyver Drew_ : the 'pkg.install' will use whatever the OS's package distribution method is for installing packages - so in your case, yes, it'll be using yum
21:58 dgarstang aurynn: Is there best practices documentation on this specifically for use with salt?
21:58 colegatron joined #salt
21:59 surge_ moogyver: that did it. It’s interesting that it doesn’t behave the same when using just the IP:PORT without http.
21:59 dgarstang aurynn: Git revision numbers also don't make good semantic human readable version numbers.
21:59 moogyver surge_ - it's a tornado thing
21:59 moogyver tornado is trying to detect the URL scheme used
22:00 moogyver and since there's no 'http://' or 'https://'
22:00 moogyver it doesn't know what to sue
22:00 aurynn dgarstang, Salt will always take HEAD for the branch it's on, and branches are directly mapped to environment names
22:00 aurynn so managing that is about when you tag releases and merge them back into the environment-specific branch
22:01 dgarstang aurynn: Would still like to see a doc on this
22:01 aurynn dgarstang, ask iggy ? I don't have one off the top of my head
22:01 moogyver https://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html
22:01 moogyver it's not a best practices, but shows everything you can do
22:03 Tyrm joined #salt
22:04 surge_ moogyver: ooooh
22:04 ronrib joined #salt
22:05 surge_ moogyver: welp, guess I’m going to write a TODO to myself for updating the docs and noting that haha
22:05 Ch3KoLyN joined #salt
22:06 moogyver surge_ haha yeah - they should really have some examples that specify how to use the cmd with the consul_url parameter
22:07 GreatSnoopy joined #salt
22:11 moloney joined #salt
22:11 blckbit10 joined #salt
22:11 zmalone Has anyone seen inconsistent grain values on salt masters?  I have a grain set on a minion, and salt-call on the minion shows the grain set to the value in /etc/salt/grains, but checking the grain on the master results in a different value.  If another person checks the grain from the master, they get the new value that I don't see.
22:13 jhauser joined #salt
22:13 moloney I want to setup reactors for when I first accept a minion key and for when a minion starts up, but I guess these will both run at the same time when I first accept a minion key. Is there any good way to avoid that? Basically I just want the minion start reactor to run on subsequent startups and not the very first one.
22:14 moogyver moloney - the tag is the same, i think you have to look at one of the fields in the event.  if the key hasn't been accepted, it's set to 'pend'.
22:15 moogyver zmalone - does clearing the grain cache fix it?
22:15 zmalone No, but deleting the /etc/salt/grains file and recreating it does
22:16 moloney moogyver:  But after I accept the minion key, both reactors will run
22:18 moogyver moloney - gonna check it out on my lab server
22:19 nbastin joined #salt
22:22 moogyver moloney - are the reactors different between what you're trying to do? ie - you have reactor A that's trying to do something for when you accept keys, and you have reactor B trying to do something else when a minion starts, but you don't want them both of them run when you accept a key?
22:23 nbastin Is it possible to use salt just to kick off processes on demand, as a user of your choice?  This is really all I'm looking for, but there doesn't seem to be a system that just does that
22:24 moloney moogyver: They both take care of some prerequisites I need for my custom grains and do a sync_all, but for the accept key reactor then also does a highstate and then reboots the minion.
22:24 baweaver joined #salt
22:24 jhauser joined #salt
22:25 babilen nbastin: It is, just pass the user to cmd.run -- https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cmdmod.html#salt.modules.cmdmod.run
22:26 nbastin babilen: that may be a bit past where I am, but that looks good at least.. :-)
22:26 nbastin like, what's the minimum we have to put on each node to support this
22:27 babilen nbastin: Nothing if you use salt-ssh, the salt-minion if you want to use masterless, salt-master somewhere + salt-minion on the minion if you want to use a master-minion architecture
22:27 nbastin we can definitely do master + minion, as far as I understand it (our master can persist forever, the minions come and go)
22:27 babilen What do you mean by "a bit past where I am" ?
22:28 moloney nbastin: if you want to use the salt-minion look at salt-bootstrap
22:28 nbastin babilen: I mean that's nice API, but I gotta get something installed first.. :-)
22:28 babilen ah
22:28 nbastin babilen: is it ok if the master is on an untrusted WAN, or should it be local?
22:28 babilen Sure, just install salt and a couple of minions, accept their keys and start playing
22:29 babilen It's perfectly fine if it is communicating over an untrasted network .. In that case I'd check the minion's fingerprints twice though ;)
22:29 babilen (before accepting them)
22:29 babilen *untrusted
22:29 nbastin babilen: sure, we've got a whole PKI setup already with ssl client certs and fingerprint checks and such for everythign that already exists
22:29 nbastin won't be hard to work in whatever is available
22:30 nbastin alright, I guess the thing to do at this point is try out a small setup, as it seems to support what I want in the end
22:31 babilen nbastin: You might be interested in https://docs.saltstack.com/en/develop/topics/reactor/index.html#a-complete-example
22:31 moloney moogyver:  I found an excerpt form "Mastering Saltstack" that says only one reactor runs at a time, so maybe this isn't a big deal.  I would just get some error messages about the first on_start reactor failing (since the minion would be rebooting when it tries to run).
22:31 nbastin babilen: thanks
22:32 babilen (if you want to automatically accept minions -- you could also remove missing/down ones regularly)
22:32 nbastin babilen: can I give them some key first to use?
22:32 babilen You can preseed keys, yes. https://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html
22:32 nbastin babilen: our orchestrator will put whatever I want on them when it creates them, so I can put something on them that identifies them as proper
22:32 babilen aye
22:32 nbastin brilliant!  :-)
22:33 moogyver moloney - well, the reactor itself shouldn't be doing alot - it's generally just parsing the tag and then firing off a job
22:33 moogyver that job isn't considered the reactor 'running'
22:33 moogyver unless you're doing alot of stuff in jinja and making calls and stuff
22:33 moogyver but it's generally better to keep your reactor sls files fast and small and let the module or runner you're executing do the work
22:35 nbastin babilen: well, so looking at cmdmod...
22:35 nbastin babilen: I need to start something that I need to later tell to stop, but will not otherwise stop
22:35 nbastin babilen: (kill is fine)
22:35 bhosmer joined #salt
22:36 snarfy moogyver, awesome thanks!!!!
22:36 moloney moogyver:  The key_accept reactor has multiple steps: 1) install prereqs, 2) sync_all, 3) highstate, 4) reboot.  So I guess all those have to complete before the reactor is done "running"
22:36 nbastin babilen: it doesn't at first blush want to let me run something in the background (modulo I guess I can try to pass shell & magic, or whatever, but that seems hackish?)
22:36 babilen nbastin: init script/systemd unit file + service.start/service.stop ? (cf. https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.service.html )
22:37 nbastin babilen: well so in particular we need to run an arbitrary number of tcpdump processes, which won't work well as init scripts (we might have to start N, where N > 1)
22:37 nbastin I mean I can make stupid init scripts that don't keep pids
22:37 nbastin but they're hard to stop
22:37 moogyver nbastin : --async and salt-run jobs.kill_job <job id>
22:38 nbastin moogyver: where does this --async come in?  (cmdmod seems to have no async-ness in the API docs)
22:38 moogyver the salt cmd itself
22:38 cpelon joined #salt
22:39 moogyver When you use async, the salt command will return immediately and just give you the job id
22:39 moogyver and you can use that job id to lookup results and such later
22:39 nbastin moogyver: I can't have a network connection that lives a long time - if --async just manages this for me on the client side that may not work
22:39 moogyver or kill the job if it's still running
22:39 nbastin if it dispatches and stores a handle but disconnects, that seems fine
22:39 babilen yeah
22:40 fas3r is it possible to create a list / dictionnary of values ( a table ) ?
22:41 moogyver nbastin - it's not.  all the connections are minion -> master.   so the minion listens for publications from the master.  then when they complete their job, they send their data to the master's event bus.
22:41 moogyver the minions have constant connections to the master though - so I'm not sure if that works for you and your network connection req.
22:41 nbastin moogyver: so during the runtime there's no active connection
22:42 nbastin (also what happens if they can't talk to master when they're done?)
22:42 moogyver Well, there's always the constant minion -> master connection, but not for that job
22:42 nbastin hrm, how bad will it be if that's not true.. :-)
22:42 moogyver It all works on event busses
22:42 moogyver buses? bus's? busee.
22:42 nbastin possibly I should just go off and try this and see what happens so I can ask more intelligent questions
22:42 nbastin buses I think
22:42 nbastin but yeah
22:42 nbastin maybe busses?
22:42 moogyver sec nbastin , let me grab you a youtube vid
22:43 snarfy argh
22:44 snarfy ok so i'm way down the rabbit hole here
22:44 moogyver nbastin - https://www.youtube.com/watch?v=r0NLljxDd1U
22:44 moogyver he goes over the internals and how the comms work w/ the master and minions
22:44 moogyver may give you what you're looking for
22:44 nbastin moogyver: thanks
22:44 nbastin moogyver, babilen: thanks, I'll try some things and come back and ask more informed questions later.. :-)
22:45 zenlot1 joined #salt
22:46 mosen joined #salt
22:46 moogyver moloney - i think the reactor is multi-threaded ( jacksontj should be able to correct me if I'm wrong on that ), so I'm not sure counting on a long running reactor job to stop another one from running is a good plan
22:47 brianfeister joined #salt
22:48 moogyver moloney - you could so something like writing a file or storing state / pillar about a host once the auth reactor has run and any start reactors won't run unless that state exists
22:48 moogyver how you manage that metadata would be up to you ( external, a file that exists on the host, some cmdb, etc )
22:49 snarfy I have two repos for gitfs. one for top file and one for environment-separated state files.
22:49 snarfy my understanding is that the env for base cannot have any states that conflict with the environments, becaue they clash on a highstate
22:50 snarfy and, indeed, if i highstate a minion, it seems to get base + env states and highstate successfully
22:50 snarfy however, if I just want to run a singular state that isn't a part of the minion's top file, it fails saying that state isn't in the base environment
22:51 snarfy which is true - it's in the dev environment. how can i have multiple envs, a base, and still have access to non-base states from the minion?
22:53 moogyver snarfy - you can pass a saltenv arg to use a diff env for alot of the state commands
22:54 moogyver you always have 'access' to the entire fileserver from the minion, there isn't real separation
22:54 snarfy yeap just figured that
22:54 snarfy for some reason i tried --saltenv=dev before
22:54 snarfy :D thanks again
22:55 subsignal joined #salt
23:01 Rumbles joined #salt
23:01 nbastin moogyver: salt-bootstrap doesn't seem to like 14.04 - is that true, or just an oversight in the docs?
23:01 nbastin moogyver: I mean ubuntu 14.04.. :-)
23:02 moogyver nbastin - ah i'm not sure.  all my stuff is RHEL based.  The bootstrap stuff may not support it but I'm pretty sure salt itself supports it
23:03 moogyver https://repo.saltstack.com/#ubuntu
23:03 moogyver they have it listed there
23:03 moogyver so i'm guessing supported
23:05 moloney moogyver:  Thanks for the help.  I was already considering using a file or something to prevent the on_start reactor from running until after the key_accept reactor, but figured I would ask if there is a better way.
23:05 jfindlay rbjorklin: bootstrap should totally support 14.04, if not, it's a bug :-)
23:05 moloney nbastin: I am using salt-bootstrap on 14.04 all the time
23:06 aron_kexp joined #salt
23:06 nbastin moloney: ok, am trying, so hopefully it Just Works
23:07 jfindlay nbastin: wrong tab complete, sorry
23:07 IPA` joined #salt
23:07 nbastin jfindlay: ah, thanks...well I guess I'll find out.. :-)
23:07 baweaver joined #salt
23:07 nbastin jfindlay: the docs on /latest/ stop at 13.10
23:08 moogyver moloney - yeah, I'll keep thinking but my 'best' thought right now is either a file or setting a pillar value in an external pillar if you have it
23:09 jfindlay nbastin: were is that?
23:09 nbastin jfindlay: https://docs.saltstack.com/en/latest/topics/tutorials/salt_bootstrap.html
23:09 moogyver there doesn't appear to be any difference between a first time minion start event and non-first time minion start
23:11 jfindlay nbastin: thanks
23:11 moloney moogyver: You think I should put in a feature request in github issues for something like that?
23:13 IPA` I'm tying to install nodejs via the salt formula. I added a pillar file https://github.com/munichlinux/vagrant-setup/blob/master/srv/pillar/node.sls. I am not sure what am i doing wrong here, any pointers?
23:13 baweaver joined #salt
23:13 moogyver moloney - wouldn't hurt.  salt is very receptive and if they know of some other way to do it, they'll let you know
23:13 snarfy ugh that's still pretty annoying having to type saltenv=foo after every salt command that isn't a highstate
23:13 jfindlay that would be me, most likely intercepting new issues :-)
23:13 snarfy i can set environment: foo in the minion config all i want, doesn't seem to help
23:14 jfindlay I seem to recall someone filing an issue like that recently
23:14 moogyver moloney - we do a first-time start thing, but we do it as part of our server bakery.  we have a script that runs on system startup that sends a custom salt-event and then removes the script so it never runs again
23:14 Rockj joined #salt
23:14 moogyver and our 'first time' reactor is based off that event
23:14 moogyver but your issue is more that you need to ignore the first start event you ever see.
23:15 mapu joined #salt
23:15 moogyver or at least have some way of saying 'first start' is different than 'normal start'
23:17 dimeshake_ joined #salt
23:17 moloney jfindlay:  I will search the issues first to make sure I am not duplicating
23:18 jfindlay moloney: no problem, but don't be afraid to submit if you don't find anything
23:19 snarfy IPA`, that formula seems baroque and there are good nodejs packages. i know on ubuntu i'd rather install from a package because they have a conflicting package called node
23:19 jfindlay nbastin: #30461
23:19 jfindlay https://github.com/saltstack/salt/issues/30461
23:19 saltstackbot [#30461]title: update documentation on bootstrap-supported platforms | https://docs.saltstack.com/en/latest/topics/tutorials/salt_bootstrap.html#supported-operating-systems
23:19 neogenix joined #salt
23:19 nbastin jfindlay: thanks
23:19 snarfy i'm on ubuntu so I do like so.. https://github.com/snarfmonkey/salt-states/blob/dev/nodejs/init.sls  https://github.com/snarfmonkey/salt-states/blob/dev/nodejs/defaults.yaml
23:19 IPA` snarfy: thanks. I will take a look at them
23:20 snarfy and actually the newer nodesource packages do the alternatives update as part of the post-inst
23:20 snarfy making that symlink part redundant
23:22 wangofett So, I'm using https://github.com/saltstack-formulas/jenkins-formula
23:23 Pie_Mage is it possible to import other salt state files (using pyobjects here) from imported modules?
23:23 wangofett and it's got this part where it builds a jenkins cli, and it's *supposed* to use a private key, but it doesn't appear to work (i.e. it doesn't use the private key bit)
23:24 Pie_Mage it seems like as soon it imports, it stops being processed by the pyobjects renderer and switches to pure python (as it gives me a syntax error for the salt:// import syntax)
23:24 iggy Pie_Mage: import how?
23:24 chiui joined #salt
23:24 perfectsine joined #salt
23:25 Pie_Mage import salt://path/to/sls_file.sls
23:25 iggy no
23:25 iggy why would you do that?
23:26 Pie_Mage modularity, code-reuse amongst other things
23:26 geekatcmu Do you secretly mean "include"?
23:26 Pie_Mage nope
23:26 Pie_Mage import, with pyobjects
23:26 geekatcmu yes, you can do that for import.
23:26 geekatcmu s/for/with
23:26 Pie_Mage i do! and it works!
23:27 Pie_Mage but when I import salt://... in the imported file it doesn't recognize it
23:27 geekatcmu Oh, right.
23:27 geekatcmu That's correct
23:27 Pie_Mage ahhh
23:28 geekatcmu Or at least, that's my experience.  "nested imports" don't.
23:28 Pie_Mage yup, that's how it looks to me
23:28 snarfy OH! apparently the environment issue I am complaining about was fixed somewhere between 2015.5.0 and 2015.8.3 ;)
23:30 bhosmer joined #salt
23:31 snarfy one of those 'oh i upgraded and it works now'
23:31 subsignal joined #salt
23:31 neogenix joined #salt
23:32 lorengordon Pie_Mage: is the effective goal to use a relative path of sorts? do you know the path relative to the pyobjects state?
23:32 lorengordon Pie_Mage: if so, perhaps try using the `tpldir` variable. that should resolve to the path of the current state.
23:34 Pie_Mage i'm trying to build a bunch of python functions to programatically generate the states, then import them where I need them
23:35 moogyver snarfy - you mean the 'environment' var in your minion is now working?
23:36 neogenix joined #salt
23:36 Pie_Mage so in my pyobjects code, i can just have a bunch of function calls which generate the states from my pillar data
23:36 lorengordon gotcha. well, dunno if `tpldir` is available to pyobjects, but worth a try
23:37 lorengordon here's a link with example usage (in jinja): https://github.com/saltstack/salt/issues/4348#issuecomment-110348391
23:37 saltstackbot [#4348]title: feature request: relative salt:// paths | I find myself repeatedly typing the same salt:// path:...
23:38 baweaver joined #salt
23:40 lorengordon i also know that if you use jinja to `include` an sls, the sls code is used in the state
23:40 lorengordon e.g. `{% include 'super.sls' %}`
23:40 lorengordon perhaps there's an equivalent in pyobjects
23:40 Pie_Mage can you combine jinja and pyobjects?
23:40 lorengordon no idea
23:41 Pie_Mage TO THE EXPERIMENTORIUM!
23:42 Pie_Mage sounds like a good lead either way, much appreciated
23:42 lorengordon huh, the docs say pyobjects should be able to import from a salt:// url exactly as you were trying... https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.pyobjects.html#importing-from-other-state-files
23:44 rem5 joined #salt
23:46 zmalone joined #salt
23:47 otter768 joined #salt
23:49 Pie_Mage lorengordon: https://github.com/saltstack/salt/pull/12577
23:49 saltstackbot [#12577]title: Make `salt_import` available to pyobjects rendered files | As I've been working through converting my jijna-heavy states to pyobjects states I've discovered that nested imports using the `salt://` syntax doesn't work. Looks like it's because it does a regex/load/exec for the initial pyobjects file it renders, but not included children....
23:50 lorengordon that kind of sucks
23:51 Pie_Mage it really does, makes modularizing things so very flat
23:52 Pie_Mage I guess it's not the end of the world, just means that everything is going to have to be imported for everything else
23:54 lorengordon maybe open an issue for the feature and ping the two committers in that closed pr
23:57 Pie_Mage that might actually be a better idea than opening up the old tickedt

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