Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-10-31

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

All times shown according to UTC.

Time Nick Message
00:04 N-Mi joined #salt
00:04 N-Mi joined #salt
00:11 major joined #salt
00:26 johnj_ joined #salt
00:27 ircuser-1 joined #salt
00:34 jas02 joined #salt
00:49 omie888777 joined #salt
01:14 Akkarin joined #salt
01:15 jas02 joined #salt
01:30 johnj_ joined #salt
01:33 pipps joined #salt
01:34 snc joined #salt
01:40 onlyanegg joined #salt
01:49 DammitJim joined #salt
02:03 jas02 joined #salt
02:09 nomeed joined #salt
02:26 noobiedubie joined #salt
02:31 johnj_ joined #salt
02:36 _JZ_ joined #salt
02:37 wongster80 joined #salt
02:55 jas02 joined #salt
02:56 ilbot3 joined #salt
02:56 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.8, 2017.7.2 <+> 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
03:01 wongster80 joined #salt
03:12 gnomethrower joined #salt
03:14 wongster80 joined #salt
03:20 wongster80 joined #salt
03:32 johnj_ joined #salt
03:35 jas02 joined #salt
03:41 fracklen joined #salt
03:45 jas02 joined #salt
03:48 icedev joined #salt
04:05 icedev joined #salt
04:13 icedev joined #salt
04:16 evle joined #salt
04:21 chowmein__ joined #salt
04:22 RandyT joined #salt
04:22 RandyT joined #salt
04:22 shadoxx joined #salt
04:23 ashmckenzie joined #salt
04:24 carmony joined #salt
04:24 nomeed joined #salt
04:24 jbailey joined #salt
04:24 jbailey_ joined #salt
04:24 Zachary_DuBois joined #salt
04:24 icedev joined #salt
04:25 Armageddon joined #salt
04:25 wedgie joined #salt
04:25 wongster80 joined #salt
04:28 sjorge joined #salt
04:33 johnj_ joined #salt
04:34 tiwula joined #salt
04:45 jas02 joined #salt
04:46 jas02 joined #salt
04:52 jas02 joined #salt
05:02 jas02 joined #salt
05:09 SkyRocknRoll joined #salt
05:13 jas02 joined #salt
05:17 jas02 joined #salt
05:21 laertus when i try:  salt-ssh '*' grains.item cpu_model
05:22 laertus it works... i've pasted the output here:  https://paste.pound-python.org/show/1mN6Os0ht3EuFHKyGwhN/
05:22 sahama joined #salt
05:23 laertus but when i try:  salt-ssh '*' cmd.run /bin/pwd
05:23 laertus i get:  https://paste.pound-python.org/show/0elOVgA39dT4hTKAjHDJ/
05:23 laertus why is it even mentioning "gssapiauthentication" ?  i don't have that anywhere in my salt configs
05:25 laertus i get the same output no matter what command i run, not just /bin/pwd
05:25 laertus even for non-existant commands like "foo"
05:27 laertus here's my roster:  https://paste.pound-python.org/show/V643Fz1IqUKWo4EoxFgs/
05:27 laertus i already have a regular ssh connection established to the target host, and that's what the original "salt-ssh '*' grains.item cpu_model" used, and that works fine
05:28 laertus just not sure why the cmd.run is failing with that weird error
05:33 impi joined #salt
05:34 johnj_ joined #salt
05:42 sahama @laertus which version you use?
05:43 laertus 2017.7.2
05:46 KennethWilke joined #salt
05:55 laertus i did an strace on that salt-ssh command, and i found it does:    execve("/usr/bin/ssh", ["ssh", "myhost", "-t", "-t", "-o", "KbdInteractiveAuthentication=no", "-o", "PasswordAuthentication=no", "-o", "GSSAPIAuthentication=no", "-o", "ConnectTimeout=65", "-o", "Port=22", "-o", "IdentityFile=agent-forwarding", "-o", "User=myuser", "mkdir", "-p"], 0x1a7b410 /* 137 vars */) = 0
05:55 laertus when i tried just a "ssh -o GSSAPIAuthentication=no localhost" i got the same error:  command-line line 0: Unsupported option "gssapiauthentication"
05:56 laertus so that shows that that error comes from that command line option, which salt-ssh is using for some reason
05:58 laertus ok, i see in /usr/lib64/python2.7/site-packages/salt/client/ssh/shell.py there's a "options.append('GSSAPIAuthentication=no')"
06:01 laertus changing that line (and another identical line) to "pass" got rid of the error, but my salt-ssh command still has no output apart from what i pasted above
06:01 laertus so it's still not working
06:04 laertus for instance, "salt-ssh '*' cmd.run /bin/hostname" returns:  https://paste.pound-python.org/show/vLWXcKYwcIRf8nA3QLwC/
06:10 jas02 joined #salt
06:10 laertus i just tried:  salt-ssh '*' cmd.run 'touch /tmp/foo.bar'
06:11 laertus in hopes that it was just a problem with outputting the result of the command, but the command still ran
06:11 laertus but, no, /tmp/foo.bar does not exist on the target host after i ran that
06:11 laertus so it's definitely not working
06:24 sahama left #salt
06:35 johnj_ joined #salt
06:36 maestropandy joined #salt
06:37 maestropandy left #salt
06:41 maestropandy1 joined #salt
06:52 hoonetorg joined #salt
07:06 laertus ok, i think i may have figured it out... at least partially
07:06 laertus in between salt runs, i'd deleted and recreated my salt config
07:08 laertus but the temporary directory salt uses to cache some of its data on the target host i think must have referenced something from the earlier configuration that i'd erased
07:09 laertus anyway, deleting that salt directory in /tmp on the target host fixed it
07:11 Miouge joined #salt
07:15 bstevenson joined #salt
07:19 aviau joined #salt
07:23 Ricardo1000 joined #salt
07:26 do3meli joined #salt
07:26 do3meli left #salt
07:36 johnj_ joined #salt
07:53 impi joined #salt
08:04 usernkey joined #salt
08:06 fracklen joined #salt
08:08 fracklen joined #salt
08:12 pualj joined #salt
08:20 Hybrid joined #salt
08:21 q1x joined #salt
08:22 jas02 joined #salt
08:31 jas02 joined #salt
08:32 jas02 joined #salt
08:34 zulutango joined #salt
08:37 johnj joined #salt
08:39 fracklen joined #salt
08:39 aldevar joined #salt
08:40 pbandark joined #salt
08:50 jas02 joined #salt
08:51 gnomethrower joined #salt
08:57 mikecmpbll joined #salt
09:00 Church- joined #salt
09:01 ProT-0-TypE joined #salt
09:05 c06 joined #salt
09:06 c06 hi all
09:06 c06 what is the input json format to pass to pepper
09:07 c06 pepper --json {"key1":"a"} i am passing like this but its saying it not valis
09:11 fracklen joined #salt
09:13 _val_ joined #salt
09:13 bobby joined #salt
09:15 Church- joined #salt
09:15 bob joined #salt
09:19 jas02 joined #salt
09:21 c06 how we can pass json input parameter to pepper.?
09:22 Guest33731_ joined #salt
09:28 jas02 joined #salt
09:30 _KaszpiR_ joined #salt
09:36 NV joined #salt
09:37 c4rc4s joined #salt
09:38 johnj joined #salt
09:39 monokrome joined #salt
09:40 brent joined #salt
09:43 fracklen joined #salt
09:44 jas02 joined #salt
09:50 fracklen joined #salt
09:51 jas02 joined #salt
09:53 wryfi joined #salt
09:56 NVX joined #salt
09:59 monokrome joined #salt
10:00 rickflare joined #salt
10:00 aerbax_ joined #salt
10:01 kwilke joined #salt
10:01 carmony_ joined #salt
10:01 rewbycraft joined #salt
10:01 djinni`_ joined #salt
10:01 __peke___ joined #salt
10:02 dvdmuckle joined #salt
10:02 eichiro_ joined #salt
10:02 atoponce joined #salt
10:02 patrek joined #salt
10:03 whyzgeek joined #salt
10:04 georgemarshall joined #salt
10:04 jas02 joined #salt
10:05 wryfi joined #salt
10:05 inetpro joined #salt
10:06 nomeed joined #salt
10:06 brent joined #salt
10:07 nledez joined #salt
10:08 J0hnSteel joined #salt
10:12 gnord joined #salt
10:13 Johbe joined #salt
10:16 wryfi joined #salt
10:21 NVX joined #salt
10:30 usernkey1 joined #salt
10:34 darioleidi joined #salt
10:37 jas02 joined #salt
10:39 johnj joined #salt
10:44 jas02 joined #salt
10:48 jas02 joined #salt
10:59 Miouge joined #salt
11:01 fracklen joined #salt
11:04 bstevenson joined #salt
11:14 aldevar joined #salt
11:20 jas02 joined #salt
11:22 Neighbour Is there a standard(ish) solution for when jinja-code in certain sls-files (which are in the topfile) depend on other sls-files (also in the topfile) having been executed? Right now I've got highstates failing because of this (a user created in one sls file doesn't exist yet at compile-time in another sls)
11:30 ange same question ^
11:30 ange Neighbour: I have tried using order, and require / require_in but that's not helping
11:32 Neighbour The problem lies in the fact that when you start a highstate, *all* involved sls files get compiled right away, which includes executing code in jinja. But as some code in jinja depends on other states (which are part of the highstate) to have been executed first, the compilation fails
11:33 XenophonF orchestration?
11:33 XenophonF you could call state.apply in batches
11:38 ange XenophonF: can you define batches and which states belong to each batch ?
11:40 johnj joined #salt
11:40 _KaszpiR_ joined #salt
11:42 gmoro joined #salt
11:42 Neighbour XenophonF: True, I'm already using that, but that would totally sidestep highstates
11:43 Neighbour It would be nice if I could specify a specific topfile to use in a highstate call from orchestration...that way I could nicely create "batches" of topfiles
11:58 XenophonF can you rewrite your states so they don't depend on side effects at render time?
11:58 XenophonF ange: state.apply takes a list of SLSes as its first argument, so yes
11:58 cablekevin joined #salt
12:04 XenophonF in general I think you should write individual SLS files so they're independent of one another
12:04 XenophonF but I don't know what your Jinja code does that it needs the user account info for
12:04 fracklen joined #salt
12:04 XenophonF can't you just assume the existence of the account by that point?
12:05 fracklen joined #salt
12:08 Neighbour XenophonF: I've got a state that deploys/generates ssh keys (based on pillardata with user/keyname/keydata) that needs to find out a user's homedir
12:09 Neighbour but there's another state that, on some minion(s) creates the user (and installs whatever software that user is supposed to run)
12:10 Neighbour the first state is generic and should be used to run on any machine that needs SSH keys deployed
12:10 fracklen joined #salt
12:11 Nahual joined #salt
12:12 Neighbour the SSH-key deployment state uses jinja to generate the salt states to deploy/generate SSH keys for all defined users/keys (in that minion's pillar) which includes finding out what the homedir of each user is
12:14 ibro joined #salt
12:23 XenophonF user-formula combines the two operations
12:23 XenophonF account creation and SSH keymat deployment
12:24 fracklen joined #salt
12:24 XenophonF alternatively whatever logic you use to calculate the user's home directory in the one state, you could replicate in the other
12:25 XenophonF users-formula I mean
12:25 Neighbour there's no calculating the homedir, it's a call to salt['user.info']
12:25 Neighbour which fails if the user doesn't (yet) exist
12:25 XenophonF understood but you know where the user's home directory will be ahead of time
12:26 fracklen_ joined #salt
12:26 XenophonF so if you create /home/xenophonf in one SLS, you can assume ~xenophonf/.ssh/foobar => /home/xenophonf/.ssh/foobar in the other
12:27 Neighbour does salt do ~-expansion?
12:27 XenophonF I'm not sure.
12:27 XenophonF worth trying
12:27 Neighbour that would avoid the need to call user.info
12:27 XenophonF are you assuming that some wiley sysadmin will come behind you and change the user's home directory out from under Salt?
12:27 dev_tea joined #salt
12:28 XenophonF by that I mean - you're in control.  you know where ~ points ahead of time.
12:28 XenophonF why bother with the lookup?
12:28 Neighbour no, but since the ssh deployment state is generic and can be applied to multiple minions, with varying users, I don't know in advance what it'll be
12:29 XenophonF logically, I'd combine the two operations, which is how users-formula does it
12:29 fracklen joined #salt
12:29 Neighbour yea, I'm pondering on whether I should also make user-creation be pillar-driven instead of state-driven
12:29 XenophonF (I don't like dependencies crossing SLSes for this exact reason.)
12:29 Neighbour since ssh-key-generation currently is pillar-driven
12:30 XenophonF I'd definitely go with Pillar-driven.
12:30 Neighbour Well, let's give that a go then...thanks for your input :)
12:30 XenophonF but then I'm using users-formula to do this :)
12:30 XenophonF no problem!
12:31 Neighbour (it beats trying to change salt to use topfiles from CLI args :)
12:37 jas02 joined #salt
12:38 noobiedubie joined #salt
12:41 johnj joined #salt
12:46 jas02 joined #salt
12:49 _KaszpiR_ joined #salt
12:49 fracklen joined #salt
12:49 darioleidi joined #salt
12:51 impi joined #salt
12:57 usernkey joined #salt
12:59 gh34 joined #salt
13:04 mikecmpbll joined #salt
13:07 absolutejam Hey guys
13:08 absolutejam I'm trying to use the docker_events engine
13:08 absolutejam But I'm seeing no... events
13:08 absolutejam I've configured it as per the docs on my minion (Dockerh host)
13:08 absolutejam and run salt-minion -l debug
13:08 absolutejam also run salt-run state.event on my Salt master
13:09 fracklen joined #salt
13:15 JawnAuz joined #salt
13:19 impi joined #salt
13:21 fracklen joined #salt
13:22 cgiroua joined #salt
13:28 Sarphram joined #salt
13:35 Brew joined #salt
13:36 jmcknight joined #salt
13:37 edrocks joined #salt
13:38 racooper joined #salt
13:42 johnj joined #salt
13:46 mchlumsky joined #salt
13:47 user-and-abuser joined #salt
13:54 fracklen joined #salt
13:54 nethershaw joined #salt
13:57 DammitJim joined #salt
14:03 fracklen joined #salt
14:08 numkem joined #salt
14:08 _JZ_ joined #salt
14:09 _JZ_ joined #salt
14:10 Nahual Is there a reason grains/core.py for systemd-detect-virt sets grains['virtual'] to 'LXC' and virt-what returns it as it is shown as 'lxc' ?
14:10 yuhl joined #salt
14:12 vishvendra joined #salt
14:13 vishvendra Hey guys... is there any idea how to resolve "KeyError: "Returner 'mysql' does not support function prep_jid" error
14:18 fracklen joined #salt
14:22 aldevar joined #salt
14:31 peters-tx joined #salt
14:32 andr3w_ joined #salt
14:34 aldevar joined #salt
14:35 andr3w_ left #salt
14:43 johnj joined #salt
14:45 omie888777 joined #salt
14:47 jshm joined #salt
14:50 evle joined #salt
14:53 tom[] in an orchestrator sls, i need to get the stdout from a shell cmd run by a certain minion into a template variable
14:53 tom[] how to do that?
14:54 * tom[] new to orch
14:59 toastedpenguin joined #salt
15:00 toastedpenguin joined #salt
15:02 Miouge joined #salt
15:09 cyborg-one joined #salt
15:12 dxiri joined #salt
15:16 fracklen joined #salt
15:18 bstevenson joined #salt
15:20 _KaszpiR_ joined #salt
15:24 aldevar joined #salt
15:29 jas02 joined #salt
15:31 mikecmpb_ joined #salt
15:37 alvinstarr joined #salt
15:38 jas02 joined #salt
15:39 tiwula joined #salt
15:41 Brew joined #salt
15:44 johnj joined #salt
15:44 lane_ joined #salt
15:49 DanyC joined #salt
15:49 _KaszpiR_ joined #salt
15:51 major joined #salt
15:57 fracklen joined #salt
16:01 swills joined #salt
16:01 swills joined #salt
16:01 swills_ joined #salt
16:02 mikecmpbll joined #salt
16:02 SkyRocknRoll joined #salt
16:03 laertus joined #salt
16:07 _JZ_ joined #salt
16:11 swills_ left #salt
16:12 swills joined #salt
16:14 RandyT tom[]: can you give more detail about what you are trying to get from the minion? There may be a more salty way to do what you want. The shell cmd will always be tricky in my experience, especially in orchestration.
16:14 RandyT Greetings all
16:14 RandyT tryin to get ec2 information from the minion in masterless mode.
16:15 RandyT Have been experimenting with ec2_pillar, but not seeing any ec2 related data.
16:16 RandyT Have done this in the past with some contrib ec2 modules. Has anything moved more maintstream salt in the past couple of years?
16:17 tom[] RandyT: first, from the master, i need to run a custom execution module on a given minion and set its txt output into a jinja var
16:17 mikecmpbll joined #salt
16:17 daks left #salt
16:18 daks joined #salt
16:19 RandyT tom[]: I have successfully passed vars in pillar during orchestration
16:20 darioleidi joined #salt
16:20 tom[] the data i need is not in pillar
16:20 RandyT your script on the minion could put it there
16:21 sp0097 joined #salt
16:21 tom[] it's really about querying the (dynamic) state of the target system
16:21 tom[] salt 'foo' epf.active
16:21 tom[] returns the value i need
16:22 tom[] but i don't know how to get that into a jinja var in an orch sls
16:23 tom[] the salt.execute runner looks maybe relevant but it's too new
16:26 RandyT pass via 'data' in reactor?
16:26 RandyT not clear what you want to do or why you cannot pass through pillar more mine
16:26 RandyT s/more/or/
16:26 tom[] neither am i
16:27 tom[] and i don't know about reactor, but i wouldn't think my problem call for event driven stuff
16:28 tom[] i guess i don't know that you can use pillar for data transport from minion to master
16:29 RandyT just set the value in pillar from your minion and on master, use {{ pillar['var'] }}
16:30 tom[] how does a minion set a pillar value?
16:32 RandyT grains might be more appropriate with grains.setval
16:32 fracklen joined #salt
16:33 astronouth7303 `_grains` is a thing
16:33 astronouth7303 the mine might work as well?
16:33 astronouth7303 https://docs.saltstack.com/en/latest/topics/mine/
16:34 impi joined #salt
16:34 tom[] "Before adding new grains, consider what the data is and remember that grains should (for the most part) be static data. If the data is something that is likely to change, consider using Pillar or an execution module instead."
16:34 tom[] this is why i wrote a custom execution module
16:34 tom[] the data is dynamic
16:36 XenophonF joined #salt
16:38 astronouth7303 how dynamic? For example, IP addresses are in grains, even if the box is DHCP
16:39 tedops joined #salt
16:40 astronouth7303 there's a bunch of hardware information, and you can change the hardware of a minion
16:40 tedops joined #salt
16:40 astronouth7303 i think they mean more like static on the order of hours or days, not "never changes ever"
16:41 tedops happy halloween all
16:42 doubletwist joined #salt
16:42 RandyT mine is very useful for very dynamic data, like managing load balancer associations, etc.
16:42 tedops question about remote execution: is there any way to suppress "Minion did not return. [No response]" ?
16:43 astronouth7303 tedops: remote execution by what method and what frontend?
16:44 tedops astronouth7303: from the CLI on a Salt master, running 'salt', centos 7, Salt version 2016.11.3
16:45 tedops astronouth7303: "salt -l quiet -G 'roles:admin.build-host' cmd.run 'uptime'"
16:45 RandyT back to my question... any idea how to get ec2 data through native saltstack functions?
16:45 RandyT I have it working with add-on grains module in masterless, but still don't have tag info available...
16:45 johnj joined #salt
16:46 RandyT trying to figure out how to do targeting
16:46 RandyT might have to write my own minion_id it seems...
16:46 cgiroua_ joined #salt
16:46 RandyT provisioning via terraform
16:46 astronouth7303 tedops: i think that's a feature of the `salt` command. I get something different through salt-api
16:47 astronouth7303 (not actually a solution, just trying to be helpful in narrowing it down)
16:47 astronouth7303 RandyT: the ec2_pillar thing doesn't work?
16:47 RandyT astronouth7303: ec2_pillar is not providing anything...
16:47 tedops astronouth7303: ooh, yeah that is helpful...I didn't realize that existed....I'll give that a shot
16:48 RandyT have tried setting use Grains with it as well...
16:48 astronouth7303 RandyT: that's weird. It's documented to provide the tags. Run it with `-l debug` and see if it has problems?
16:49 tom[] how dynamic? i need the value now, not the value 10 minutes ago
16:49 astronouth7303 RandyT: `pillar.items` might also be helpful
16:50 RandyT astronouth7303: pillar.items not showing anything related to ec2
16:50 RandyT and when you say 'run it with -l debug' what would I be running?  pillar.items?
16:51 tedops astronouth7303: I don't think I know how to use salt-api...I'm getting 'command not found' on the master...I can dig, but if you know off-hand, can you point me to docs?
16:51 astronouth7303 yeah, looking at ec2_pillar.py, there's a ton of debug information
16:52 astronouth7303 tedops: it's usually packaged separately. It's an HTTP RPC for salt, so you can poke at the master without having to SSH in.
16:52 astronouth7303 tedops: fyi, the pillar item is `ec2_tags`
16:54 astronouth7303 err, that last one was RandyT
16:55 pbandark i am trying to create absolute path using jinja "path_join". `{% set network_data = path_join(environment_directory, environment_id, data['data']['network_name']) %}` . but, I am getting an error: "Jinja variable 'path_join' is undefined". https://paste.fedoraproject.org/paste/WwXttyWVROvzSmmh6ayCkg
16:55 RandyT astronouth7303: heading to have a look at the code. config changes in minion config seem to be ignored... note: I am masterless
16:56 astronouth7303 RandyT: i'm not familiar with masterless, unfortunately. Is the master config still distinct from the minion config under masterless?
16:56 astronouth7303 pbandark: what version of salt? That function wasn't added until 2017.7.0
16:57 pbandark salt 2017.7.2 (Nitrogen)
16:57 RandyT astronouth7303: master config is unused... there is no master
16:57 astronouth7303 pbandark: on the master or the minion?
16:57 cgiroua joined #salt
16:57 pbandark both are on same version
16:58 pbandark astronouth7303:
16:58 pbandark do you think its an syntax error ?
16:59 astronouth7303 RandyT: k, just making sure. It wouldn't surprise me if you still needed a master configuration file on the minion.
17:00 astronouth7303 pbandark: oh, it's a filter https://docs.saltstack.com/en/latest/topics/jinja/index.html#path-join
17:02 RandyT astronouth7303: walking through interactive python, boto calls are working...
17:03 pbandark astronouth7303: ok. i want to join 3 variables which will create absolute path(as mentioned in the pastebin).  is it possible ?
17:03 astronouth7303 i take it `-l debug` isn't being helpful
17:04 astronouth7303 pbandark: idk, i'm just another user and i'm on 2016.11 because i haven't had time to upgrade (and 2017.7.0 broke our deployment process)
17:04 pbandark ok
17:06 RandyT astronouth7303: might be a bug here, just figured out that if I set use_grain: True, I see the values in pillar, but not in grains
17:07 RandyT if use_grain: False, I don't see it either in pillar or grains
17:07 astronouth7303 RandyT: ... that's the point of a pillar module?
17:07 astronouth7303 that's not what use_grain means
17:07 astronouth7303 https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.ec2_pillar.html
17:08 pipps joined #salt
17:09 RandyT I've read the doc. what does use_grain mean then?
17:09 astronouth7303 > This allows the use of an instance-id grain instead of the minion-id.
17:11 RandyT I'm not setting any specific grain to use this. my point is that it is not visible in pillar unless I set use_grain: True.
17:11 astronouth7303 ok, to translate:
17:11 astronouth7303 when false, ec2_pillar only uses the minion ID to identify the AWS instance ID
17:12 astronouth7303 when true, ec2_pillar may also look in the `instance-id` grain to get the AWS ID. However, because grains are self-reported by the minion without verification from the master, this is a potential security risk
17:12 astronouth7303 either way, the results are in the pillar, not the grains, because it is a pillar module
17:13 RandyT ok, thanks for clearing that up.
17:19 nixjdm joined #salt
17:26 pipps joined #salt
17:27 bconnelly_iseatz joined #salt
17:29 bconnelly_iseatz left #salt
17:33 aldevar joined #salt
17:36 gimpy2938 joined #salt
17:36 sp0097_ joined #salt
17:37 gimpy2938 I'm trying to find a better way of targetting minions within .sls files with jinja ... any clue how I can do that?  Simple PCRE/Regex support?
17:37 pipps joined #salt
17:38 astronouth7303 https://docs.saltstack.com/en/latest/topics/targeting/index.html all are available in your top.sls files with use of a `match:`, see https://docs.saltstack.com/en/latest/ref/states/top.html#advanced-minion-targeting
17:38 gimpy2938 I'm not asking about top.sls though
17:39 astronouth7303 you don't target in state files
17:39 gimpy2938 If I don't then 90% of my .sls look the same with tiny difference between them
17:39 gimpy2938 I don't want to do that
17:39 gimpy2938 it's more templating than targetting
17:39 astronouth7303 you can set parameters via grains, pillars, or results from execution modules
17:40 gimpy2938 ... but the template needs to distinguish between different types of minion nodes
17:40 astronouth7303 you can branch on same
17:42 gimpy2938 yes I don't get it
17:43 onlyanegg joined #salt
17:44 gimpy2938 say I have a sssd.sls ... in it I say '{% if grains["id"].startswith("poop-") %}' ... all I really need to something better than startwith(), if I could just use PCRE that would work.  I use this same login within template config files
17:44 gimpy2938 s/login/logic/
17:44 astronouth7303 https://docs.saltstack.com/en/getstarted/config/jinja.html
17:45 gimpy2938 read that too, how does it apply to my question?
17:45 gimpy2938 unless you're trying to say "it doesn't say how to do it so it can't be done"?
17:45 astronouth7303 you should be using the minion ID to match pillar files to fill in data
17:46 gimpy2938 pillar files are still .sls and have the same problem
17:46 astronouth7303 you use the pillar topfile to do the matching
17:46 johnj joined #salt
17:46 gimpy2938 then wouldn't I need to split all my .sls files???
17:47 astronouth7303 depends on the nature of the data. I have some pretty repetitive pillar files for datacenter parameters.
17:47 gimpy2938 top.sls would look like "if match type A use foo_a.sls; if match type B use foo_b.sls"?
17:48 gimpy2938 if I have to do that then I may as well use different environments and really make the whole system super-redundant
17:48 gimpy2938 copies of copies of copies of .sls files, invariably getting out of sync with one another
17:48 astronouth7303 i mean, if you enjoy that level of unDRY, that's up to you
17:48 gimpy2938 that's exactly what I'm tyrign to avoid
17:49 gimpy2938 I have an unDRY way to do it now by using minion ID matching in templates, the matching just sucks and I need something more powerful
17:50 gimpy2938 node groups would be GREAT but of course you still can't use those in sls files, only top.sls...
17:50 astronouth7303 i've found the matching via pillar topfile to be acceptable
17:50 astronouth7303 there's also mapfiles, but I don't use those and don't know anything about them.
17:50 gimpy2938 but do you then have different sls files?
17:51 astronouth7303 of like 5 lines each isolated to one little thing
17:51 gimpy2938 ???
17:51 astronouth7303 use the pillar topfile to do your minion id matching, pointing to pillar sls files containing just the variant parameters
17:52 astronouth7303 for more information on what salt pillar is, see https://docs.saltstack.com/en/latest/topics/tutorials/pillar.html
17:52 gimpy2938 I don't see how that would work in my case
17:52 gimpy2938 I uses  pillars, I know them
17:53 gimpy2938 this seems like a way to really make it a mess; I would have to define soooooooo many pillars
17:53 astronouth7303 does each minion really have its own values?
17:53 astronouth7303 are there classes of minions? how many?
17:55 gimpy2938 there is a large set which are all 99% the same but need specific tweeks; then a have a separate set of minions which have a different overall config; however, both sets of nodes have a common base config too
17:55 astronouth7303 specific tweaks? you mean just specific values?
17:55 astronouth7303 sounds like you have three sets of SLS files, the common base, group A, and group B
17:55 Edgan gimpy2938: It sounds like you want defaults + pillar overrides in a predictable way
17:58 Edgan gimpy2938: https://storage.cygnusx-1.org/formula.txt  This uses a map.jinja which has defaults, integrates with your sls/formula, and pulls in overrides with the region_env_cluster part. You could make other groups, and even do it down to an exact host if you wanted.
17:58 gimpy2938 I have one set of SLS files currently
17:58 astronouth7303 break that shit up
17:58 jmedinar joined #salt
17:58 gimpy2938 I'm trying to avoid duplicating them since that;s the only solution I have really come up with
17:59 gimpy2938 then it's unDRY though
17:59 astronouth7303 i have one SLS for each daemon for each service, as well as actual application deployment
18:00 astronouth7303 broken up by service, global minion config, and some common states for daemons used across the system
18:01 Edgan I break each state/formula into init.sls(index/includes), pillars(pillar checks), users.sls(create system accounts), pkgs.sls(install debs/rpms), files.sls(create files), and services.sls(setup services). 99% of the time those are what you need, and in that order.
18:02 gimpy2938 let's step back ... say I have a config, sssd.conf ... I template the config to have the ID-based jinja I showed earlier ... that template simply changes a single line depending on whether the minion is in set A or B ... how SHOULD I do that instead without having two copies of the config each with their own single-line change?
18:03 Edgan gimpy2938: I have a sssd.conf template
18:04 Edgan gimpy2938: Looks like this, https://paste.fedoraproject.org/paste/292GT7~aet~QmRwhfgCHAg
18:04 Edgan gimpy2938: all the values come from the map.jinja, start as defaults, and can be overridden via pillars
18:04 gimpy2938 can you show where the rest of that is set?
18:04 gimpy2938 as in, where do the maps come from?
18:05 Edgan gimpy2938: https://paste.fedoraproject.org/paste/qRehp8Gv4oE~r4P9z-fNNg
18:05 Edgan gimpy2938: that would be sssd/map.jinja
18:06 gimpy2938 where do you put that file?
18:07 Edgan gimpy2938: if salt-formulas was a directory/git repo, it would be salt-formulas/sssd/map.jinja, and I do file tempaltes with full paths like, salt-formulas/sssd/files/etc/sssd/sssd.conf
18:08 cyborg-one joined #salt
18:09 gimpy2938 I'm not understanding how salt picks that up though...do you point to it in a top.sls?  is this some other thing in addition to states and pillars?
18:09 gimpy2938 ... and as such is completely separate from them?
18:10 Edgan gimpy2938: ok, connecting the dots
18:11 Edgan gimpy2938: in top.sls, you do something like, https://paste.fedoraproject.org/paste/TpTIxJ6hHpgiC56R-~yhQA
18:11 gimpy2938 pillar top.sls or ... whatever the other one is called?
18:11 Edgan gimpy2938: https://paste.fedoraproject.org/paste/Cjv2uYJfzwEvo0-ko5K7Zg  Then you create salt-formulas/sssd/init.sls like this.
18:11 Edgan gimpy2938: that is the formula/state top.sls
18:12 gimpy2938 so /srv/salt/top.sls by default?
18:12 Edgan gimpy2938: then init.sls includes files.sls, which has something like, https://paste.fedoraproject.org/paste/AADPXmZ2OkxuWX10PhGTuA
18:12 Edgan gimpy2938: yes
18:13 gimpy2938 this seems a bit complicated
18:14 gimpy2938 one file references another which references another which pulls from another ... sort of thing
18:15 edrocks joined #salt
18:19 Edgan gimpy2938: But it makes it very flexible and makes your sls files more like templates
18:19 Edgan gimpy2938: Then I can copy salt/sssd to salt/nginx, and hack it to fit nginx
18:19 Edgan gimpy2938: The files.sls above also needs, {% from 'sssd/map.jinja' import sssd with context %}
18:20 Edgan gimpy2938: at the top
18:20 user-and-abuser yep :)
18:23 user-and-abuser really like the map. the way your talking about your topography feels like microservices
18:23 Edgan user-and-abuser: I have used it with deploying microservices
18:23 _JZ__ joined #salt
18:26 pipps joined #salt
18:27 user-and-abuser Edgan very nice
18:29 gimpy2938 I think I'll just leave it alone and quit my career, much easier
18:30 user-and-abuser lol wow
18:38 tedops joined #salt
18:39 mikecmpbll joined #salt
18:40 _JZ_ joined #salt
18:47 johnj_ joined #salt
18:47 vishvendra joined #salt
18:52 XenophonF to give you a slightly different perspective, I usually recommend against using `include`
18:53 XenophonF if I were to write a mini-formula for sssd, I'd lay it out like sssd/{defaults.yaml,map.jinja,init.sls,files/sssd.conf}
18:54 XenophonF and init.sls would have (typically) a pkg.installed, file.recurse, and service.running states
18:54 XenophonF like this: https://github.com/irtnog/openssh-formula/tree/master/sshd
18:55 XenophonF I don't like decomposing SLSes such that requisites span files.
18:57 Edgan XenophonF: Sometimes you end up putting if statements around the includes. I think includes are the right way to go. My way pillars.sls, users.sls, and pkgs.sls are just macros.
18:57 Edgan XenophonF: putting the yaml in the map.jinja lets you do jinja with it, and makes the both more powerful
18:57 XenophonF oh of course I don't mean to say that you're Doing It Wrong :)
18:58 tedops left #salt
18:58 XenophonF only that I can't envision a scenario where I'd want to decouple pkg.installed, file.managed, and service.running
18:58 XenophonF There are cases SLSes I write _are_ decoupled.
18:58 XenophonF E.g., my formula for Shibboleth IdP
18:59 Edgan XenophonF: Look at the overall style in, https://storage.cygnusx-1.org/formula.txt , I think you will better understand why I break it out.
19:00 XenophonF yeah, we have completely different writing styles
19:00 XenophonF it's OK
19:00 XenophonF e.g., I prefer defaults.yaml separate from map.jinja
19:00 Edgan XenophonF: I try to pack all the "details" into the map.jinja
19:01 XenophonF what I was saying about decoupled formulas, those are cases where I expect to compose multiple formulas
19:01 Edgan XenophonF: map.jinjas do almost nothing. I don't see the point of having defaults.yaml separate. It is more powerful. Look at how I can set a name jinja variable and use {{ name }} everywhere.
19:01 XenophonF e.g., shibboleth-formula and tomcat-formula
19:03 XenophonF that's a neat trick!
19:03 XenophonF but I think it makes the formula a little harder to follow
19:03 XenophonF YMMV
19:03 Edgan XenophonF: also with salt-ssh I have to extra_refs all the map.jinjas. If It had defaults.yaml, I would have to list all of them too.
19:04 XenophonF OH
19:04 XenophonF yeah
19:04 XenophonF salt-ssh
19:04 pipps joined #salt
19:04 XenophonF man there ought to be a showcase or something where we can all post our One True Ways (LOL) of doing stuff
19:05 Edgan XenophonF: It makes it harder to follow, but I think it is getting serious about actually having formulas, and making them look as alike as possible. Which then means I can use a current one as a template for the next one.
19:06 astronouth7303 tbh, the few times i've tried to use formulas it went poorly
19:07 Edgan astronouth7303: why?
19:07 pipps99 joined #salt
19:09 astronouth7303 it varies, but i've generally found it easier to use system packages and just writing config files than to try to suss out what a formula is trying to do
19:11 Edgan astronouth7303: I still use packages, but they often do things in non-standard ways. They create their own users with random uid/gids. Sometimes they enable the service, sometimes they don't. Even if they did, maybe someone disable it, but we are trying to enforce that it is enabled and running.
19:12 Edgan astronouth7303: Also storing directory names in the map.jinja or defaults.yaml lets you reuse them in other formulas
19:12 astronouth7303 oh, i usually end up having to write service.enabled anyways because of service.mod_watch behavior
19:12 Edgan astronouth7303: One simple example would be an nginx formula that installs nginx. But then some microservice needs to drop it's own nginx.conf.
19:13 cgiroua_ joined #salt
19:13 Edgan astronouth7303: You could repeat yourself and just say /etc/nginx in the microservice sls files, but you could pull it from the nginx map.jinja
19:13 Edgan astronouth7303: Then if it ever changed, you change it in one place.
19:13 XenophonF astronouth7303: I think some formulas try to do too much
19:14 XenophonF I mean, contrast my own openssh-formula with the official one
19:14 astronouth7303 fair. so far i haven't had that problem. also, i'm not against map files, i just mean formulas in general
19:14 XenophonF plus the official one is really brittle
19:15 XenophonF try adding additional config files and stuff
19:15 XenophonF where as mine just uses file.recurse so adding stuff is easy
19:15 * XenophonF shrugs
19:15 XenophonF obviously it works well for a lot of people, hence its inclusion in the official formula repo
19:17 astronouth7303 my other problem is that there's no formula manager, so installing complex services means you have this rabbit hole of dependencies you have to traverse manually
19:17 XenophonF true but that's unavoidable
19:17 astronouth7303 for me, it was easier to use the vendor's appliance
19:17 XenophonF I think that's an acceptable choice.
19:18 * XenophonF clearly doesn't work for SaltStack's sales department.
19:18 choke joined #salt
19:18 Edgan XenophonF: The official one is more explicit. It is trying to enforce permissions on the host keys. I like it have a sub-formula for the client package.
19:19 XenophonF yes, and mine doesn't handle host keys at all (on purpose)
19:19 XenophonF I think there's room for multiple approaches even if I disagree with the others.
19:20 Edgan XenophonF: But someone could chmod -R 777 /etc and sshd would probably break
19:20 Edgan XenophonF: I don't care for their if statement happy style though
19:20 XenophonF LOL
19:20 XenophonF no kidding
19:20 Edgan XenophonF: and the set variables everywhere
19:21 Edgan XenophonF: This is what I like to concentrate all that in the map.jinja.
19:21 fracklen joined #salt
19:21 XenophonF also, contrast the sshd_config templates of the two formulas
19:21 Edgan XenophonF: Leaves the sls files way more readable
19:22 _KaszpiR_ joined #salt
19:22 XenophonF I think mine's waaaaaay easier to read even though it's pretty magical (in that it relies on defaults set in defaults.yaml and map.jinja).
19:23 edhgoose joined #salt
19:23 Edgan XenophonF: I don't care for either. My sshd_config template is just the default sshd_config with all the comments stripped out. The one advanced thing I do is, https://paste.fedoraproject.org/paste/C6Q7GX1JCq4vVIkEI8KlBw
19:24 _JZ_ joined #salt
19:24 XenophonF TBH that's completely fine
19:26 Edgan XenophonF: Part of my style is I don't try to make a formula that will cover every possible use case.
19:26 Edgan XenophonF: Because then you touch nginx or apache2 with a billion options and you will be writing that one formula for years
19:27 Edgan XenophonF: That is more the Chef style, and it is one of the common complaints.
19:29 Edgan XenophonF: I do try to use file.recurse in most cases, like you.
19:30 astronouth7303 does files.recurse generally work better than files.archive?
19:30 _JZ_ joined #salt
19:31 astronouth7303 *archive.extracted
19:31 XenophonF they do two different things so I'm not sure how to answer your question
19:31 astronouth7303 i've discovered that i can't not include `- source_hash: {{ salt.cp.hash_file(archive)['hsum'] }}` when i use archive.extracted
19:32 Edgan astronouth7303: recurse pulls from the fileserver, where as archive.extracted will extract a tar or something.
19:32 astronouth7303 you can use either to solve the "I have a bunch of files i need to get to the minion via saltfs" problem
19:32 Edgan astronouth7303: but recurse will work with templates, not just flat files
19:33 XenophonF Edgan: I'm of the 'all-or-nothing' config management style :)
19:33 astronouth7303 i'm currently using tarballs via saltfs to distribute builds from CI to minions
19:33 XenophonF ok gtg time to carve a pumpkin!
19:33 Edgan astronouth7303: I use fpm to make debs or rpms instead of tars
19:33 Edgan astronouth7303: and use pkg.installed
19:33 astronouth7303 i keep forgetting that exists
19:34 Edgan I also use salt-ssh, and use source, and salt-ssh is running on the jenkins slave, that has been passed the right packages to transfer
19:35 Edgan astronouth7303: This helps avoid the apt-get dist-upgrade or yum update breaking my package versions
19:36 Edgan astronouth7303: since the debs/rpms aren't in repositories that apt/yum know about
19:36 Edgan astronouth7303: I also store the artifacts in Artifactory, so they can be shared across Jenkins masters.
19:37 thekevjames joined #salt
19:38 astronouth7303 i'm on gitlab so that manages artifacts, but things i actually publish get copied to salt://lfs
19:38 astronouth7303 (usually salt://lfs/<deploy environment>)
19:38 Edgan astronouth7303: How does that copy work?
19:38 astronouth7303 i have a ci runner on the same box as the salt master
19:39 astronouth7303 because reasons
19:39 Edgan astronouth7303: So you need enough storage on the salt master for all that?
19:39 astronouth7303 no, builds overlap each other, so it only needs enough storage for the artifacts currently used by the environments
19:39 thekevjames Hey all! I'm just getting started with salt, so forgive me if this is a stupid question, but I think I'm missing something re: configuring custom grains (ie from salt-contrib). https://pastebin.com/1TBgjbvG
19:40 astronouth7303 eg, salt://lfs/staging/frontend.tar.xz
19:40 thekevjames Clearly the grain synced to a minion and is executable, but for some reason salt can't run it...
19:40 Edgan astronouth7303: I also like to have my deploys and salt master runs segregated. Then a deploy always runs when it should, and doesn't have to wait for the salt master to finish an existing run.
19:40 Edgan astronouth7303: so more of a sync than a copy
19:41 numkem joined #salt
19:41 ed_Goose joined #salt
19:41 astronouth7303 thekevjames: it's a python module, it needs to be a function. see https://docs.saltstack.com/en/latest/topics/grains/#writing-grains
19:41 Edgan thekevjames: What does the copy of the custom grain in your git repo look like?
19:42 Edgan thekevjames: Here is a simple custom grain, https://paste.fedoraproject.org/paste/vBORxv9a~V~U-9Hy4kWi3A
19:42 thekevjames Edgan: the gce.py file is copied from https://github.com/saltstack/salt-contrib/blob/master/grains/gce.py (unchanged)
19:43 astronouth7303 oh, yeah, my deploy step does a highstate and states handle the deploys. works pretty well for setting up new minions but definitely can have some bottlenecking issues.
19:43 astronouth7303 having a specific runner for doing the salt stuff artificially bottlenecks it in the CI queue and exposes that backup to build infrastructure, though
19:45 Edgan thekevjames: Do you maybe have a grain in /etc/salt/grains called gce?
19:45 DammitJim joined #salt
19:46 thekevjames Edgan: Just checked -- nope.
19:46 Edgan thekevjames: Grains have an order of precedence
19:46 Edgan thekevjames: what do you get for grains.get gce, if you leave the gce.py custom grain out
19:46 thekevjames Edgan: checked /etc/salt/minion as well, no dice
19:46 Edgan thekevjames: if you still get local:, you have something else setting the grain
19:47 thekevjames Edgan: do you mean if I remove the gce.py from my gitfs?
19:47 Edgan thekevjames: yes
19:47 thekevjames Edgan: one sec
19:48 Edgan thekevjames: being that the word local isn't in your gce.py, I bet something else is setting it
19:48 Edgan thekevjames: could even be another custom grain
19:48 johnj_ joined #salt
19:48 swills joined #salt
19:48 swills joined #salt
19:49 ChubYann joined #salt
19:50 edrocks joined #salt
19:50 RandyT joined #salt
19:50 RandyT joined #salt
19:50 thekevjames Huh, I can't get saltutil.sync_grains to remove the grain, though the saltmaster gitfs no longer has it
19:51 thekevjames Edgan: hmm seems you're right, still getting "local:"
19:51 thekevjames Edgan: any idea how to trace back where that grain comes from?
19:52 Edgan any other custom grains?
19:52 Edgan thekevjames: Oh, I think I see what is going on
19:53 thekevjames Edgan: a couple static ones with different names, present in /etc/salt/grains
19:53 Edgan thekevjames: salt Always say local:
19:53 Edgan that isn't a grain
19:53 thekevjames Edgan: oh shoot
19:54 MGorman joined #salt
19:54 Edgan so you aren't getting any gce grain set
19:54 Edgan thekevjames: where are you putting your custom grains in your gitfs?
19:55 MGorman Hi guys.
19:56 thekevjames states/_grains/gce.py, where the saltmaster's gitfs_root is "states"
19:56 sp0097 joined #salt
19:56 MGorman Quick question. I'm trying to figure out a way to assume an IAM role to access another account. Is this possible with just using separate keys. Specifically trying to update dns entries using boto_route53
19:57 thekevjames Edgan: on each minion, it ends up at /var/cache/salt/minion/extmods/grains/gce.py and /var/cache/salt/minion/files/base/_grains/gce.py, which is correct afaik?
19:57 Edgan thekevjames: Are you should the grain is actually gce? It looks like it is pub_fqdn_ipv4, roles, and zone
19:58 Edgan thekevjames: the file is gce,py, but that is not the name of the grains it returns
19:58 Edgan thekevjames: you could have bob.py return a alice grain
19:58 RandyT MGorman: what "keys" are you referring to specifically?
19:58 thekevjames Edgan: ... I am an idiot and you've fixed my problem
19:58 RandyT MGorman: I typically handle this by assigning a profile to the instance which has permissions to do what is needed with the various AWS service.
19:59 RandyT no keys needed
19:59 MGorman RandyT: IAM Keys. The docs show using keys for each account as profiles.. but i want to use the assume role ability in aws to jump accounts without needing AWS IAM keys for all of them.
19:59 Edgan RandyT: doesn't it just set keys for you in the metadata of the instance then?
19:59 MGorman RandyT: Yeah, I'm using instance role.. but the problem is my company has like 6 accounts
20:00 MGorman Saltmaster being in a build account, DNS i need to update being in Dev account
20:00 RandyT Edgan: yes, the keys are provided through the metadata in that case.
20:01 MGorman with aws cli, or boto, you can use the profiles from ~/.aws/credentials to switch profile and assume that other account's role.. but i don't think this is currently possible in the salt boto states.
20:01 RandyT I'm using role "jumping" in Terraform provisioning process, but I would assume that your instance would need the permissions to assign a role, which would be very powerful keys IMO
20:01 morissette joined #salt
20:01 MGorman example of assuming role : http://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html
20:02 MGorman Might just have to create a runner for this.
20:03 MGorman Just wasn't sure if i was missing something obvious
20:03 RandyT pretty sure you could provide access to the ARN for another account to manage Route53 from an assigned profile.
20:03 RandyT I've typically kept the route53 access to master only though...
20:04 MGorman Basically what i'm trying to do is have a box setup dns for its hostname. IE: {{ salt['grains.get'('id') .dev.
20:04 MGorman .root-domain.com.
20:04 thekevjames joined #salt
20:05 _KaszpiR_ joined #salt
20:05 _JZ_ joined #salt
20:05 MGorman Actually.. i think i just rubber ducked the problem.
20:06 MGorman The box just needs access to its own route53 entry, not everything in multiple accounts. I was making the incorrect assumption that it was running on  saltmaster.
20:07 swa_work joined #salt
20:09 MGorman Yeah. That worked. Its been one of those days :-) Thanks for the ears and suggestions.
20:10 numkem joined #salt
20:10 RandyT np, always helps me when I type it out in IRC...:-)
20:12 cgiroua joined #salt
20:14 MGorman Yeah.  I have a few colleagues who i often rubber duck things they don't have much input on just so i can say it out loud to realize my mistakes :-)
20:15 thekevjames Hmm I seem to have an incorrect assumption somewhere.. if I modify a map file and re run `salt-cloud -m /path/to/map`, is it not meant to modify minion grains?
20:18 RandyT MGorman: had to go look up the rubber duck reference... I had not heard that one. :-)  and I have been around a long time...
20:21 ange is there a way to ensure a !py state is run after some other states ? not sure if require_in  in states I want to run before can avoid the !py state explode because some things other states will setup haven't run yet
20:21 bildz State 'file.mkdir' was not found in SLS
20:21 bildz file.mkdir:
20:21 bildz - path: {{ programdir }}
20:21 bildz any ideas?
20:23 pipps joined #salt
20:26 sp0097 Hi there, Needed some clarification on salt-ssh.  With salt-ssh, can I define a custom execution module under /srv/salt/_modules and have it executed against a machine in the rosters?
20:29 JawnAuz bildz, I don't see that in the docs for state.file. I see file.directory - user, -group, -mode, -makedirs. https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html
20:30 sp0097_ joined #salt
20:31 onlyanegg joined #salt
20:36 sp0097_ joined #salt
20:39 sp0097 joined #salt
20:40 sp0097 Hi, With salt-ssh, can I define a custom execution module under /srv/salt/_modules and have it executed against a machine in the rosters?
20:44 Edgan sp0097: I think modules don't work with salt-ssh, but I could be wrong.
20:45 Edgan sp0097: I have one for debugging, and I remember it not working with salt-ssh
20:45 XenophonF bildz: file.mkdir is from the file execution module
20:45 XenophonF bildz: you want the file.directory state, from the file state module
20:46 sp0097 edgan: ok, phew.  I see that the standard execution modules out of the box work just fine (e.g. test.ping, etc )
20:48 Edgan sp0097: yes, test.ping works
20:48 astronouth7303 it can depend on how jinja calls them? `salt['test.ping']` will work but `salt.test.ping` won't
20:49 XenophonF those should be equivalent, astronouth7303
20:49 sp0097 edgan:  Are custom execution modules on the roadmap to be supported in the future?
20:50 astronouth7303 afaik, they're not under salt-ssh
20:50 XenophonF ah
20:50 astronouth7303 unless that's hersay
20:50 XenophonF wouldn't know
20:51 astronouth7303 (one of the reasons i use salt-cloud, not salt-ssh)
20:51 Xevian joined #salt
20:51 Edgan astronouth7303: I find salt-cloud, as is, way to limited
20:52 johnj_ joined #salt
20:52 cgiroua joined #salt
20:54 astronouth7303 Edgan: it's not great, but works well enough for me on vmware. Improving it would require improving how we do instance creation. it gets instances up and enrolled in salt, and that's really what i need it to do.
20:56 Edgan astronouth7303: I bake the salt minion into the image, and pass keys into the instance via cloud-init and user-data
20:56 pipps joined #salt
20:57 astronouth7303 oh yeah, my base image is just debian with ladvd, an ssh server, and ssh keys.
20:57 astronouth7303 i try to manage as much as possible with salt itself
20:58 Edgan astronouth7303: yeah, same here
20:58 Edgan astronouth7303: I manage salt with salt
20:58 astronouth7303 i'll probably end up doing that when i get time to upgrade to 2017.7
21:00 sp0097 We’re moving to salt w/ python3.  I have one oddball case on my dev box where I have a mac os x running 2017.7.2, but with python2.7.  Anyone have any tips to get python3 to be used by salt?  I don’t want to change the system wide default either.
21:00 XenophonF astronouth7303: my example salt-master config using salt-formula - https://github.com/irtnog/salt-pillar-example/blob/master/salt/example/com/init.sls#L234
21:01 XenophonF Is Python 3 officially supported now?
21:01 XenophonF I thought it was stille experimental.
21:02 XenophonF sp0097: which package did you use to install?
21:02 XenophonF http://repo.saltstack.com/#osx lists both a Python 2 and a Python 3 version.
21:02 sp0097 It’s working pretty well.
21:02 sp0097 I used brew install for my mac
21:02 XenophonF oh
21:02 XenophonF sorry can't help you then
21:02 XenophonF I've only ever used the official Mac package.
21:03 sp0097 if I can do it with the official, I am all ears.
21:05 sp0097 I didn’t realize there were official mac packages.  :)
21:10 pbandark hi.. using salt state module, is it possible to send data to api end point?
21:11 Edgan pbandark: it is python code, so if you mean a random non-salt api, yes
21:12 astronouth7303 pbandark: `http.query`
21:12 Edgan pbandark: if you mean _modules
21:13 pbandark Edgan, astronouth7303: i am trying with http.query. https://paste.fedoraproject.org/paste/Ap97bzrBVryhhn9KOHqljQ
21:13 pbandark is it correct ?
21:13 astronouth7303 add a `status` argument
21:13 astronouth7303 or match, something so it knows if it succeeded or failed
21:14 pbandark ok
21:15 XenophonF sp0097: official package at link above
21:15 XenophonF bundles its own python3 though, doesn't use the system's
21:15 XenophonF same as on windows, I guess
21:15 aldevar joined #salt
21:22 pipps joined #salt
21:24 thekevjames joined #salt
21:36 heaje joined #salt
21:37 sp0097 joined #salt
21:38 sp0097_ joined #salt
21:39 thekevjames joined #salt
21:41 aldevar joined #salt
21:42 RandyT on a masterless minion, is there something I can use that will force a sync_all whenever salt-call is run?
21:43 RandyT or perhaps this is accomplished by just running the sync_all once after provisioning...
21:44 zach Anyone here at SaltConf currently?
21:46 whytewolf Zach. Yeap
21:47 fracklen joined #salt
21:53 johnj_ joined #salt
21:53 Miouge joined #salt
21:55 zach whytewolf: but you don't count :-P
21:56 whytewolf Lol. I am still at saltconf. It just happens to be a job function.
21:59 zach whytewolf: lol, sorta counts
22:00 zach Good stuff so far, kind of storage format but it works
22:00 zach storage? strange
22:03 _JZ_ joined #salt
22:05 whytewolf This is just the training now.
22:11 zach yeah
22:23 vishvendra1 joined #salt
22:30 vishvendra joined #salt
22:39 pipps joined #salt
22:40 vishvendra joined #salt
22:45 dxiri joined #salt
22:53 pipps joined #salt
22:54 johnj_ joined #salt
23:01 MajObviousman joined #salt
23:07 mike25de joined #salt
23:08 mike25de hi guys
23:08 mike25de have you had issues with disabling firewalld on RHEL 7.3 ?
23:08 mike25de i am trying to disable the firewall... BUT at some point (??!!) it is still enabled.
23:08 mike25de https://gist.github.com/anonymous/b9cc3e272534516900db45b30af67235
23:09 mike25de anyone has a clue?
23:09 dxiri hello everyone, quick question! I setup a record on my dns server for salt, but after starting the minion it says: Master hostname: 'salt' not found or not responsive. Retrying in 30 seconds
23:10 dxiri dig salt on this same machine works ok
23:11 mike25de dxiri: i would try first with the /etc/hosts file ... just to make sure it works
23:14 XenophonF mike25de: you could look and see how firewalld-formula does it
23:18 dxiri mike25de: yep that works ok :)
23:19 CharlesMcLaughli joined #salt
23:20 icebal joined #salt
23:20 dxiri mike25de: not sure why it can't resolve salt though, like I mentioned, dig works fine
23:21 dxiri I would rather not have to do the hostsfile thing, the point of making the DNS resolve salt is to avoid having to set up anything in that regard isn't it?
23:24 _JZ_ joined #salt
23:33 colegatron joined #salt
23:33 mike25de true dxiri
23:33 mike25de XenophonF: thanks buddy
23:35 aldevar left #salt
23:38 aviau joined #salt
23:55 johnj_ joined #salt

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