Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-05-08

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

All times shown according to UTC.

Time Nick Message
00:00 VR-Jack however, anyone with access to node pillar data or master salt can just view the pillar in clear text. it's decrypted before sent to minion I believe.
00:00 baweaver joined #salt
00:00 enarciso but x-fer data to minion is over ssl/encrypted right?
00:01 VR-Jack yes, but then minion hold pillar data cached. in memory only I believe, but won't swear to it
00:01 enarciso ok. cool. I'll look into it. Thanks VR-Jack
00:02 mattrobenolt fwiw, the decryption happens ont he minions, not the master.
00:02 enarciso ok, that's what I thought.
00:02 VR-Jack eh? I thought the gpg key was on the master only
00:02 enarciso would that means the key file need to be in the minion?
00:03 mattrobenolt Not entirely sure, just reading the docs. :)
00:03 ChesFTC No, the decryption happens on the master I'm sure
00:03 VR-Jack pillar is master side
00:03 VR-Jack mostly
00:03 ChesFTC We don't have gpg installed on our minions
00:03 ChesFTC So it couldn't happen there
00:03 mattrobenolt The docs say that python-gnupg needs to be installed on minions.
00:03 mattrobenolt > This will apply the renderers to all pillars and states while requiring python-gnupg to be installed on all minions since the decryption will happen on the minions.
00:04 mattrobenolt Maybe that's specific if the states were gpg encrypted?
00:04 VR-Jack yeah. that's for state gpg
00:04 enarciso that sort of defeat the point of decrypting doesn't it? You want to x-fer the encrypted file over then decrypt... right?
00:04 VR-Jack states have to be done at minion
00:04 Sypher joined #salt
00:05 VR-Jack encarciso: the master is the master. it knows all. in the case of pillar, it must decrypt and load the pillar data, then send it over an encrypted channel to the minion (if access rights are met)
00:06 enarciso after much reading. it seems that's correct.
00:06 enarciso Thanks
00:07 VR-Jack also, there are people who have done some stuff with vault
00:07 enarciso VR-Jack: ? I would be interested in that :-)
00:07 VR-Jack pillars can be anything, so it wouldn't be impossible to do a pillar to a vault. Of course, it still is retrieved by the master before being sent to minion
00:08 VR-Jack well, more accurately, pillars are dicts. What returns those dicts is variable
00:08 bfoxwell joined #salt
00:09 emostar ChesFTC: I found the problem! I have two different states that are using the same pillar data. one expects a string, the other expects a dictionary
00:09 ChesFTC emostar: :)
00:09 emostar ChesFTC: thanks for you help. i ended up doing 'salt <host> pillar.items' to see the pillar data
00:09 bfoxwell joined #salt
00:10 otter768 joined #salt
00:10 ChesFTC Great - I should have suggested that - I tend to use the {{ varname }} trick when I need to see the output of a module, or something dynamically generated
00:11 ChesFTC And for whatever reason, I can't run it directly
00:13 emostar good trick to keep in the bag :)
00:15 ninkotech__ joined #salt
00:15 markm_ joined #salt
00:16 druonysuse joined #salt
00:20 forrest joined #salt
00:22 bhosmer_ joined #salt
00:26 MindDrive This is driving me nuts... I have a custom module in my base root that I use for a given application.  If it gets updated on the master, when (via a salt.client.Caller() object) I go to use it on a given host, I'd like to have the master synchronize the module - but only to that host - and then have the minion reload/refresh so it's using the new module.  Is this even possible programmatically?
00:26 MindDrive (Trying to use sync_modules() didn't work.)
00:29 VR-Jack sync_modules doesn't sync it?
00:31 MindDrive The programmatic version of sync_modules doesn't seem to allow isolating it to a specific host (it only has keyword options, none for filtering minion names) and just running it without any parameters did... nothing.
00:31 jerematic joined #salt
00:33 VR-Jack were you doing it from reactor? I think everything supports - tgt: on reactor
00:34 MindDrive I'm doing it from within a Python program.
00:35 MindDrive caller = salt.client.Caller(mopts=opts)\n    caller.sminion.functions['saltutil.sync_modules'](...)
00:38 forrest__ joined #salt
00:39 VR-Jack and it doesn't update the module?
00:40 mattrobenolt Is there a trivial way of previewing a rendered state file's yaml without running on a minion?
00:40 mattrobenolt Basically, to just run the renderer to verify some output.
00:40 MindDrive Uh, I'm pretty sure I've said it didn't, since it doesn't know what host I want to update it on.
00:40 VR-Jack http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.saltutil.html has a yaml example of module.run saltutil.sync_modules and reload_modules: True
00:41 VR-Jack MindDrive: if running on a minion, it puts it on the minion
00:41 VR-Jack if running from a reactor, tgt specifies where.
00:42 MindDrive This is not running on a minion, it's running on the master.
00:42 VR-Jack then there should be an option to specify the minion you are targetting your minion command to
00:42 MindDrive There is none.  I've already looked at the source code.
00:44 VR-Jack The module doesn't take a target. You must send the module to run on the target.
00:44 khaije|io joined #salt
00:45 khaije|io is there a (or plans for a) git-annex file backend for salt?
00:46 ageorgop joined #salt
00:47 MindDrive Obviously there's a major disconnect here, so please see: http://paste.pound-python.org/show/1odEq3zYRXWPnWC8HYtM/
00:47 smcquay joined #salt
00:48 jimklo joined #salt
00:48 MindDrive Before the caller.sminion.functions call, I need another call to ensure the 'cmd' being run (in this case 'tds.install') has its module sync'ed on the host I'm sending it to.
00:48 MindDrive (So changes are picked up if I update the module.
00:48 MindDrive )
00:48 VR-Jack MindDrive: salt.client.Caller is the same as using a salt-call. minion only
00:49 VR-Jack lookup salt.client.localclient. See example. http://docs.saltstack.com/en/latest/ref/clients/index.html#client-apis
00:49 MatthewsFace[SEA joined #salt
00:50 Berty_ joined #salt
00:52 __number5__ khaije|io: AFAIK, no
00:52 ldlework left #salt
00:53 kwmiebach left #salt
00:55 UtahDave joined #salt
00:56 druonysuse joined #salt
01:01 khaije|io copy that __number5__
01:02 I3olle joined #salt
01:05 ITChap joined #salt
01:18 otter768 joined #salt
01:19 Nazca__ joined #salt
01:22 loz-- joined #salt
01:41 UtahDave joined #salt
01:46 dendazen joined #salt
01:48 ilbot3 joined #salt
01:48 Topic for #salt is now Welcome to #salt | 2014.7.5 is the latest | Please use https://gist.github.com for code, don't paste directly into the channel | Please be patient when asking questions as we are volunteers and may not have immediate answers | Channel logs are available at http://irclog.perlgeek.de/salt/
01:48 primechuck joined #salt
01:56 ITChap hi
01:56 ITChap is there an equivalent to grains.filter_by for pillars ?
01:56 ageorgop joined #salt
01:57 ITChap I am checking the best practice doc, more precisely the part on the map.jinja files
01:57 ITChap I am trying to return different values depending the on the software version given by a pillar
01:59 VR-Jack ITChap: I don't think it has it directly, but I think you can throw it through jinja filters
02:00 ITChap yeah currently I use a load of if statements
02:00 ITChap but filter_by is really neat :)
02:01 VR-Jack none of these work for you? http://jinja.pocoo.org/docs/dev/templates/#builtin-filters
02:02 VR-Jack in particular, look at select
02:02 VR-Jack that sounds like a filter_by
02:03 VR-Jack or selectattr()
02:03 ITChap selectattr() looks like what I am looking for
02:03 VR-Jack coolio
02:03 ITChap :)
02:04 VR-Jack never used filter_by. just had to go by the name. heh
02:04 ITChap I have state for installing java and I define the java version do install in a pillar. Is it a normal way to do ?
02:04 ITChap or do you recommend something else ?
02:05 VR-Jack I definitely recommend version stuff in pillar
02:06 ITChap and where do you keep the default settings for the application ? in your states with a yaml file or in the pillars ?
02:07 VR-Jack in the yaml or in a jinja file is normal. look at the formulas
02:08 ITChap ok
02:08 VR-Jack you don't do defaults in pillar because if you move it around, the pillar may not exist
02:09 kusams joined #salt
02:09 ITChap oh I see
02:09 VR-Jack for grain differences, people usually have a map.jinja
02:09 VR-Jack you'll see that a lot in formulas
02:10 VR-Jack salt.get is common as well, because you can set a default if it fails to pull something
02:10 VR-Jack or salt[pillar.get] I guess. heh
02:11 ITChap I use the "or" in jinja for setting defaults
02:16 ITChap VR-Jack: thank you for your help
02:16 VR-Jack ITChap: glad to be of help
02:23 bhosmer joined #salt
02:26 favadi joined #salt
02:29 desposo joined #salt
02:32 penguinpowernz joined #salt
02:39 evle joined #salt
02:50 JlRd joined #salt
02:51 michelangelo joined #salt
03:00 rojem joined #salt
03:08 iamfil iggy: thanks! sorry for the late reply. I'll ask Ryan_Lane.
03:18 OnTheRock joined #salt
03:27 zz_ashmckenzie joined #salt
03:27 writtenoff joined #salt
03:33 markm__ joined #salt
03:36 Furao joined #salt
03:50 thayne joined #salt
03:52 rdas joined #salt
04:06 pdayton joined #salt
04:12 markm_ joined #salt
04:18 jalaziz joined #salt
04:19 markm__ joined #salt
04:20 Furao joined #salt
04:20 pdayton joined #salt
04:20 msn joined #salt
04:20 pdayton joined #salt
04:23 Furao joined #salt
04:23 Singularo joined #salt
04:24 bhosmer joined #salt
04:29 khaije|io left #salt
04:30 primechuck joined #salt
04:30 mosen joined #salt
04:31 pdayton joined #salt
04:33 pdayton1 joined #salt
04:36 thayne joined #salt
04:37 jhauser joined #salt
04:43 ecdhe chitown, enjoyed your saltconf15 presentation.
04:44 Furao joined #salt
04:52 jalbretsen joined #salt
04:53 hasues joined #salt
04:53 hasues left #salt
04:53 I3olle joined #salt
04:54 markm_ joined #salt
04:56 chitown ecdhe: thanks!
04:57 ecdhe You took questions about buildbot vs. jenkins, and I think you have completely the right take on that.
04:58 ecdhe My company is about the same size as yours and there are a lot of things we do that appear suboptimal... like using trac instead of the more featurful redmine.
04:58 ecdhe But the reality is, if you need to replace buildbot later, you are free to do so!
04:58 UtahDave ecdhe: so you are using buildbot?
05:00 ecdhe UtahDave, all projects this year are python only, so I'm using salt+distutils+tar.
05:00 UtahDave cool
05:00 ecdhe +vagrant for identical environments.
05:01 ecdhe I'm using trac for issue tracking because it's python.
05:01 ecdhe I would probably choose build bot because it's python.
05:01 ecdhe That is, until we outgrew it.
05:06 ecdhe UtahDave, I've been using salt to manage embedded environments.  I would love to present at saltconf but I probably don't have enough material to do more than a lightning talk...  do you think anyone would be interested?
05:07 UtahDave ecdhe: Yeah, I think that would be a terrific talk.
05:09 ecdhe UtahDave, I appreciate the encouragement, perhaps I'll propose a talk for next year.
05:09 saffe joined #salt
05:09 UtahDave Yeah, please do!  I think that would be quite interesting
05:10 UtahDave I've noticed that many people underestimate others' interest in what they
05:10 UtahDave ... in what they are doing
05:10 MaliutaLap joined #salt
05:10 MaliutaLap left #salt
05:12 markm__ joined #salt
05:15 ecdhe UtahDave, can I ask what's got you on irc at this hour?
05:15 UtahDave :)  Just double checking that my presentation is ready for tomorrow.
05:16 UtahDave I'm speaking at OpenWest tomorrow morning.  demoing beacons, reactor, salt-api, etc
05:16 UtahDave I like to live demo stuff.  :)
05:17 ecdhe Cool!
05:18 ecdhe I'm writing code for a product-to-be that needs to be demo'd to a customer in a few days...
05:18 ecdhe It's kinda crunch time, but between salt and python3 on linux, I definitely enjoy the work.
05:18 Fiber^ joined #salt
05:18 ecdhe Hope your presentation goes well!
05:19 UtahDave thanks!
05:19 UtahDave you, too!
05:19 UtahDave I better get some sleep.  Catch you tomorrow!
05:19 ecdhe adios!
05:20 UtahDave chao
05:22 und1sk0 joined #salt
05:22 st_iron joined #salt
05:30 pdayton joined #salt
05:30 MaliutaLap joined #salt
05:33 clintberry_1 joined #salt
05:33 loz-- joined #salt
05:34 I3olle joined #salt
05:35 st_iron joined #salt
05:47 MaliutaLap joined #salt
05:47 MaliutaLap joined #salt
05:49 otter768 joined #salt
05:58 MaliutaLap joined #salt
05:59 joeto joined #salt
05:59 kawa2014 joined #salt
06:06 kusams joined #salt
06:08 nikboo joined #salt
06:09 teogop joined #salt
06:12 AndreasLutro joined #salt
06:16 MaliutaLap left #salt
06:16 flyboy joined #salt
06:25 bhosmer_ joined #salt
06:29 zer0def joined #salt
06:30 trikke joined #salt
06:30 yuhl_work_ joined #salt
06:31 jerematic joined #salt
06:32 colttt joined #salt
06:37 soren_ joined #salt
06:42 markm_ joined #salt
06:43 colttt joined #salt
06:44 balltongu joined #salt
06:44 trikke joined #salt
06:48 Grokzen joined #salt
06:54 egil joined #salt
06:58 dkrae joined #salt
06:58 lb1a joined #salt
07:08 kusams joined #salt
07:11 MatthewsFace[SEA joined #salt
07:14 salt-n00b joined #salt
07:18 Auroch joined #salt
07:20 einyx joined #salt
07:22 supersheep joined #salt
07:35 wvds-nl joined #salt
07:50 fbergroth joined #salt
07:50 otter768 joined #salt
07:50 jakubm morning
07:51 jakubm anyone is using git as an ext_pillar by any chance?
07:52 jakubm and could share a snippet from his config?
07:52 jakubm also regarding states in git: did i understand correctly - can you only have top.sls in one branch?
07:56 supersheep joined #salt
08:00 KermitTheFragger joined #salt
08:00 JayFK joined #salt
08:07 flyboy joined #salt
08:11 crashmag joined #salt
08:13 Grokzen joined #salt
08:16 al joined #salt
08:20 PI-Lloyd jakubm: set ext_pillar: to - git: <branch> <git url:repo>
08:20 mage_ hello, I have dozen of small (python) webapps running under a dedicated user, dedicated virtual env, requirements.txt, etc. How would you organize this ? One pillar which list all webapps with this, or one pillar with users, one with venvs, etc .. ? same for my state files: one per webapp or one for the users, one for the venvs, etc .. ?
08:21 Xevian joined #salt
08:21 PI-Lloyd mage_: the way we do it is to split users into a 'core' state that gets applied to all systems
08:21 PI-Lloyd then have seperate states for each role/app
08:21 babilen gah, salt-bootstrap broken again :(
08:21 PI-Lloyd the pillar is structured the same way
08:22 PI-Lloyd babilen: well that's not ideal :(
08:22 mage_ so one users.sls state file ?
08:23 csa_ joined #salt
08:23 AndreasLutro mage_: I do something similar, and have one pillar .sls for each app, and they all add stuff to different dicts like uwsgi_apps, nginx_vhosts, pg_databases
08:24 mage_ AndreasLutro: can you pastebin an example .. ? :)
08:24 PI-Lloyd mage_: we actually split the users right down into multiple state files as we have different groups and roles
08:24 mage_ yep I have webapps users but also "core" users
08:24 AndreasLutro mage_: https://bpaste.net/show/a96c2cce00f6
08:24 mage_ so one users/init.sls with two includes (webapps.sls and core.sls)
08:25 mage_ AndreasLutro: thank you!
08:26 bhosmer joined #salt
08:28 mage_ in fact it doesn't matter that much how the pillars data are organized as long as the states files are modularized enough, right ?
08:28 AndreasLutro kinda
08:28 AndreasLutro as a developer, I think of states as functions and pillars as function arguments
08:29 AndreasLutro but often your different states need to "communicate" which complicates things
08:29 AndreasLutro anyway this approach has worked for me
08:29 mage_ ok :)
08:31 chiui joined #salt
08:33 jakubm PI-Lloyd: yeah i did for some reason it didn't work. I tried going with __env__ and {{env}} there as well, I specified all my envs under ext_pillar like Jeff did (vide his email on salt-users) but nothing worked. I cleaned up all the cache and stuff. For now we will stick to flat files and maybe trigger repo update on certain events
08:34 CeBe joined #salt
08:36 PI-Lloyd jakubm: https://bpaste.net/show/62af51ce9024 - this is the master config we currently use... our git URL is set in ssh config
08:38 PI-Lloyd also need to make sure python-git package is installed afaik
08:39 PI-Lloyd oh and make sure the user that salt is running as has the host key for the git url accepted... that one bit me early on
08:43 balltongu joined #salt
08:55 yuhl_work_ joined #salt
08:57 kusams joined #salt
08:58 yuhl_work_ joined #salt
09:00 multani joined #salt
09:01 babilen Is there a way to specify different versions of the bootstrap script (I want to use an older one) ?
09:02 toanju joined #salt
09:12 PI-Lloyd babilen: could you not pull a different branch from the github page?
09:13 stoogenmeyer_ joined #salt
09:14 agend joined #salt
09:14 supersheep joined #salt
09:15 multani is there an equivalent to the execution module cp.list_file, but for pillars? I'd like to get the list of 'pillar files', so in my pillar/top.sls file I can 'include' a pillar file only if it exists
09:18 inad922 joined #salt
09:19 bluenemo joined #salt
09:19 bluenemo joined #salt
09:23 ildiroen joined #salt
09:24 fredvd joined #salt
09:25 babilen PI-Lloyd: I can't really do that as vagrant seems to just pull the script from https://bootstrap.saltstack.com
09:26 babilen I only found documentation on how to select different versions of salt, but that script is causing me a lot of headaches in the last couple of days and I have better things to do than fixing those bugs
09:26 babilen (right now)
09:26 babilen s/better/more important/
09:26 PI-Lloyd ^^
09:28 AndreasLutro babilen: I think the first argument to the .sh script can determine the version you want to install
09:28 sdfgsdfhg joined #salt
09:28 PI-Lloyd thats the version of salt, not the version of the bootstrap script
09:28 AndreasLutro oh wait you mean getting an older version of the bootstrap script itself
09:29 PI-Lloyd the only older version i can find is 2 years old which is on the github page, i'm just trying to find out where our vagrant setup gets the bootstrap from
09:29 AndreasLutro if you use config.vm.provision :salt I think it just fetches the latest version
09:30 AndreasLutro you could change that to a shell provisioner that manually installs salt
09:30 VSpike well, that's just wierd. the lvm.vg_present state says devices is "A list of devices that will be added to the volume group". Turns out it means a comma separated string, not an actual list
09:30 PI-Lloyd well that's exactly what our vagrant file uses (:salt), and it works fine....
09:30 VSpike There seem to be a lot of little oddities like that in salt
09:34 AndreasLutro actually I might be wrong, vagrant docs imply that it installs from the distro's package manager
09:34 AndreasLutro hm
09:34 favadi joined #salt
09:34 elfixit joined #salt
09:35 PI-Lloyd not strictly true as you can set config.install_type to specify a version
09:35 PI-Lloyd for example we install the v2015.5.0 tag
09:35 babilen Yes, but that still uses the current version of the bootstrap-salt.sh script.
09:36 babilen I don't want to install a different salt version, but I want to use a different bootstrap script version. It has been buggy/problematic in the last couple of days and I simply wanted to know if there is a way to get a different version.
09:37 PI-Lloyd not that I know of
09:37 AndreasLutro doesn't look like it
09:37 PI-Lloyd I've not encountered any issues with the bootstrap itself, i've just provisioned several vagrant boxes fine using that bootstrap and different salt versions
09:37 babilen https://github.com/saltstack/salt-bootstrap/issues/598
09:40 mage_ is it possible to include a state file in another state file without "executing" it ?
09:40 babilen no
09:40 babilen But there might be other ways to achieve what you are actually trying to achieve.
09:41 mage_ ok, so it's impossible to have a - require: - user: foo which is include in users.sls without adding _all_ users in thise sls ?
09:41 toanju joined #salt
09:42 peters-tx joined #salt
09:42 mage_ for ex I have the following https://dpaste.de/5TjQ
09:42 mage_ so at line 14 a require: user: ...
09:43 mage_ and this user is in the users.webapps sls, but there are also other users in this file, and I would like to add only the required user (is missing) instead of all
09:43 keimlink joined #salt
09:44 mage_ too bad it's impossible to do a - require: - user: users.webapps:someuser
09:48 babilen mage_: Why is it a problem to create all those users?
09:50 mage_ babilen: not really a problem, just a thing a wondered
09:50 babilen But you have multiple options: 1. Use a single file for each user which allows you to include users.foo and users.bar 2. Use the users-formula to create only those users you *actually* want and compose/merge your pillar from multiple files that you include (cf. https://github.com/saltstack-formulas/users-formula)
09:50 trikke joined #salt
09:51 otter768 joined #salt
09:51 mage_ yep the single file approach is fine, but then you loose all the flexibility of templating and for loops :)
09:51 babilen I would recommend the latter. That allows you to include "- users" which will have been filled with all the applicable users and you can then ship additional pillars with different parts of your setup that will, in the end, be merged into one large "users: .." pillar
09:52 VSpike My lv_present state is failing every time. Am I doing something daft? https://bpaste.net/show/b230ef74d6de
09:52 mage_ I'll think about it .. thanks
09:52 VSpike log output https://bpaste.net/show/b9c6d1a9f08c
09:52 VSpike Doesn't even look like it's trying to create it
09:54 VSpike "sudo salt-call lvm.lvcreate lvdata vgdata extents=100%FREE" works fine on the minion
10:05 giannello joined #salt
10:10 Furao joined #salt
10:11 keimlink joined #salt
10:13 ponpanderer joined #salt
10:25 inad922 joined #salt
10:26 bhosmer joined #salt
10:29 mage_ do you use Orchestration ? when to use it ?
10:33 giantlock joined #salt
10:33 joeto Hi all, is it possible to use pillar data from one pilar to another one?
10:36 ntropy joeto: only with external pillar i believe
10:37 Furao joined #salt
10:37 joeto actually it is Will check now :)
10:38 mage_ joeto: you can include a pillar in another pillar
10:38 mage_ but be carefull with the namespaces merges
10:40 c10_ joined #salt
10:42 joeto ok I am tring to do following : in one pillar I have some data and want to manage one variabl in another pillar so I do not need to modify sls files (they are universal for now) looks like this fails:
10:42 joeto tag: {{ pillar['ec2-global-conf']['EC2_ACCOUNT_ID'] }}
10:43 joeto tag is much more longer I cut it :)
10:43 AndreasLutro joeto: which version are you using? I think I do that in 2015.5
10:43 AndreasLutro and it works
10:43 joeto 2014. latest stable :(
10:44 rofl____ :(
10:44 rofl____ 2015.5 planned release soon?
10:44 AndreasLutro it's been released
10:44 babilen rofl____: It has been released already
10:45 joeto 2015??
10:45 babilen (there simply aren't packages for all distributions/operating systems yet)
10:45 rofl____ babilen: whaaaat
10:45 joeto aaa :D
10:45 rofl____ oh
10:45 babilen joeto: 2015.5, yeah
10:45 joeto hmmm
10:45 joeto :D
10:46 kusams joined #salt
10:46 joeto http://docs.saltstack.com/en/latest/ still saying latest stable is 2014 :)
10:47 joeto ok, will try next week :)
10:47 AndreasLutro I'm just going off this https://github.com/saltstack/salt/tags
10:47 AndreasLutro I've been running from source for months anyway
10:47 mage_ can I use jinja template inheritance with salt ?
10:47 AndreasLutro mage_: yes
10:47 mage_ cool
10:51 sfxandy joined #salt
10:51 sfxandy morning all
10:52 Guest41113 nick sfxandy
10:52 Guest41113 left #salt
10:59 lietu joined #salt
11:04 rogst joined #salt
11:06 jakubm PI-Lloyd: thanks for the code snip!
11:08 toanju joined #salt
11:34 JDiPierro joined #salt
11:44 PI-Lloyd jakubm: no worries, hope it helps
11:46 ScrumpyJack joined #salt
11:52 otter768 joined #salt
11:56 inad922 joined #salt
12:14 kusams joined #salt
12:21 bastion1704 joined #salt
12:24 jonatas_oliveira joined #salt
12:27 giannello joined #salt
12:29 subsignal joined #salt
12:31 I3olle joined #salt
12:35 bhosmer joined #salt
12:47 cmcmacken joined #salt
12:47 bhosmer joined #salt
12:50 mage_ what do you think of the following: https://dpaste.de/FYxC ?
12:50 mage_ it seesm the best for modularity and templating, no ?
12:51 bhosmer_ joined #salt
12:57 tmclaugh[work] joined #salt
12:57 Berty_ joined #salt
13:00 JDiPierro joined #salt
13:00 Andre-B joined #salt
13:04 jdesilet joined #salt
13:05 bhosmer joined #salt
13:07 _prime_ joined #salt
13:10 dyasny joined #salt
13:10 mapu joined #salt
13:12 pdayton joined #salt
13:13 babilen mage_: https://github.com/saltstack-formulas/users-formula + https://github.com/saltstack-formulas/users-formula/blob/master/pillar.example
13:14 giantlock joined #salt
13:15 Deevolution left #salt
13:15 Deevolution joined #salt
13:19 mage_ babilen: yep I've read that
13:19 mage_ but it's not so flexible
13:20 cpowell joined #salt
13:21 Tyrm joined #salt
13:21 mage_ as if a sls requires a user you have to include the whole user sls
13:21 mage_ with my example you can include user.specific_user
13:22 mage_ I find it more modular
13:24 steffo joined #salt
13:26 toanju joined #salt
13:26 TooLmaN joined #salt
13:27 _mel_ joined #salt
13:31 babilen mage_: What's the problem with including the whole user sls?
13:31 babilen The modularity is in the pillar in that case rather than the states (which are generated from pillar data)
13:32 primechuck joined #salt
13:33 inad922 joined #salt
13:33 babilen You would simply include all states for users that are being created *anyway*. I find that quite wonderful and don't understand why you are not happy about it too ;)
13:34 racooper joined #salt
13:38 timoguin joined #salt
13:39 mage_ babilen: maybe I'm too "perfectionnist", but when I, for example, want to regenerate a virtualenv which require a specific user with salt somemachine state.sls venvs.python.myvenv I find it strange to include users which have nothing to do with the venvs actually, as it require only *one* user
13:39 plindgren joined #salt
13:40 plindgren Hello Partypeople!
13:40 plindgren Can i in one state run against one minion require a state that needs to be run on another minion?
13:41 ksj is there a way to list what files the saltmaster is serving? I'm having trouble with gitfs not finding a top file, and I want to understand what salt is seeing
13:41 plindgren so state 1 runs on minion 1 then state 2 on minion 2 requires state 2 requires state 1
13:42 plindgren sorry i wrote that ^
13:42 plindgren wrong
13:42 plindgren The state 1 on minion 1 runs, then state2 on minion2 requires state 1
13:42 oravirt joined #salt
13:42 plindgren thats what i need to achieve
13:43 murrdoc joined #salt
13:43 pedromaltez joined #salt
13:43 markm_ joined #salt
13:45 perfectsine joined #salt
13:47 hasues joined #salt
13:47 hasues left #salt
13:48 tzero joined #salt
13:49 PI-Lloyd ksj: take a look in /var/cache/salt/master/gitfs/refs/base
13:50 murrdoc joined #salt
13:51 plindgren screw it
13:51 plindgren ill just redesign the whole thing
13:51 plindgren i got into this situation by bad design on my part imo
13:51 kaptk2 joined #salt
13:52 emaninpa joined #salt
13:52 otter768 joined #salt
13:53 kusams joined #salt
13:54 ksj PI-Lloyd: I rm -r /var/cache/salt every time I restart to try to ensure it's getting the latest git.
13:55 ksj basically I copied /srv/salt to my git repo, with /salt/srv prepended. so I have no idea why http://dpaste.com/24TYGBX isn't working. Salt definitely has access
13:56 ksj i.e. under my git repo, /salt/srv/top.sls is a top file that works locally, and all the necessary files are there#
13:57 PI-Lloyd - root: salt/srv might have something to do with it if they are in /srv/salt
13:57 whytewolf plindgren: sounds like you have what the orchestration runner was created for. running states across different minions that require each other
13:57 PI-Lloyd nvm ignore previous didn't read your comment properly
13:58 Andre-B joined #salt
13:58 PI-Lloyd I would take a look in the path i mentioned before you delete it again just to see what the master is trying to grab
13:59 PI-Lloyd so restart the master, give it a few mins to grab what it needs and take a look..
13:59 PI-Lloyd also check the master log for any errors ;)
14:03 rojem joined #salt
14:04 catpig joined #salt
14:05 rojem joined #salt
14:07 APLU joined #salt
14:07 ksj PI-Lloyd: thanks. I don't have a "refs" dir. by "refs" did you mean the random hash?
14:07 murrdoc joined #salt
14:08 amcorreia joined #salt
14:10 andrew_v joined #salt
14:11 matthew-parlette joined #salt
14:15 johndeo joined #salt
14:17 thayne joined #salt
14:17 PI-Lloyd no there should be a hash and a refs directory afaik
14:17 murrdoc joined #salt
14:18 PI-Lloyd anything in the master log to indicate any issues?
14:18 murrdoc keeps saying 'upgraayyed'
14:18 murrdoc not sure what that means
14:19 ksj ...yeah...I can't figure out what the hell's wrong with it. it's authenticating. it's getting the git repo, but it's not getting anything IN it. it's a private github repo....if that matters. the key it's using definitely has access though
14:20 Heartsbane joined #salt
14:22 StDiluted joined #salt
14:24 timoguin joined #salt
14:25 PI-Lloyd have you added the host key to the known_hosts file on the master?
14:25 PI-Lloyd actually you must do if it's getting the repo
14:26 iggy ksj: if you mean there's nothing in it as in you looked in the cache dir and it doesn't have the files checked out, that's normal
14:27 cpowell does anyone have a good explination of using multiple environments in your pillar?
14:28 clintberry_1 joined #salt
14:29 murrdoc joined #salt
14:30 Grokzen joined #salt
14:31 evle1 joined #salt
14:31 ksj iggy: ok, so in the directory /var/cache/salt/master/gitfs  I have a long hash directory, an envs.p file, and a remote_map.txt. the hash directory has a .git directory, but no files.
14:32 timoguin ksj: they're just not checked out. you should be able to see the log with git log
14:32 ksj it's checking out the full (480) files via git that it does when I do a git clone
14:32 ksj if I do a git log in that directory, I get fatal: bad default revision 'HEAD'
14:33 ksj ...by the way, I'm really new to git, if that wasn't obvious
14:33 VR-Jack cpowell: same as state? The usual method is to do a series of overrides, where qa includes and overrides base, dev might include and override base and qa.
14:33 timoguin ksj: are you just trying to see all the files or what?
14:34 VR-Jack if doing environments in state, obviously you might need different pillar formats to support the differences in state files.
14:34 ksj timoguin: I have pushed my (working) salt state configureation to github. I've correctly set up the master to use git (it definitely authenticates correctly), but it can't find a top file
14:34 cpowell VR-Jack: I understand the concepts and its what I want, I can find docs on the environemnts. But I want to know specifically how the overrides work
14:34 keltim_ joined #salt
14:34 ksj it's driving me crazy. I'm seriously close to spazzing out
14:35 ksj .....too much coffee I guess
14:35 timoguin ksj: `git checkout master` will check everything out so you can look at it
14:35 Brew joined #salt
14:36 timoguin also git ls-files
14:36 iggy ksj: it's normal for there not to be any files in there
14:36 iggy in the .git directory, there will be the raw objects
14:36 ksj timoguin: the repo is fine. i can do a git clone, change my salt master to local, and get a working set up
14:36 VR-Jack cpowell: goes in order according to how you listed the paths in the config. you'd have to test pillar overrides. It should be file based, but pillar merging might change that
14:36 ksj iggy: yeah, there are the raw objects there for sure
14:37 timoguin yea, the master doesn't need the working directory, just the all the commit metadata
14:37 ksj but why won't it see my damn top file....or any file. that's what I originally asked here - if there's a way to browse the fileserver to see what salt sees
14:37 iggy ksj: check 'salt-call cp.list_master'
14:38 timoguin also `salt-run fileserver.file_list` on the master
14:39 fyb3r joined #salt
14:39 ksj thanks....that's what I was looking for, probably. unfortunately both commands give me nothing
14:39 ksj actually salt-call just gives me 'local:' - nothing more
14:41 murrdoc salt-call config.get fileroots
14:42 iggy oh, wait a minute
14:43 iggy config.get gitfs_provider
14:43 jimklo joined #salt
14:44 VR-Jack cpowell: actually, the merging code wouldn't have an effect. environments is strictly a file selection process. so state or pillar, the sls selected is based on the environment listed in the config. Lane has a blog post on it
14:44 cpowell VR-Jack: would you happend to have a link?
14:44 ksj fuck git, frankly. I'm going back to doing everything locally. I've wasted three hours with this crap.
14:45 cpowell basically what I am trying to have is a single file_roots and then to control it via different pillars
14:45 cpowell and somehow have a defaults.sls in there so if its not found it pulls it from there
14:47 rojem joined #salt
14:47 matthew-parlette joined #salt
14:48 I3olle joined #salt
14:50 scarcry joined #salt
14:51 favadi joined #salt
14:51 VR-Jack cpowell: I was wrong. environments is in the tutorials. The environment option is strictly so you can have duplicate files. The first "match" for a file wins
14:52 VR-Jack if you're not doing duplicate files, there is no reason to use environments
14:53 VR-Jack well, the other benefit for states alone is you can restrict access to certain files.
14:53 cpowell we want the flixiblity of using duplicate files if needed, but at the same time have sane defaults if its not found
14:54 cpowell maybe I am overclomplicating things
14:54 VR-Jack http://docs.saltstack.com/en/latest/topics/tutorials/states_pt4.html covers multiple-environment. where you'd have a base, qa, and dev.
14:54 VR-Jack defaults for pillar should always be in the state files themselves.
14:54 iggy cpowell: with environments, the "base" environment is basically your catch-all
14:55 iggy ksj: well, next time give up before you waste our time trying to help you
14:56 dariusjs joined #salt
14:56 cpowell here is an example, an application has an api endpoint. This endpoint is different for Prod/Staging/Dev and is different base on the datacenter location
14:56 VR-Jack pillar merging/overriding allows you to extend or overwrite values without bothering with environments. Environment for pillar is "load this hosts.sls instead of that other hosts.sls file" useful for major changes in data structure
14:56 cpowell same state formula, just different pillar data
14:56 ksj iggy: sorry, didn't mean to seem ungrateful. thanks a lot....just tired and frustrated
14:57 martoss joined #salt
14:57 VR-Jack cpowell: if you are sure the states never change, you can just specify matching in pillar top.sls and point to different files.
14:57 iggy ksj: if you ever decide to come back to it, make sure you are using pygit2, gitpython doesn't support the extra options the way you have them specified
14:58 ksj yeah, it's pygit2
14:59 VR-Jack with environments, you can do it similar to that link I posted above. it allows for individual file overrides using environments. works for pillars the same as file_roots.
14:59 cpowell ok, I will re-read it. Thanks
15:00 VR-Jack file overrides are useful for dev/qa/prod as you may be changing the state code and the entire pillar layout. If you are just setting different values, a normal pillar with node matching and pillar merging/overriding works fine.
15:01 gladiatr joined #salt
15:01 cpowell so how does the pillar merging/overriding work?
15:01 sandah joined #salt
15:01 Fiber^ joined #salt
15:02 cpowell you have the same pillar key in two sls's and the top most wins/
15:02 murrdoc depends on the merging strategy u pick
15:02 cpowell ok, the default is 'smart'
15:02 cpowell I read that
15:02 murrdoc yup
15:03 murrdoc also use salt 'minionname' pillar.get key:key2
15:03 murrdoc to see how the merging happens
15:04 conan_the_destro joined #salt
15:05 VR-Jack The rule is that dicts merge and lists override
15:05 mpanetta joined #salt
15:05 bhosmer joined #salt
15:05 murrdoc + " in smart mode "
15:06 VR-Jack ^^^
15:06 murrdoc i find it pretty powerful
15:06 VR-Jack I use it a lot
15:06 murrdoc but lotsa people dont find it sufficient
15:06 mpanetta joined #salt
15:07 andrew_v For salt commands that hit multiple servers, is there a way to sort the output by minion ID?
15:07 murrdoc reclass does it more inheritance-y, and stuff, might be good for your use case
15:07 VR-Jack For example, I have a bunch of users.sls. A base (for all), and then company, server type, and finally individual servers.
15:07 VR-Jack it merges all the users into a single set.
15:07 cpowell right
15:08 VR-Jack or in some cases, I override a user's settings. different password, different key, etc.
15:08 VR-Jack that's how I found that lists override. I tried to add a group in - groups: and it only included the one.
15:11 VR-Jack where environments are useful is full file overrides. So that dev starts out the same as prod, but as you put in new files, it changes.
15:11 murrdoc does it ?
15:11 murrdoc i havent checked environments in a while
15:11 VR-Jack if you include multiple directories for each environment, yes
15:11 murrdoc there was a nasty bug in them
15:11 VR-Jack first file found wins
15:11 murrdoc so i stopped looking
15:12 cpowell right, if it finds a file match, it takes the top most match
15:12 VR-Jack yeah. that tutorial shows that well
15:12 VR-Jack pillar_roots works the same as file_roots
15:12 cpowell I think I want what the state exmple show, but for pillars
15:12 ndrei joined #salt
15:13 VR-Jack it's important for "dev" as you might be rewriting the entire state file and referencing a different pillar format (I didn't like how I did - groups: in my users pillar)
15:14 VR-Jack vice versa, of course. if you change the dicts/list layouts in pillars, the jinja in states will also have to change.
15:15 VR-Jack once everything is how you like it, you copy the files to the qa/prod environment and delete it from dev.
15:17 VR-Jack that being said, many people just do multiple masters and copy things around rather than deal with environments
15:17 matthew-parlette joined #salt
15:17 cpowell environements for us are not so much for salt testing and application
15:17 VR-Jack or use hg/git and pull the correct branch to the correct master
15:17 cpowell * but for applications
15:18 murrdoc so scary
15:18 VR-Jack for applications, you can just use pillar's top file to match and dictate which parts of the pillars a node gets
15:18 cpowell so single top.sls and just have different matchers
15:18 cpowell and defaults in base
15:19 VR-Jack yes, that's how pillar differs from file_roots
15:19 VR-Jack if a minion has access to a file_root environment, it can run an sls there.
15:19 VR-Jack pillars only send data to a minion that matches for that data in the top.sls
15:20 cpowell and you can have muliple matches in the top
15:20 cpowell so match '*' and 'api*'
15:20 cpowell and get both sets of pillars?
15:20 murrdoc there is a completely opposite way of doing this
15:21 murrdoc if u have a unique identifier for the server
15:21 murrdoc say a role or something
15:21 VR-Jack cpowell: Here's a simple into complex example https://gist.github.com/anonymous/a885fb6257786f6c39ec
15:21 murrdoc u could put all the pillars for a server in its unique role pillar
15:21 murrdoc stupidly simple
15:22 murrdoc especially if u only use formulas
15:22 VR-Jack the top.sls I gave sends hosts and auth-common to every minion. Only minion names ending in -paradox get paradox.auth data
15:22 cpowell gotcha
15:22 VR-Jack The last one is some wacky jinja that loads a pillar sls file and creates a host-* match for any host that had a type: vmhosts and gives it vmhosts.iptables
15:23 cpowell murrdoc: I am evaluating that method now
15:23 VR-Jack that jinja is a test, though. don't recommend it.
15:23 murrdoc cpowell:  i use that method right now
15:23 murrdoc all formulas have their defaults.yml, that get overriden a pillar
15:24 murrdoc so a servers pillar file, is basically overrride for defaults on formulas and any thing else that is relevant
15:24 murrdoc look at a file, know what a server looks like
15:24 big_area joined #salt
15:24 VR-Jack the only sticky point you have to watch for is that your decisions are based on master information only. things like grains can be compromised if a user can modify the minion config
15:25 VR-Jack that matters if you're managing a minion that has alternative management.
15:25 cpowell VR-Jack: understood, I will be matching using nodegroups
15:25 jimklo joined #salt
15:26 VR-Jack I find most people just use lists matcher over nodegroups. less master config changes
15:26 cpowell I want to be able to change our naming convention if we hate it
15:27 VR-Jack Can be simplified with a small amount of jinja. Create a jinja variable with your list, then punch it into the various places in top.sls you need it.
15:27 VR-Jack basically, a jinja equiv of nodegroups
15:28 debian112 joined #salt
15:29 Auroch joined #salt
15:29 VR-Jack in fact, my little test top.sls will eventually be a node list builder for a yaml file. So I can create lists for the various "types" of hosts. Then reference those lists in the top.sls
15:30 VR-Jack the test was just to learn how to load and access the yaml file
15:32 yuhl_work_ left #salt
15:32 yuhl_work__ joined #salt
15:33 mage_ with {% from "users/webapps/map.jinja" import default with context %} what does the "with context" means ?
15:34 murrdoc parse the template, with all available information and then setup the variable and then pass iit back to use in this tempalte
15:34 mage_ and without context .. ?
15:35 * murrdoc shakes 8ball
15:35 mage_ so if a variable is defined in both templates "with context" will overwrite it ?
15:36 SheetiS "with context" is a Jinja thing.  You can read about it specifically here: http://jinja.pocoo.org/docs/dev/templates/#import-context-behavior
15:36 VR-Jack if the variable requires processing to setup you need context. ie, if you must run jinja or salt commands etc for the variable to be assigned
15:36 murrdoc the included variable will be used
15:37 mage_ mmh
15:37 VR-Jack it's a question of if we pull it local, or run it in place and then pull it.
15:37 mage_ so basically we always need "with context" with salt if I understand well ?
15:37 VR-Jack not necessarily
15:38 iggy sometimes you don't need or want the context
15:38 VR-Jack if it's simple as in a static declaration of the variable you don't need with context. Or if you are pulling in a macro that you want to activate locally, you wouldn't use in context
15:39 VR-Jack if you did in context with a macro, the macro would be preprocessed before being imported
15:39 VR-Jack that could be bad
15:39 mage_ I have some difficulties to undersand what is the "context"
15:39 VR-Jack context is what happens when you process the original file
15:39 mage_ (first time I user jinja)
15:39 mage_ ok
15:40 mage_ so with context = preprocess the template before it's being imported and without context = don't preprocess ?
15:40 VR-Jack that's my understanding, yes
15:40 mage_ thank you :)
15:41 iggy context is things like {{ salt }} {{ grains }} {{ pillar }}, etc.
15:41 iggy and anything you've {% set %}
15:42 mage_ okay
15:42 VR-Jack macros and static declarations are usually pulled without context
15:42 VR-Jack well, macros can go either way, technically
15:44 murrdoc those macros, so naughty
15:45 rojem joined #salt
15:45 spiette joined #salt
15:45 iggy ^
15:45 iggy just use #!py or something if you need functions
15:53 otter768 joined #salt
15:55 timoguin_ joined #salt
15:56 kunersdorf joined #salt
15:57 inad922 joined #salt
15:59 conan_the_destro joined #salt
16:01 ferbla joined #salt
16:02 ek6 joined #salt
16:03 ajw0100 joined #salt
16:05 VulcanRidr joined #salt
16:06 nzero joined #salt
16:07 phpdave11 anyone know why i'm getting this error when i run salt?
16:07 phpdave11 UnicodeDecodeError: 'utf8' codec can't decode byte 0xc6 in position 85: invalid continuation byte
16:07 aparsons joined #salt
16:07 Furao joined #salt
16:08 furball365 joined #salt
16:08 ek6 phpdave11: just an intermittent error that comes up for you trying to display response data?  as in the command you were executing still did execute?
16:08 wendall911 joined #salt
16:08 dingo phpdave11: pretty easy
16:09 phpdave11 it's happening every time i try to run highstate
16:09 dingo can you be more specific, is it while rendering your states/pillars, or a command result?
16:09 dingo i'm guessing the former
16:09 babilen phpdave11: Because your input data contains a character that cannot be decoded by Python. As to *why* such a character/byte is in your input I cannot comment. That requires a little more information (e.g. what you are doing)
16:10 InAnimaTe joined #salt
16:10 phpdave11 ok, so maybe an invalid character somewhere in my sls files?
16:10 dingo if the command output cannot be decoded salt annoyingly dumps a blob of base64
16:10 dingo yup that's right, phpdave11, trying to find a command to help you, one sec
16:10 dingo It's Æ  btw
16:11 dingo find roots pillars -type f | xargs grep '\xc6'
16:11 iggy phpdave11: you have utf in your states... py2 doesn't handle utf very well
16:11 iggy or pillars
16:11 VulcanRidr Hey. Totally new to Salt, but I figured I'd come here to ask. Is there a separate orcestration engine? We already have puppet in place, but mcollective is a poorly-documented pile...
16:11 iggy use dingo's command
16:12 dingo well his error says it *is* trying to decode using utf8, iggy
16:12 dingo hje's probably using something more native to his own country, like some iso* encoding
16:12 iggy something like that
16:13 iggy py2 = use ascii or hate life
16:13 iggy VulcanRidr: salt has it's own orchestartion built-in
16:13 ek6 heh that needs to be a bumper sticker
16:14 dingo ? I maintain many unicode-heavy projects in py2.6 and py2.7
16:14 dingo its not a problem at all
16:14 dingo some are py2/py3 bi-compatible
16:14 VulcanRidr Maybe orchestration is the wrong term. I'm thinking of sending commands to multiple hosts based on some criteria, e.g. all webservers, or all ubuntu boxes or whatever.
16:15 dingo that's very simple VulcanRidr, part of the mechanism, nothing special
16:15 txomon|home joined #salt
16:15 dingo http://docs.saltstack.com/en/latest/ref/cli/salt.html#synopsis
16:15 iggy VulcanRidr: salt -G 'os:Debian' cmd.shell "some command for debian boxes"
16:16 iggy something like that
16:16 iggy so yeah, still built-in
16:17 VulcanRidr iggy: Thanks. So will something like that play nicely with the existing puppet infrastructure? or would I need both a puppet client and a minion on each and every box?
16:18 iggy if you want, you can use salt-ssh while you're switching over, but I would eventually switch over to running a salt-minion on all your managed hosts
16:18 iggy there are certain things salt-ssh just can't do
16:19 VulcanRidr Okay. Makes sense.
16:20 iggy once you start using salt, you'll want to get puppet out of the picture as quickly as possible
16:21 iggy one guy said the other day, he rewrote 3 months worth of puppet work in salt states in a day
16:21 iggy or something along those lines
16:21 kusams joined #salt
16:22 murrdoc also in the transition period
16:22 murrdoc u can still execute puppet stuff using salt
16:22 murrdoc there is a puppet module in salt
16:22 ageorgop joined #salt
16:22 txomon|home iggy, that was enlighting, so you mean that salt-formulas, althought they are told to be at the latest version, they will try no to break?
16:23 JDiPierro joined #salt
16:23 iggy txomon|home: ENOCONTEXT
16:23 txomon|home iggy, the github patch I did
16:23 yorjo joined #salt
16:23 smcquay joined #salt
16:23 phpdave11 ok, i think i figured out the \xc6 problem, thanks guys
16:23 txomon|home changing defaults to recommended... I come from a place where sane defaults are the rule =)
16:23 phpdave11 it wasn't in any of my sls files
16:24 iggy I mean that someone added that stuff to the formula without me noticing and I've been trying to undo it ever since then
16:24 phpdave11 but a script that gets run by one of my states with cmd.run outputted some garbage.  i put a log statement in /usr/lib/python2.7/json/encoder.py to figure out what it couldn't decode
16:24 txomon|home undo?
16:25 writtenoff joined #salt
16:25 Gareth morning morning
16:25 txomon|home Can't you just delete it?
16:25 txomon|home Gareth good afternoon =)
16:25 KyleG joined #salt
16:25 KyleG joined #salt
16:25 Gareth morning is a relative term :)
16:25 iggy the wildly erasing files that the formula didn't create in order to "have a clean starting point" (if that were the case, it should erase /etc/salt/master too, but it doesn't, so it's a lame excuse)
16:25 murrdoc :)
16:26 iggy txomon|home: I just don't like that being the default behavior
16:26 txomon|home btw, I got a bug with that formula =)
16:26 txomon|home iggy, neither me
16:26 txomon|home haha
16:26 murrdoc txomon|home:  guess what
16:26 murrdoc now u get to fix it
16:27 murrdoc :D
16:27 iggy it's very much against "least surprise" to erase people's files
16:27 txomon|home but I don't understand why you maintain it
16:27 txomon|home murrdoc, I alreday have a patch request
16:27 iggy _I_ don't
16:27 murrdoc its how u give back
16:27 ndrei joined #salt
16:27 murrdoc for free software
16:27 iggy I'm one of a group
16:27 txomon|home ohh so you mean that you can't just change the default?
16:27 iggy and I can't just change things that someone else approved
16:27 txomon|home even if its a sane default?
16:28 iggy as I said... I argued this a while back and lost
16:28 murrdoc wait
16:28 iggy but leave your PR there and see what others have to say
16:28 murrdoc can i see the default in question
16:28 txomon|home I mean, it's like trying to be Arch Linux and holding into initrd because you don't want to break your users
16:28 txomon|home you fork and that's it!
16:28 txomon|home sure
16:29 txomon|home https://github.com/saltstack-formulas/salt-formula/pull/130
16:29 murrdoc + clean_config_d_dir: False
16:29 iggy the formula by default rm's everything under /etc/salt/master.d
16:29 txomon|home it's documented like the following in the pillar.example: "This is not recommended but is the default"
16:29 murrdoc this is sorta needed
16:29 murrdoc Gareth:  put a _schedule.conf in the /etc/salt/master.d/
16:29 murrdoc cant just remove it
16:30 murrdoc i approve
16:30 murrdoc not that that matters
16:30 iggy the default _is_ to remove things
16:30 murrdoc yeah but he changed it to not remove
16:30 txomon|home indeed hahaha
16:30 Gareth who? what? where?
16:30 murrdoc which is +1
16:30 phpdave11 i wonder if i should submit a bug report for the utf decode problem
16:30 iggy so the state does actually ignore _*, so _schedule.conf is safe
16:30 phpdave11 do you guys get the same error if you run this?
16:30 phpdave11 salt \* cmd.run 'echo -e "Test\xC6Test"'
16:31 murrdoc but why remove files
16:31 txomon|home phpdave11, AFAIK, the shell will interpret that
16:31 murrdoc some of us dont want to touch the /etc/salt/master file
16:31 murrdoc and only use overrides from .d
16:31 murrdoc this formula is stupid
16:31 txomon|home phpdave11, you broke my ssh connection :(
16:31 aparsons_ joined #salt
16:31 phpdave11 sry
16:32 Gareth murrdoc: _schedule.conf was thatch's addition not mine.  But the schedule modules I added will try and use a schedule.conf under /etc/salt/minion.d
16:32 txomon|home murrdoc, I do want to generate everything from scratch
16:32 txomon|home salt \* cmd.run 'echo -e "Test\xC6Test"
16:32 txomon|home melkor# packet_write_wait: Connection to 192.168.1.3: Broken pipe
16:32 txomon|home as I wrote that
16:32 murrdoc Gareth:  sorry my bad
16:33 yorjo Is it normal to see two "Sending event - data" with very close _stamp for every command issue on the master? For example, if I request form a grain of one particular minion, I see two log entry in /var/log/salt/master which would be duplicate if not the sligh difference in _stamp (2015-05-08T16:07:31.463730 vs 2015-05-08T16:07:31.463897)
16:33 murrdoc must have been a based pi feature
16:33 iggy thatch
16:33 murrdoc oy vey
16:33 * murrdoc reservers comments
16:33 Gareth murrdoc: no worries :) I agree with though, doing a purge of everything under the .d directories seems extreme.
16:34 jdesilet joined #salt
16:34 murrdoc true
16:34 iggy murrdoc: feel free to comment on that PR
16:34 iggy the last time I tried to change it, I got veto'ed
16:34 txomon|home anyway, I just say that if you say in the docs that it is not recommended, you shouldn't do it by default, if it's recomended, then change the docs
16:34 murrdoc that requires like committing
16:34 Gareth murrdoc: thatch, the idea was to have a saved copy of the schedule in case it wasn't saved....an auto save if you will.
16:35 murrdoc it makes sense, and it also makes sense cos its more readable
16:35 murrdoc the part i dont like , personal preference, is that its setup by the package
16:35 murrdoc in the user space config dir
16:35 iggy the idea (as I understood it) was to have scheduler set up on minion start instead of requiring a pillar sync and/or state.schedule.present run
16:36 murrdoc there is stuff in teh schedule btw
16:36 murrdoc even if you dont set up any
16:36 murrdoc like the mine refresh and all that
16:36 iggy ^
16:36 aparsons joined #salt
16:36 txomon|home btw, the formula has also a bug when generating the formulas repo, because I get [ERROR   ] Error parsing configuration file: /etc/salt/master - mapping values are not allowed here
16:36 txomon|home in "<string>", line 458, column 11:
16:36 txomon|home - base: patch-1
16:36 txomon|home ^
16:37 spookah joined #salt
16:37 txomon|home on a sample config
16:37 thayne joined #salt
16:37 zzzirk joined #salt
16:38 iggy "when generating the formulas repo"?
16:38 iggy code talks... paste it
16:38 iggy (to somewhere other than the irc channel, btw)
16:38 txomon|home yep let me...
16:38 murrdoc Mother's Day is on Sunday if anyone is a horrible person like me and totally forgot
16:38 murrdoc lets make 'gist it' a thing
16:39 iggy I'll send my mom a text at like 11:59
16:39 txomon|home was
16:39 txomon|home for me already was, and I forgot
16:39 iggy gist it!
16:39 txomon|home https://gist.github.com/txomon/7352fd912abfad120177
16:40 iggy wtf is salt_formulas?
16:41 txomon|home https://github.com/txomon/salt-formula/blob/master/pillar.example#L127-L163
16:41 iggy yeah, I had nothing to do with that, I just put my formula git repos in my master config
16:41 txomon|home and you can do s/txomon/salt-formulas/
16:41 iggy you'll have to ask someone else about that rubbish
16:41 txomon|home iggy, if I do, it will just get synced?
16:42 iggy yes
16:42 txomon|home ok, then I don't need all that
16:42 iggy true
16:42 iggy that's a huge chicken-egg issue too
16:42 txomon|home haha
16:42 iggy the formulas won't get updated until you run highstate
16:42 iggy but you want the latest formulas when highstate runs
16:43 iggy so you almost always end up running highstate twice
16:43 txomon|home highstate runs automatically in the recommended modes, doesn't it?
16:43 iggy highstate never runs automatically
16:44 txomon|home then I have seen a cron setup or something somewhere that did it
16:44 iggy you can do it with the scheduler
16:45 iggy and I think there's an example somewhere of having github run a webhook against salt-api which in turn runs a highstate
16:47 murrdoc ouch
16:47 or1gb1u3 joined #salt
16:47 murrdoc put it on the schedule
16:47 murrdoc and use the smtp returner for most win
16:47 or1gb1u3 left #salt
16:51 txomon|home btw, having defaults split between the jinja and the yaml doesn't look good to me... either one or the other (the yaml seems better to me)
16:52 rojem joined #salt
16:52 cwyse joined #salt
16:54 murrdoc :|
16:55 murrdoc this formula looks like the devs dont get along
16:55 RandalSchwartz joined #salt
16:55 txomon|home yeah hahaha
16:55 * RandalSchwartz waves at the channel
16:56 txomon|home http://img-9gag-fun.9cache.com/photo/aD0PRww_460sv.mp4
16:56 RandalSchwartz I've started using fcron to manage my "must run daily" tasks.  It has an interface like crontab (with -e and -l and -u $user).
16:57 RandalSchwartz what's the most straightforward way to manage a jinja'ed fcrontab file, to automatically reload fcron when the fcrontab changes
16:57 RandalSchwartz maybe keep a text file on the machine as the result of a template, and watch that change to run the reload command?
17:04 theologian joined #salt
17:04 wt joined #salt
17:05 wt hi, should __pillar__ be available inside an sls file?
17:05 wt a file served as a state, that is
17:06 wt I am getting the following error: Rendering SLS '<env>:<statename>' failed: Jinja variable '__pillar__' is undefined
17:06 |Fiber^| joined #salt
17:06 bhosmer joined #salt
17:07 txomon|home wt, isn't it just 'pillar'
17:07 txomon|home ?
17:07 Ahlee No, salt['pillar.get']('value', 'default')
17:07 SexGirL joined #salt
17:07 |Fiber^| joined #salt
17:07 wt no, I don't want pillar.get
17:07 txomon|home Ahlee, but that's if you want to use the pillar get
17:07 wt pillar.get doesn't fail when the pillar doesn't exist
17:07 Ahlee You're in a state file, you want pillar.get
17:08 txomon|home Ahlee, pillar.get yes, bu tthat salt pillar is not needed if now using it's feature, is it?
17:08 wt I really wnat the sls to fail to render if the pillar does not exist.
17:09 wt I would prefer to get an error over the state file actually being rendered with no data
17:09 wt Can I get that behavior with pillar.get?
17:10 Furao joined #salt
17:10 murrdoc no
17:10 Ahlee {% set hi_mom =  salt['pillar.get']('value', 'default') %}; {% if hi_mom != 'default' %} <state> {% endif %}
17:10 iggy txomon|home: what defaults aren't in yaml?
17:10 Ahlee no pillar, empty set is rendered
17:10 desposo joined #salt
17:11 Ahlee sure it's terribly hacky
17:11 desposo joined #salt
17:11 spookah joined #salt
17:11 txomon|home iggy, the thing is that there are defaults in the jinja
17:11 iggy wt: {{ pillar['foo'] }} will fail
17:11 VulcanRidr left #salt
17:11 Ahlee there's that, too
17:12 txomon|home iggy, he want's that I think
17:12 iggy txomon|home: what jinja is what I'm asking?
17:12 txomon|home iggy, get_default() calls within the jinjas under files in the salt_formula
17:12 txomon|home btw, I found a bug with the salt_formulas thing I stopped using
17:12 wt iggy, ok, so pillar instead of __pillar__...thanks
17:12 iggy file + line number or gtfo
17:13 txomon|home they generate the yamls without colon in the gitfs_remotes, even if it has an option, that's the problem I had
17:13 iggy wt: __pillar__ is in python (modules, grains, pyrendered stuff, etc.)
17:13 murrdoc no
17:13 murrdoc __salt__['pillar.get'']
17:13 murrdoc __pillar__ == bad
17:13 txomon|home why not just pillar.get() ?
17:13 murrdoc language bad too
17:14 wt pillar.get does not fail
17:14 wt pillar.get does not fail when the pillar does not exist
17:14 iggy http://docs.saltstack.com/en/latest/topics/development/dunder_dictionaries.html
17:14 txomon|home wt so do pillar['xxx']
17:14 wt txomon|home, got it. I just used __pillar__ instead of pillar.
17:14 iggy sure, accessing __pillar__ directly is usually going to lead to weird errors, but it's certainly got it's uses
17:15 RedundancyD joined #salt
17:15 txomon|home wt remember http://docs.saltstack.com/en/latest/topics/pillar/index.html#pillar-get-function
17:15 txomon|home just in case =)
17:16 RandalSchwartz left #salt
17:16 wt txomon|home, in my case, I actually got burned because a pillar disappeared and salt happily rendered the template with an empty string
17:17 wt I was using pillar.get before
17:17 iggy test=True is a beautiful thing
17:17 jonatas_oliveira joined #salt
17:17 txomon|home indeed iggy
17:18 wt test wouldn't have saved me
17:18 wt the pillar disappeared during an upgrade due to a salt bug in the gitfs backend
17:19 iggy a minor distinction, pillars don't use the gitfs backend (yet)
17:19 wt but the _grains do
17:19 wt And my pillars are using grains to select the right files in the git_pillar at this time.
17:20 wt In the top.sls.
17:20 sophomeric iggy: external_pillar was a nice and very easy idea. thanks much.
17:20 txomon|home I am unable to locate the bug within this salt_formulas thing, but it's somewhere over there
17:20 wt Speaking of which, git_pillar needs to be fixed so that it works like other ext_pillars.
17:21 iggy wt: well, other than failing, you can also use {% if not salt['pillar.get']('something') %} a bunch of stuff that gets skipped if the pillar isn't set {% endif %}
17:21 iggy that's what you see in formulas a lot
17:22 wt That doesn't cause the render to fail. I can't probably use that in sls files, but not templates.
17:22 iggy but I'm of the firm belief that you should "do whatever f'ing works for you"
17:22 murrdoc its why hes not allowed in 4 states
17:22 murrdoc some of the f*ing that worked was illegal
17:22 iggy and 8 countries
17:23 txomon|home xDDDD
17:23 wt FWIW, I was using salt['pillar.get']('pillar_name') before
17:23 * txomon|home suspects that is partially true...
17:23 wt I am moving to pillar['pillar_name']
17:23 murrdoc which is sad
17:23 murrdoc cos salt['pillar.get'] is better
17:23 txomon|home murrdoc, not if you want actual errors, I am also like that =)
17:23 iggy wt: the other thing to remember is salt['pillar.get'] supporst sub-dict/list lookup using : pillar['foo'] doesn't
17:24 wt well, I have a number of templates (not sls files) that need to fail to update if the pillar data they rely on is not present.
17:24 txomon|home wt, however, you can also do pillar.pillar_name
17:24 txomon|home it's cleaner for me
17:24 txomon|home it uses attr instead of getter
17:24 wt txomon|home, is that considered better practice?
17:24 txomon|home and way less ['']
17:24 wt That seems kinda magical.
17:24 iggy if you know all this (which it sounds like you did before we beat you with clue-by-fours for the last 15 minutes), then use whatever is most appropriate for your situation
17:24 murrdoc wt:  pillars shouldnt be read in
17:24 murrdoc in a template
17:24 murrdoc read it in , i n the state
17:24 murrdoc pass it down to the template
17:25 txomon|home I am just python dev that discovered that =) not into salt yet (got started past week)
17:25 txomon|home iggy, you are awesome man hahahaha
17:25 murrdoc the . syntax breaks with the new lazy loader
17:25 wt iggy, I clearly didn't have it right. I was using __pillar__ instead of pillar. I also wanted to know if there was a better way to achieve what I wanted.
17:25 iggy murrdoc: think that was fixed
17:26 murrdoc that whiteinge
17:26 murrdoc smart dude
17:26 murrdoc like really … really smart
17:28 wt Thanks for the help, everyone.
17:30 c10 joined #salt
17:31 SEJeff left #salt
17:32 txomon|home you are welcome
17:32 tomh- joined #salt
17:33 pcn How can I get insight into what template variables are available on a host.  http://docs.saltstack.com/en/latest/ref/states/vars.html only seems to provide an overview.
17:33 pcn I mean e.g. how can I print out items(salt) or something to get that level of info.
17:33 pcn errr... salt.items()
17:34 iggy best thing I found when getting started was to look at other people's examples
17:36 pcn So there isn't a list of functions/names/etc or a way to extract them from a running system?
17:36 txomon|home in my case, I just ctrl+f in the pdf and crossed fingers =)
17:36 murrdoc http://docs.saltstack.com/en/latest/salt-modindex.html
17:36 txomon|home there is one salt-call pillar.get I think
17:37 iggy it's hard to get a clear example other than just making salt fail with show_full_context()
17:37 iggy http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html
17:37 iggy ^ that might help some
17:37 murrdoc http://docs.saltstack.com/en/latest/ref/states/all/index.html
17:37 dingo < phpdave11> i wonder if i should submit a bug report for the utf decode problem
17:37 dingo absolutely not: your data is *not* utf8, that is the problem
17:37 dingo >>> b"Test\xC6Test".decode('utf8')
17:37 dingo would reproduce the issue exactly.
17:38 dingo whatever your your '\xC6' byte is a part of, it needs to be utf8-encoded, not whatever encoding you're using, there
17:41 VR-Jack it's important to note that module.x can be different than state.x when you are dealing with documentation
17:43 VR-Jack hmm. guess that's modules.x and states.x
17:47 txomon|home seems there is also a but somewhere lost in that salt_formula https://gist.github.com/txomon/5b77000e5e247ff7fac3
17:47 txomon|home Is it just me that walks into all those errors?
17:48 jalbretsen joined #salt
17:48 VR-Jack txomon: I'm going to guess that your pillar for it had something wrong. perhaps a string where there should be a list
17:48 txomon|home if you update the link I posted the pillar
17:49 flebel joined #salt
17:49 VR-Jack well, the last 2 lines are definitely wrong
17:50 VR-Jack err, never mind. perhaps not
17:50 VR-Jack *brain needs coffee*
17:50 txomon|home https://github.com/saltstack-formulas/salt-formula/blob/master/pillar.example#L53-L55
17:51 VR-Jack gitfs_remotes is supposed to be under master:
17:51 txomon|home VR-Jack, no if you want those for both
17:52 txomon|home anyway, I found the problem, I was targeting in salt/top.sls salt.formulas and I haven't filled any, so it just gets into rendering it without data
17:52 murrdoc salt-minion : Depends: dctrl-tools but it is not installable
17:52 murrdoc :(
17:54 otter768 joined #salt
17:54 spookah joined #salt
17:55 txomon|home murrdoc, that sounds like debian
17:55 iggy txomon|home: open an issue, if there's no pillar, it should just noop, not fail miserably
17:56 iggy maybe I'll use that as an excuse to rip that shit out
17:56 txomon|home haha ok
17:56 ajw0100 joined #salt
17:57 txomon|home iggy, there you are https://github.com/saltstack-formulas/salt-formula/issues/131
17:58 murrdoc i am on ubuntu
17:58 txomon|home yeah, whatever
17:58 iggy I'm a formulas contributor, I get emails for every issue, but thanks ;)
17:58 txomon|home murrdoc, try the salt deploy script
17:58 txomon|home it's way easier
17:58 txomon|home or switch to archlinux hahaha
17:59 murrdoc k
17:59 murrdoc good idea
17:59 murrdoc one second
17:59 iggy salt-bootstrap uses the pkg repo's... which is probably where things are broken
17:59 txomon|home iggy, I know, but there was the possibility that something could have been done wrong on configuration =)
17:59 iggy murrdoc: is that from the ppa?
18:00 murrdoc yeah, its my bad
18:00 murrdoc there was a bug
18:00 murrdoc stale pyc files
18:01 murrdoc so what happened is i upgraded the salt-master on the saltmaster
18:01 murrdoc but not the salt-minion
18:01 dingo that would only happen if the .pyc had a newer last-modified time than the .py
18:01 dingo or it can cause import issues, if packages moved, too
18:01 dingo it can still find the path of the old .pyc even if there is no .py
18:02 dingo when a module.py gets moved to a module/__init__.py or vice-versa
18:02 murrdoc dingo:
18:02 murrdoc the salt-minion uses files from salt-common
18:03 murrdoc so if on the master, i upgrade the salt-master and salt-common package
18:03 murrdoc but not the salt-minion
18:03 murrdoc this is an expected error
18:03 txomon|home and that's why I hate now debian / rhel based distributions... they tend so split everything into packages!
18:03 txomon|home s/ so / to /
18:03 iggy you should hire someone to take care of that stuff for you
18:03 murrdoc i am trying to
18:04 txomon|home btw, running salt and saltmaster in a RPI really takes a life =)
18:04 dingo i bet, all the AES encryption probably costs the most
18:05 txomon|home maybe I should make the minion run locally and the master serve?
18:07 iggy masterless?
18:07 txomon|home yeah a masterless master
18:07 saffe joined #salt
18:07 txomon|home I would save the AES encryption when doing the highstate on it
18:07 iggy masterless is actually a thing
18:08 iggy (lyft uses it extensively)
18:08 txomon|home I prefer to have it all centralized, I plan to put sensitive data in the git repo
18:11 txomon|home I like salt more than puppet
18:11 c10 joined #salt
18:12 Brew1 joined #salt
18:13 Brew1 joined #salt
18:15 baweaver joined #salt
18:19 faliarin joined #salt
18:22 txomon|home so, if I want to match a host in the top.sls by it's hostname (not FQDN), how may I do it?
18:22 txomon|home ok nothing, said nothing
18:23 txomon|home I will better do it by FQDN...
18:24 VR-Jack txomon: I usually match on minion_id, which I set to what I want for best matching
18:25 txomon|home yeah, will also do that, but I had grown up matching against hostnames instead of FQDN and had some minions id as FQDN and others as hostname
18:25 txomon|home so I didn't run anything on the half of them, but the ones in base: '*'
18:28 txomon|home is it me, or the salt-formula creates it's configs under /etc/salt/*.d to override the ones in /etc/salt*
18:28 txomon|home because I hoped to write the real file instead of the .d one...
18:30 Diaoul joined #salt
18:33 agend joined #salt
18:37 iggy txomon|home: 'nodename:hostname':
18:37 iggy - match: grain
18:38 jonatas__ joined #salt
18:38 txomon|home ok, will be using FQDNs anyway, just in case
18:38 bhosmer_ joined #salt
18:40 iggy you can use globs in matches if you've got long names like we do... 'prod-rest*' will match prod-rest01.c.some-slug-001.internal
18:43 txomon|home ufff no, just my home domain =)
18:46 Freddy joined #salt
18:50 jonatas_oliveira joined #salt
18:54 ndrei joined #salt
18:56 martoss joined #salt
18:56 coval3nce joined #salt
18:57 txomon|home so the minion will keep generating the key with the hostname instead of the fqdn TT
18:58 coval3nce In a salt orchestrate runner, is there a way to use pillar data from the master without passing a pillar= arg?  OR, is there a way to pass an argument to be used in a particular state, where this argument is created in the orchestration runner?
18:59 coval3nce e.g would like to send a notify message if any portion of the orchestrate runner fails, but the metadata on how to send a notification is in pillar but message to be sent is defined in the orchestrate runner .sls
19:00 txomon|home so you want to define a pillar not in the command line but in a file? That's normal pillar/top.sls, isn't it?
19:00 coval3nce i guess fundamentally, there is no pillar data at all in the context of an orchestrate runner correct?
19:01 txomon|home coval3nce, I have no idea, new here :D
19:01 see joined #salt
19:02 whytewolf coval3nce: you can still use a top file for your pillar data. and it will get out there. orchestrate doesn't stop that.
19:03 coval3nce so salt[‘pillar.get’] shuld work within a orchestrate sls file?
19:03 whytewolf no, it would work in the state files.
19:03 coval3nce Gotcha, so i should move what i’m trying to do into a state, and call that state from orchestrate
19:03 whytewolf exatly
19:04 whytewolf orchestrate tells the master what to do. not the minions
19:04 kitplummer joined #salt
19:04 coval3nce Is there a way to pass a parameter to a state for lets say a text blob i’d liek to define in the orchestrate file?
19:05 whytewolf that i do not know
19:05 kitplummer heyo. trying to use salt-cloud.  is it supposed to run the state.highstate action?
19:05 kitplummer when a map is started?
19:06 whytewolf kitplummer: it runs bootstrap, you need to setup a reactor to run the highstate after the new instence boots
19:07 VR-Jack coval3nce: https://gist.github.com/anonymous/8826032ed5c22ef09897
19:07 VR-Jack that's from my kickstart orchestrate file
19:07 bhosmer__ joined #salt
19:08 coval3nce VR-Jack: so the {{ minionid }} gets rendered in the state execution on the targeted minion?
19:08 seev I have an API endpoint that defines and tracks hostnames, which correspond to minion IDs and roles
19:08 seev on first boot, it checks in to see what sort of server it should become
19:08 VR-Jack coval3nce: it creates a minionid and a node pillar for the state to process
19:09 txomon|home question, I am tracing the minion id generation, and I see a lot of log.info entries, how may I get access to them?
19:09 VR-Jack in this case, minionid is a string and node is a very large dict
19:09 coval3nce VR-Jack: so where does the “minionid” variable come from in this case, the pillar data on the miion?
19:09 txomon|home debug=True doesn't seem to print them,...
19:09 VR-Jack coval3nce: in this case, it comes from the master
19:10 txomon|home arggghhhh
19:10 txomon|home cat /etc/salt/minion_id
19:10 VR-Jack orchestrate files are processed by the master
19:10 txomon|home not needed anymore =)
19:10 kitplummer whytewolf: cheers - this right: http://salt-cloud.readthedocs.org/en/latest/topics/deploy.html#post-deploy-commands
19:10 murrdoc yeah orchestrate files should have pillarts too
19:10 murrdoc pillars*
19:11 murrdoc or at least __salt__
19:11 VR-Jack the pillars I created, minionid and node will be passed and processed by the minion when it runs the kickstart sls
19:11 coval3nce So where do you set master pillar data….RTFM'ing
19:12 whytewolf kitplummer: yeap
19:12 VR-Jack that, unfortunately, I can't tell you. the particular data I pulled was from a base: '*' pillar.sls
19:13 soren joined #salt
19:13 coval3nce Maybe i’m thinking of this all wrong ;)  I thougth pillar data is only accessible in a minion (e.g. pillar dta defined in pillar_roots or ext_pillar).  Orchestrate runs on the master, so the master would not have access to any of the said pillar data.
19:14 mapu joined #salt
19:14 murrdoc pillar data is on the master
19:14 murrdoc master sees all
19:15 martoss left #salt
19:15 florinandrei joined #salt
19:16 baweaver joined #salt
19:16 hybridpollo joined #salt
19:16 iamtew joined #salt
19:17 coval3nce ok, so in theory the master sould be able to resovle any pillar data in an orchestrate file per the compilation of top.sls
19:20 txomon|home why salt-master isn't restarted when I add a line into salt's gitfs_remotes?
19:20 whytewolf is it added into a file that the state to restart salt-master is watching?
19:22 txomon|home whytewolf, using the salt-formula, it should restart it...
19:23 hybridpollo joined #salt
19:24 rem5 joined #salt
19:24 whytewolf humm, it should then. from what i see in the master.sls file of salt-formula it has a file.recurse that it is watching in minion.d
19:24 antoniotd2005 joined #salt
19:24 babilen txomon|home: I am not aware of a single service that restarts whenever you make changes to its configuration files
19:24 antoniotd2005 left #salt
19:24 whytewolf unless it starts with _
19:25 babilen Ah .. using the formula
19:25 whytewolf unless you changed the file directly and not through the formula
19:26 txomon|home whytewolf, but not master.d...
19:27 txomon|home the thing is that I am updating the master config
19:27 whytewolf sorry, yes master.d not minion.d
19:27 whytewolf typo on my part
19:27 txomon|home well, I just timed, and takes 5 minutes to my master to update the repos
19:27 txomon|home even if I restart
19:28 * txomon|home is running the master in a rpi
19:31 chiui joined #salt
19:32 whytewolf yikes
19:32 coval3nce Meh, will have to play more, for some reason the orchestrate.sls file tht i’m redering isn’t able to pull pillar data
19:34 txomon|home coval3nce, remember that pillar/top.sls gives access to pillar data and salt/top.sls to states... so you might not be giving access your orchestrate.sls to the data you want to use
19:35 ckao joined #salt
19:35 twobitsprite left #salt
19:36 VR-Jack coval3nce: this works for me. https://gist.github.com/anonymous/07208bd03c3703bfd953
19:36 forrest joined #salt
19:37 coval3nce i bet my problem is im missing a catch all host idenitfier
19:37 coval3nce doh
19:37 coval3nce in top.sls that is
19:39 coval3nce VR-Jack: thanks man, looking at that gist now
19:39 VR-Jack coval3nce: you may have to tweak it, but here's an example where I load a pillar natively in the pillar top.sls (before pillar loads). https://gist.github.com/anonymous/a885fb6257786f6c39ec
19:40 txomon|home VR-Jack, you love that =)
19:40 VR-Jack txomon: yes, because it's a good example of jinja doing wicked things
19:41 VR-Jack not sure if you can full path the hosts.sls, though. it was in the same directory as the top.sls. From an orchestrate it would be different
19:42 txomon|home whytewolf, you were correct, I hadn't specified correctly the gitfs_remotes =)
19:43 jasonrm joined #salt
19:44 coval3nce VR-Jack: looking at your first gist, i’ve been trying to use the pillar.get functions within jinja brackets
19:44 coval3nce e.g.  "channel={{ salt['pillar.get’](‘foo) }}"
19:44 nzero joined #salt
19:45 VR-Jack hmmm. haven't tried that. There might be issues with salt[] inside the state, though
19:45 coval3nce let me try using jinja assignment like you did
19:45 coval3nce instead of trying to put them withi the render brackets
19:47 txomon|home btw, why does the f_defaults.conf have all those comments?
19:47 txomon|home if salt-formula isn't managing /etc/salt/{master,minion}, why should it care about comments?
19:47 whytewolf jinja should just work, since it would render the yaml before handing it over to the runner.
19:48 VR-Jack yeah, and I think that pillar.get has issues when run on master.
19:48 derelm joined #salt
19:49 steffo joined #salt
19:49 whytewolf txomon|home: you got me, I don't use the salt-formula although i hear it has goten better since iggy started pitching into it
19:50 VR-Jack although I think iggy would like to toss it. lol
19:50 iggy the f_defaults thing is basically a legacy file that's been copied around a few times
19:51 iggy nobody cares enough to get rid of it (and the comments aren't completely useless)
19:53 txomon|home iggy, but instead of getting rid of it, I would just deploy it in /etc/salt/master
19:53 coval3nce VR-Jack: https://gist.github.com/dkiser/a30fdc65683d4bd9edfc  the grains.get call renders, but other variables are simply empty.
19:54 iggy txomon|home: review the git history
19:54 iggy it used to do that, and someone changed it at some point for some reason
19:54 VR-Jack coval3nce: grains are processed by master. pillars are usually processed by minion.
19:54 VR-Jack I've noticed trying to deviate causes issues sometimes
19:54 iggy backwards
19:54 agend joined #salt
19:54 txomon|home iggy, but it's ok to deploy it in /etc/master.d/f_default but just if you rip off the comments, it's too much text for nothing really
19:54 VR-Jack iggy: not for referencing
19:55 giantlock joined #salt
19:55 otter768 joined #salt
19:55 VR-Jack salt['pillar.get'] seems to work well on a minion, but not on a master. pillar[] works on both. grains.get works well on master
19:56 iggy txomon|home: I have no intention of changing it, but it would simplify the thing immensely if it worked the way you say
19:56 coval3nce VR-Jack: i haven’t used straight pillar[] at all, maybe that would work in my case
19:57 VR-Jack coval3nce: that's what I have in my kickstart orchestrate file
19:57 txomon|home iggy, intention means you wont do it or that if I do it you won't accept it?
19:58 VR-Jack I believe the master only picks up on '*' pillar, though I haven't tested that.
19:58 iggy txomon|home: won't do it, I wouldn't block it being changed
19:58 coval3nce VR-Jack: is that syntax a straigh dictionary style, e.g can’t do pillar[‘foo:bar’]…in ither words, no convencience nesting getter
19:59 iggy coval3nce: correct
20:00 VR-Jack hmm. actually, heh. I did use pillar.get
20:00 VR-Jack is slack:channel available to * nodes?
20:00 murrdoc does this niels dude hang out in irc
20:00 murrdoc i want to know why we should be cleaning out the .d directory
20:00 murrdoc feel like the onus of proof should be on that
20:00 murrdoc not cleaning it makes sense to me
20:01 coval3nce VR-Jack: yeah you used both, now im getting a attribute does not exist error, which makes sense if its not grabbing the pillar data i think it sohuld be
20:01 VR-Jack yeah. master probably only gets all nodes by default, since it can't match minion identifiers.
20:02 VR-Jack I didn't see any special options for matching master.
20:02 VR-Jack probably should be an FR
20:03 VR-Jack orchestrate gets weird, though. it doesn't work like the rest of salt
20:03 coval3nce yeah i tried explcitly adding ‘*’ for the sls file i wanted and no dice
20:04 c10 joined #salt
20:04 coval3nce be nice is there was a salt-run pillar.get equivalent of the salt-call one
20:04 coval3nce to see whats getting build on master in context of orchestrate
20:05 VR-Jack strange. I know mine is working as posted in that gist. Took awhile to find the right combination.
20:05 VR-Jack I call orchestrate with a node pillar on cli, and it looks up the rest and does the job
20:06 coval3nce in my pillar/top.sls i’ve got ‘*’ including a particular file which should have the dict i want
20:06 VR-Jack under base:?
20:06 VR-Jack master would default to base environment
20:06 coval3nce yeah, and the paricular environment im lauchin orchestrate with
20:07 coval3nce i got stuffon a git stage branch, and runing salt-orchestrate with saltenv=stage
20:08 VR-Jack You might have hit an environment break. I've heard there's bugs in it. My setup is single base environment and no externals
20:08 XenophonF joined #salt
20:09 c10_ joined #salt
20:09 coval3nce so so, i can prolly work around it by calling a state from orchestrate, if i can figure out how to pass a parameter to that state  <— potentially by using the pillar kwarg
20:09 XenophonF is there a yaml variable or some kind of introspection that would tell me the name of the current SLS file?
20:09 XenophonF er, i mean jinja variable
20:10 coval3nce e.g move this slack stuff down into a state that relys on pillar vars, let it get the pillar vars as normal for all things expcept the message text, then i pass that as a pillar kwarg to that state from  orchestrate…..altough that won’t work if the pillar kwag overwrite the normal pillar
20:10 coval3nce Any idea of that is a deep merge?
20:11 SafeMoneyOnl joined #salt
20:11 iggy XenophonF: {{ sls }} or maybe {{ source }}
20:11 XenophonF thanks iggy
20:12 VR-Jack coval3nce: you'll have to test. should still smart merge, though.
20:14 VR-Jack you're other option is to find a way to load_yaml to pull what you need into jinja
20:15 XenophonF how do i invoke salt.renderers.jinja.render? i want to run something like "salt-call jinja.render salt://test.sls" but of course that doesn't work
20:15 coval3nce Yeah, but ideally i wanted some of this stuff to be GPG encrypted in pillar data
20:15 VR-Jack I'm not sure how to handle pathing for load_yaml, though. was fine with same directory in a pillar, but may be an issue from an orchestrate sls in a different tree
20:16 VR-Jack ahh, multiple renderers can be problematic
20:17 viderbit joined #salt
20:17 cpowell what is the code name for the current release?
20:17 aparsons joined #salt
20:17 iggy XenophonF: see if salt-call -l debug state.template will work with test=True
20:18 cpowell nm
20:18 XenophonF thanks again iggy, i'll try that
20:19 iggy XenophonF: or state.single test=True
20:19 iggy there's not a handy "show me the rendered output of something" function
20:19 iggy although it would be awesome
20:20 coval3nce +1
20:20 cpowell +100
20:21 murrdoc show_sls is good enough
20:21 whytewolf +10e1000
20:21 murrdoc on the make do tip
20:21 XenophonF thanks murrdoc will try that too
20:22 XenophonF it'd be nice if there was an equivalent for other jinja templates though
20:22 XenophonF not just SLS files but config files too
20:22 murrdoc {{ show_full_context }} is like dump vars
20:23 iggy it has to be used carefully
20:23 iggy and still requires you to edit files on the master
20:23 murrdoc yes
20:23 murrdoc all true
20:24 spookah joined #salt
20:24 iggy would be handy to have: salt-call state.render_string "{{ grains['nodename'] }}"
20:24 iggy or something similar
20:25 saffe joined #salt
20:25 iggy someone should open an issue!
20:25 * iggy too lazy... friday
20:25 murrdoc paging brian jackson
20:25 murrdoc come in brian
20:25 murrdoc save the day
20:25 murrdoc brian
20:25 murrdoc mr jax
20:25 murrdoc we need the jax
20:26 iggy we had a release last night... it's leave early day today
20:26 cpowell so I am assuming ya'll all work for Saltstack?
20:26 VR-Jack you can work for them?
20:26 VR-Jack sounds annoying
20:26 cpowell they have a fancy websire!
20:26 cpowell has to be legit
20:26 coval3nce hehe
20:27 iggy none of us do
20:27 iggy too cold
20:28 murrdoc also everything closes at 11
20:28 XenophonF too dry
20:28 murrdoc but rents cheap
20:28 VR-Jack becides, given the various salt codenames, I don't want to see the employee titles
20:28 cpowell dry county? nope.com
20:29 ajw0100 joined #salt
20:29 XenophonF plus it doesn't rain much
20:29 iggy it's not totally dry... but they have weird alcohol laws for sure
20:29 iggy (and it's the state, not the county)
20:29 lahwran joined #salt
20:30 pedromaltez joined #salt
20:31 iggy I should tell ryan lane that lyft's gps locations suck... it's always like a half block off
20:31 kusams joined #salt
20:32 murrdoc how is nope.com not a release website
20:32 murrdoc travesty
20:32 cpowell yup lol
20:34 txomon|home iggy, there you are https://github.com/saltstack-formulas/salt-formula/pull/132
20:34 txomon|home and I didn't erase all I wanted, but if the patch gets accepted, will do the same with master and cleanup even more
20:34 iggy I saw the notification email before you had time to mention it in here
20:34 txomon|home hahaha
20:35 txomon|home 741L vs 369L
20:35 murrdoc why dont we just put all overrides in .d
20:35 txomon|home murrdoc, that is the idea I am following
20:35 iggy technically they are
20:35 murrdoc then the next upgrade we dont have to worry about whats in the minion.conf
20:36 murrdoc i am saying dont manage the file
20:36 txomon|home oh you mean the opposite?
20:36 iggy they are just in a giant bloated copy of the config files from 0.17.x
20:36 murrdoc make it a one liner
20:36 txomon|home so managing /etc/salt/master and leaving .d for user?
20:36 murrdoc include {{ conf-dir }}
20:36 murrdoc and thats it
20:37 murrdoc joined #salt
20:37 shadowsun joined #salt
20:37 murrdoc i mean if u think about it, each config can be put under a grouping
20:37 murrdoc so have namespaced files in the .d
20:37 murrdoc and then manage that dir
20:38 murrdoc instead of nuke everything but underscores
20:38 murrdoc (i realize there is no point to this convo )
20:38 shadowsun I'm getting an error, "     Comment: Unable to manage file: none of the specified sources were found
20:38 shadowsun Problem is, it's not attempting to get the file, the specified source does exist, and if I tell salt to say, copy the file, the minion finds it just fine
20:39 shadowsun How do I get this to start working again, or at least get more information on what exactly is broken?
20:40 Chadk So here's a silly question: A salt state for some software being up to date, which there's no repo for and thus is build from source, what's the best approach to that? Trying to build it and check version and replace as needed, manage a repo yourself, or is there some nice clever trick?
20:40 iggy so like "/etc/salt/master:\n  file.append:\n    - text: include /etc/salt/master.formula.d" then just put stuff in there instead of touching /etc/salt/master.d ?
20:40 shadowsun Chadk: I went with the "manage a repo myself" option
20:41 iggy if you're on debian, aptly formula helps with that
20:41 Chadk That, that to me seemed like the nicest option really.
20:41 Chadk I guess I better up on maintaing repos.
20:41 iggy aptly-formula
20:42 Chadk Yeah, just looking at it. I'm still new, so takes a bit to see what's actually going on. I'm just trying to make everything make sense and actually have something run. I recently switched all my dev to windows, so I've gotta get my dev VM back up and running, and esxi server online >_>
20:42 spookah joined #salt
20:43 Andre-B joined #salt
20:45 txomon|home I would rather prefer to have it all together in one file, instead of spread over there
20:45 txomon|home and more, if it's a managed file
20:46 dingo i hate taxonomy
20:46 dingo i like one folder with a dozen files, vs. 68 folders & sub-folders, most with one file each
20:46 dingo taxonomy, esp in files and folders, seems to be a phenomenon from the java world, but i see it often in python, too
20:47 APLU joined #salt
20:48 whytewolf huh, i always thought it was windows geeks trying to learn linux and bringing the complications of registry with them. [jk, kind of]
20:48 shadowsun So, can anyone help me find out why my minions are throwing "Unable to manage file: none of the specified sources were found"?
20:49 XenophonF left #salt
20:49 iggy shadowsun: try gist'ing your state file
20:49 Chadk whytewolf, nah. I got sick and tired of OS X's window manager, and never got along with KDE/Gnome. So back on Windows I am, wishing for a good terminal.
20:50 Chadk Ah, different context, nvm
20:50 dingo shadowsun: what is your "- source: <contents>"
20:50 whytewolf Chadk: cygwin's terminal isn't to bad.
20:51 Chadk But salt doesn't support salt
20:51 Chadk Eh, support cygwin*
20:51 Chadk At least from what I can tell
20:53 shadowsun iggy, dingo: https://gist.github.com/Kionmaru/fa989b33fdd733bb48a1
20:53 whytewolf ahh. your right. salt does not really support cygwin.
20:54 txomon|home any of you knows how the openssh.auth formula works
20:54 txomon|home I am trying to understand it but maybe someone can say "It injects the ssh keys in each user's home .ssh/authorized keys" or stuff like that
20:54 txomon|home or maybe I have mistaken on what it does
20:55 shadowsun txomon|home: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.ssh_auth.html ?
20:55 txomon|home no https://github.com/saltstack-formulas/openssh-formula
20:55 rypervenche joined #salt
20:55 clintberry_1 joined #salt
20:56 UtahDave joined #salt
20:56 whytewolf shadowsun: looks like salt://states/etc/yum.conf isn't the correct path. what is the file_roots setting in your master conf pointing at
20:56 shadowsun whytewolf: It's pointing at the git repo.
20:56 bhosmer_ joined #salt
20:56 shadowsun "salty" is the base dir of a clone of that repo
20:56 iggy shadowsun: A. gist supports multiple files... no reason to cram it all into one B. salt 'r3.*' cp.list_master C. gist supports revisions, so no need to make a new one every time you paste some more data
20:57 txomon|home shadowsun, seems like the link you posted is only relative to the user dir... I would like to have all the authorized keys under control in /etc =)
20:57 shadowsun iggy: I just made this one. I haven't pasted more data. I thought it would be more convenient to just give you gobs of data, my apologies.
20:57 iggy shadowsun: I meant for when you show me the output of "salt 'r3.*' cp.list_master" ;)
20:58 VR-Jack txomon: that forumla configures the central openssh stuff.
20:58 shadowsun Oh, I didn't know that was a request.
20:58 shadowsun sec
20:59 txomon|home VR-Jack, but user pubkeys too, doesn't it?
20:59 txomon|home the thing is that I am unable to understand how it does so
20:59 VR-Jack pub and private via the auth section I believe.
20:59 shadowsun iggy: you want the full output, or just the line that shows yum.conf?
21:00 coval3nce VR-Jack: just threw a pillar.items in that jinja and orchestrate is returing an emply list
21:00 VR-Jack it's a little overkill if all you want is the pub key
21:00 murrdoc this formula stanks
21:00 murrdoc (kidding)
21:01 txomon|home yeah, I just want to have all the pubkeys in, for example /etc/ssh/auth/%u_auth and each %u_auth represents all the keys that have access to a user
21:01 txomon|home mainly because I may want to delete a user
21:02 moloney joined #salt
21:02 iggy shadowsun: I mean, I guess the fact that you see it in the output is the key point
21:02 shadowsun iggy: Updated the gist. But yeah, it has been working for a year or so, and today it's magically not, and I haven't touched those config files, and git log says neither has anyone else. All of the content looks perfectly normal
21:03 VR-Jack I just use ssh_auth.present and .absent. but I have simple needs. the openssh.auth can do more complicated tasks
21:03 iggy shadowsun: did you look for issues in the tracker?
21:03 shadowsun So I'd love to know why the minion thinks it can't find the file when it doesn't appear to be trying to find the file.
21:03 iggy I want to say someone reported something similar
21:04 VR-Jack coval3nce: oh, fun. still doing the environment thing?
21:04 coval3nce VR-Jack: yeah trying to undertand wahts happening ;)
21:04 VR-Jack covalence: are you sure environment is setup right?
21:04 shadowsun iggy: I found a windows bug listed that appears similar, but it's tagged windows
21:04 shadowsun so I bypassed it
21:05 coval3nce VR-Jack: pretty sure, pillars and grains work prfectly in states
21:05 VR-Jack are those states running in the environment you're kicking orchestrate to?
21:06 coval3nce yeah
21:06 moloney I am looking into writing a custom grain to provide more PCI device info.  I would like to use the "python-hwinfo" package to do this (https://github.com/rdobson/python-hwinfo).  How should I handle the dependency on this package?  Can I use salt to make sure this package is there for my custom grain or would that cause a circular dependency?  Should I just dump a copy of that package in the _grains directory?
21:06 shadowsun iggy: The others are #22040, which is a similar but different error, and #21799, which doesn't appear to be related, except that they're also encountering the same none of the specified source files are available.
21:06 shadowsun (which may or may not be related to the error they're reporting.)
21:07 badon_ joined #salt
21:08 VR-Jack coval3nce: could be a bug in orchestrate possibly. you might try a small test orchestrate file and try it frome base environement to see what it sees
21:08 iggy moloney: you can have salt install the package and it will reload the modules after the installation... just make sure the state that installs it is higher in the top file than the states that use it
21:08 bhosmer__ joined #salt
21:08 moloney iggy:  Well it is a custom grain that is going to use it, not a state.
21:09 iggy but presumably that grain is going to be used in a state somewhere?
21:09 forrest moloney: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.saltutil.html#salt.modules.saltutil.sync_modules look at the example there, shows how to reload a module.
21:10 forrest and I believe you should be able to use that for the grains sync.
21:10 forrest which is right above
21:10 VR-Jack worst case, you can make sure you have the module before you configure the minion to create the grain
21:11 moloney iggy:  Yes, I just thought the grain info might be collected before any states are run.  I guess you are saying the grains are collected in a "lazy" fashion as needed?
21:11 rojem joined #salt
21:12 VR-Jack last I read, grains are generated at minion start and stay static
21:12 iggy moloney: no, but a package install causes salt to reload modules/grains/etc
21:12 iggy (and you can force it on a package install with reload_modules: True)
21:13 VR-Jack iggy: I think it's the concern of the config for the grain referencing the module on minion startup before the module is there
21:14 VR-Jack if like pillars, it would ignore the error, but I'm not an expert on grain config
21:14 shadowsun forrest: evening
21:14 forrest shadowsun: hey
21:14 moloney Hmm, I think I understand. I will try it out real quick.
21:14 shadowsun iggy: Any ideas on how to get more info out of it on why it's mysteriously failing?
21:16 Draxx joined #salt
21:19 iggy shadowsun: not really, no
21:20 shadowsun iggy: I guess I'll roll an RPM to revert all the boxes then
21:20 murrdoc is javier domingo in this channel
21:20 murrdoc javier domingo
21:20 txomon|home yes
21:20 txomon|home me
21:20 murrdoc u a funny guy
21:20 murrdoc bipolar
21:20 murrdoc but funny
21:21 txomon|home why murrdoc ?
21:21 txomon|home I was exploring the saltstack repo
21:21 iggy I wrote that in the pillar example
21:21 iggy can you tell I've been against the idea from the start
21:21 pfallenop joined #salt
21:21 murrdoc i mean this in a good way
21:22 txomon|home btw, I have found that there are a lot of repos that are just a map of packages for different OSes
21:22 txomon|home shouldn't be better to mix all of them in one?
21:23 iggy they'd be harder to find
21:23 txomon|home iggy, I think that /etc/salt/{minion,master} should be the ones managed, and that they should be *clean* configs
21:23 iggy txomon|home: that's how it used to be
21:23 txomon|home and should
21:23 iggy till some jagoff changed it
21:23 txomon|home it's about usability. if you want to document code, that's ok, you can do it *briefly* but having such a giant inunderstandable thing...
21:24 txomon|home xDD
21:24 murrdoc @jagoff is a good man
21:24 iggy and by the time I noticed, it was too late to revert all the crap
21:24 Deevolution joined #salt
21:25 txomon|home to know what has been deployed, I have created a command: alias know-what-is-there="grep -v -e '^$' -e '^#'"
21:25 txomon|home haha
21:25 pedromaltez joined #salt
21:28 coval3nce VR-Jack: looka likw merging of the pillars do not happen if a pillar is provided to a state in orchestrate
21:32 ajw0100 joined #salt
21:34 txomon|home I would really merge all those mapping packages into one... they are really just ocupying space
21:34 nzero joined #salt
21:34 txomon|home and you need to update your master all the time
21:34 txomon|home instead of having a fresh map
21:35 pfallenop joined #salt
21:38 VR-Jack coval3nce: thanks. good to know.
21:39 VR-Jack txomon: honestly, while salt-formulas can be cool, a lot of times I just do a file.managed and do my own stuff
21:39 murrdoc http://www.wired.com/2015/05/tech-time-warp-douglas-adams-bbc-hyperland/
21:39 baconbeckons joined #salt
21:40 txomon|home VR-Jack, that's why I was speaking about having a packages-formula for those kind of packages
21:41 txomon|home if you are just going to manage the service, the package, and maybe a key-value file or stuff like that, you can put them all together
21:41 baconbeckons i need to run a shell script that returns a value and pass that value into a state when the state is run. what is the best practice for doing this?
21:41 thehaven joined #salt
21:41 txomon|home btw this is a really interesting formula: https://github.com/saltstack-formulas/hostsfile-formula
21:43 baweaver joined #salt
21:45 pedromaltez joined #salt
21:46 thayne joined #salt
21:47 jhujhiti is it possible to include a state from a state written with the py renderer?
21:48 mpanetta joined #salt
21:52 murrdoc yes
21:52 litwol joined #salt
21:52 litwol Hello
21:52 mario__ joined #salt
21:52 txomon|home hello
21:53 murrdoc my name is elder price
21:53 mario__ hey guys
21:53 jhujhiti murrdoc: do you have an example? the closest thing i can find is https://github.com/saltstack/salt/issues/18487 , which says it's broken.
21:53 litwol I am having difficulty how to adapt CLI Example to salt state sls
21:53 litwol based on this documentation: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.ebuild.html#salt.modules.ebuild.install
21:53 litwol i'm looking at the 'uses' cli example.
21:53 mario__ I have a question someone may have an answer for
21:53 litwol what would the state file syntax look like ?
21:54 litwol so far i have pkg.installed: \n -name: ... \n - uses: \n - my_use_flag
21:54 murrdoc well sorry jhujhiti
21:54 mario__ can someone tell me or point me about the differences between SaltStack Enterprise and Opensource?
21:54 murrdoc i figured you could inclde: it by id
21:55 VR-Jack baconbeckons: I've yet to find anything good for dynamic variables in saltstack. You could have the script send a salt event to the master and have the master's reactor call the other state with the data, though.
21:55 shadowsun iggy: If I run the salt-master directly, the problem vanishes. If I restart the service and highstate the minion again, it fails the same way. It's not a minion problem.
21:55 iggy shadowsun: interesting find
21:55 litwol Running my state i get this error: InvalidAtom: Invalid use dep: '"internal-jsoncpp"'
21:55 shadowsun iggy: Yeah. Not what I was expecting, but troubleshooting it far neough to get a work around is easier than building an RPM and reverting ~80 boxes
21:55 timoguin mario__: paid support, and a new enterprise GUI. that's all.
21:56 jhujhiti murrdoc: with python code 'include [something].mystate'? maybe?
21:56 baconbeckons VR-Jack: yeah, that does seem a little round a bout though. only the minion needs the data and it feels weird to have the minion calculate the value, send it to the master, and have the master send it back
21:56 iggy txomon|home: as I said earlier, if you go shoving a bunch of formulas into one repo, you make them harder to find
21:56 otter768 joined #salt
21:57 mario__ timoguin: thank you! I was confused because a saltstack sales guy told me the boto_vpc functionality is only in the enterprise edition but not present in opensource
21:57 txomon|home iggy, unless you point everyone to check packages-formula repo
21:57 txomon|home if it's a well known repo that has all the configuration-less or light configuration repos there, then it would be perfect
21:57 jhujhiti err, python 'import', not include
21:57 timoguin mario__: that isn't true .https://github.com/saltstack/salt/blob/develop/salt/modules/boto_vpc.py
21:58 txomon|home obviously, if a package grows, as for example the fail2ban one, then you can always place a message on the new location of the package
21:58 txomon|home I don't see the problem there
21:58 iggy txomon|home: most people don't even know the saltstack-formulas even exist, much less know to look at one for a bunch of states bundled together
21:58 VR-Jack baconbeckons: there's also support for minion reactor, I think. haven't researched it much
21:59 baconbeckons VR-Jack: i’ve never played with that part :(
21:59 iggy txomon|home: and we have no control over how the org is portrayed to visitors... that's a default github look
21:59 mario__ timoguin: I see. I have a question now. I installed salt via pip and the boto_vpc module file looks way smaller that the one in  github. Do I need to install a different version?
21:59 mario__ timoguin: pip installed 2014.07.5
21:59 iggy mario__: the default view in github is devel
22:00 iggy you almost certainly don't want to install that version
22:00 timoguin mario__: i linked the develop branch
22:00 smcquay joined #salt
22:00 VR-Jack baconbeckons: it's one of salt's shortcomings I think.
22:00 mario__ timoguin, iggy: So that's a fucntionality for a future stable version then?
22:00 VR-Jack lots of workarounds, but all messy
22:01 iggy mario__: correct
22:01 iggy 2015.2 should be out "soon" it's got some of the new boto functionality
22:02 timoguin You mean 2015.5, iggy
22:02 * timoguin ducks
22:02 mario__ iggy: Got you! Should 2015.2 good enought to show a demo to my boss? I'm pushing for salt at our company but they want to see the AWS fucntionality
22:02 Chadk My team wants to see a web GUI to be sold :(
22:03 murrdoc salt-pad
22:03 murrdoc google it
22:03 murrdoc shine it
22:03 murrdoc sell it
22:03 baweaver joined #salt
22:04 Chadk But is that the GUI that supposedly ships with Enterprise, which is hard to get info on?
22:04 forrest VR-Jack: Minion reactor isn't in until next release. I double checked last week
22:05 VR-Jack forrest: thanks. The only reason I considered it is there's event.fire vs event.send.
22:05 txomon|home iggy, it's by recent activity =)
22:05 forrest VR-Jack: Yeah I'm not sure how it will function on the minion, once it's out in stable I'll update my blog to use it.
22:06 forrest so it will auto-update on push
22:06 litwol hah so strange
22:07 mario__ I have to go now guys, thank you iggy and timoguin
22:07 VR-Jack baconbeckons: you best bet is probably to do a py render of the state file, make a direct shell call, take the output, and then do the salt call and send that data via pillar
22:07 iggy txomon|home: right, but we can't add a note there that says "look at X-formula repo if you can't find something here"
22:07 VR-Jack power of python should get the job done, but shesh. messy
22:08 litwol i'm using 'require' in a pkg.installed state to pull another state. that 'another' state does two things to set up dependencies: (1) configure package settings, (2) install package. it is critical for configuration to happen first.
22:08 iggy Chadk: saltpad is a community project (not related to saltstack enterprise)
22:08 txomon|home the formula would be really used, I promise
22:08 txomon|home if it's organized, no worries
22:08 litwol http://dpaste.com/3AT7WQA
22:08 litwol as expected require: \n - pkg.. worked great
22:09 litwol but i also expected configuration to be executed 'first' as well. but it didnt. actually it is pushed to the very very last state
22:09 litwol so strange
22:09 iggy I'm part of the group that maintains the formulas... I can assure you that nothing stays at the top of the list for long
22:10 txomon|home iggy, is there mailing list?
22:10 iggy litwol: yes, require is bad about altering the order unnecessarily
22:10 iggy txomon|home: yes
22:10 litwol iggy: i am trying to find the correct way to express dependency.
22:10 iggy txomon|home: https://groups.google.com/forum/#!forum/salt-formulas
22:11 litwol iggy: i must have use flags set first. then dependent package installed. THEEEEN the final relevant package installed.
22:12 iggy litwol: why are you using extend?
22:12 litwol iggy: to insert "refresh: False". in all my tests pkg.installed forces repository refresh every time. must be a bug, but i'm not taking chances..
22:13 litwol i'm trying my best to end up using mysql-formula
22:13 litwol learning what i must to be able to use it without alteration to upstream
22:13 baconbeckons VR-Jack: can you explain what you mean by a py render of the state file?
22:14 txomon|home iggy, thanks
22:14 iggy litwol: that sounds like a bug if it's running update on a pkg.installed (it does for pkg.latest however)
22:14 * litwol nods
22:14 litwol i've researched it a while back
22:14 VR-Jack baconbeckons: I seem to recall that you can have python render the file, which basically means turning it into a python script
22:14 litwol after few hours tracking i decided to blindly add refresh:false everywhere.
22:14 iggy litwol: not that knowing it's a bug helps you right now
22:14 Draxx joined #salt
22:14 baconbeckons VR-Jack: oh, i see. yeah, this is getting messy :(
22:14 iggy litwol: I wouldn't be surprised if extend was messing with ordering too
22:15 litwol iggy: i just found it peculiar that i am defining pkg.installed and use flags under same state id, and that state gets split in two. one very top (pkg.install) as expected, one at very bottom (flags)
22:15 litwol strange
22:16 litwol okey tried one more thing just now
22:16 litwol removed extend
22:16 iggy litwol: in my experience, once you start using explicit dependencies, you have to use them everywhere
22:16 litwol my cmake dependency is at the very top. under it i do include mysql.server
22:16 litwol no explicit statement of dependency/require/whatever
22:16 iggy so just add require to everything
22:17 litwol now my lower-included mysql is being executed first, while first defined cmake state is executed last O_O
22:17 litwol fyi i am on the 2015 codebase of salt
22:17 iggy i.e. cmake->pkg.installed should require the use flags stanza
22:17 ajw0100 joined #salt
22:17 litwol iggy: i dont mind adding dependencies. what stopmed me is i couldn't use portage_config.flags as dependency resolution
22:17 litwol i've tried
22:17 litwol sec i'll dpaste
22:18 iggy require: portage_config: mysqld_dependence_cmake
22:18 litwol *gasp*
22:18 litwol grrr damn me. i used portage_config.flags for require
22:18 * litwol sigh
22:19 litwol http://dpaste.com/1G08GA3 works
22:19 litwol iggy: yet again. thx.
22:20 litwol on gentoo it is impossible to install mysql 5.6.x without cmake. and cmake has dependency recursion on jsoncpp
22:20 litwol one must configure cmake to use internal-jsoncpp on cmake to be able to install that to be able to install mysql 5.6.
22:21 litwol iggy: can i ask you about mysql-formula specifically? well, not the formula, but rather jinja2 syntax
22:21 litwol https://github.com/saltstack-formulas/mysql-formula/blob/master/mysql/server.sls
22:21 litwol imports mysql/defaults.yaml
22:21 litwol https://github.com/saltstack-formulas/mysql-formula/blob/master/mysql/defaults.yaml
22:22 litwol hard-coded definitions for various operating systems
22:22 litwol great
22:22 litwol how can i override it without modifying/hacking upstream locally ?
22:22 fyb3r left #salt
22:22 iggy set mysql:lookup pillar values
22:23 speedlight joined #salt
22:23 litwol oh!
22:23 iggy look for lookup in the pillar.example for some inspiration
22:23 litwol so *that's* what that means
22:23 litwol https://github.com/saltstack-formulas/mysql-formula/blob/master/pillar.example
22:23 litwol yes i'm looking at that too
22:23 litwol i am still far from understanding the syntax
22:23 litwol where can i read about the {% merge=... %} syntax?
22:24 litwol oh. maybe it is the grains.filter_by() syntax
22:24 fridder joined #salt
22:24 litwol got it
22:24 litwol http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.grains.html#salt.modules.grains.filter_by
22:25 litwol great. i'll use version-specific pillar values then
22:27 conan_the_destro joined #salt
22:29 iggy yeah, it'll likely take some tinkering (and might even require some formula changes, although it looks like someone did that formula right)
22:32 litwol not exactly. not for gentoo
22:34 iggy I meant in terms of using defaults.yaml, lookup, etc
22:34 * litwol nods
22:38 baweaver joined #salt
22:40 c10 joined #salt
22:41 checho joined #salt
22:41 IOMonster joined #salt
22:42 checho hi everybody. I'm on Ubuntu trying to install a pkg from a http://web/package.deb ...is there any simple way to do it? or should I go through wget -> dpkg on the node? thanks!
22:43 aurynn checho, I *think* that the deb pkg provider is smart enough to grab from the web, but don't quote me on that
22:43 aurynn in any case the file provider definitely is
22:44 hybridpollo joined #salt
22:45 checho I've tried with Name: pkg.installed: - sources:  - name: URL and it didn't like it...
22:46 murrdoc do a gp.get_url
22:46 murrdoc to a location
22:46 murrdoc then install
22:47 checho that's basically what I'm doing using a CMD.... a wget and then a dpkg -i ...
22:47 murrdoc sure
22:47 murrdoc u could right a python states too
22:47 murrdoc to do the same
22:50 txomon|home and yes, I have been writing the email for 35 mins :)
22:50 murrdoc domingo u aight
22:50 checho tks.... I just started using salt and is like learning to fly a plane
22:50 Ztyx joined #salt
22:51 txomon|home murrdoc, about what ?
22:51 Ztyx left #salt
22:51 txomon|home all?
22:53 jalaziz joined #salt
22:55 UtahDave joined #salt
22:56 larkir left #salt
22:58 iggy checho: what was the actual pkg.installed state you tried? (just gist it!)
22:58 iggy sources can be tricky
22:58 Chadk joined #salt
22:59 checho iggy: I've tried pkg.installed:  - sources:  - mypkg1: http://web/mypkg1.deb
22:59 txomon|home anyone here going europython?
23:00 iggy checho: that's it?
23:01 checho iggy: with a name before, but yes, that's what I tried.
23:02 keltim_ joined #salt
23:02 checho iggy: http://pastebin.com/uMWq9U2V
23:03 iggy murrdoc: "gist it!" isn't working
23:03 iggy checho: the second source is wrong
23:04 iggy the name has to match the short version of the uri
23:04 checho iggy: should I split this into two entries?
23:04 iggy - centrifyssh-openssh: http://web/nb/centrify/centrifydc-openssh-6.0p1-5.1.0-deb5-x86_64.deb
23:04 murrdoc :)
23:04 murrdoc we shall try
23:04 subsignal joined #salt
23:05 iggy - centrifydc-openssh: http://web/nb/centrify/centrifydc-openssh-6.0p1-5.1.0-deb5-x86_64.deb
23:05 iggy but hey, if that doesn't work, there's always https://github.com/saltstack-formulas/aptly-formula
23:06 murrdoc #sscepimping
23:06 checho those are two different pkg, should I split them into two entries?
23:06 iggy not necessary
23:06 iggy just make sure both entries are correct ;)
23:07 checho oh.ok. Let me try again.
23:08 bluenemo joined #salt
23:09 bhosmer_ joined #salt
23:10 iggy did you see the difference between what I pasted and what you had?
23:11 checho iggy: tks...it looks like when you do things properly, they work. :-)
23:13 iggy ^5
23:13 litwol Interesting
23:14 dbanck joined #salt
23:14 pedromaltez joined #salt
23:15 iggy also... that's why we paste files when asked because I wouldn't have seen that from the pseudo-code pasted inline in the channel earlier
23:17 I3olle joined #salt
23:21 moloney iggy: So I created my custom grain. In my top.sls the first state makes sure all hosts have the 'python-hwinfo' package and I have 'reload_modules: True' in that state. The next state in top.sls matches hosts based on my custom grain and installs some more packages. The first time I run the highstate 'python-hwinfo' is installed, but the custom grain is not set and so the additional packages are not installed.
23:21 moloney Running it a second time, the grain is recognized and the additional packages are installed.
23:21 iggy so the custom grain matching is in the top.sls?
23:22 moloney Yeah, after the state that installs the dependency.
23:23 checho Hi all:  I have another question: I need to run a command only if a file is a symlink ( not a regular file)...how can I write a condition if a file is a symlink??
23:23 iggy moloney: not surprised, I guess the top file isn't reloaded as well
23:24 iggy moloney: only other thing I can think of is to setup a reactor that installs the package, sync_grains, etc when the minion comes up
23:24 coval3nce joined #salt
23:25 iggy checho: A. rethink what you're doing B. {% if file.is_link('/path/to/something') %} do stuff {% endif %}
23:25 * litwol sigh
23:25 iggy err... {% if salt['file.is_link']('/path/to/something') %} do stuff {% endif %}
23:25 shadowsun checho: cmd.run or salt template?
23:25 litwol i am following mysql-formula example to avoid overriding upstream formula when configuring my desired state through overrides/extends
23:26 litwol alas i've hit a dead end.
23:26 litwol default.yaml defines many configuration options which get /ALL/ written into a end-result file
23:26 litwol and i can't figure out how to /remove/ some lines from being written.
23:26 litwol https://github.com/saltstack-formulas/mysql-formula/blob/master/mysql/files/my.cnf
23:27 litwol line 9 is what merges my pillar overrides with default.yaml
23:27 litwol unfortunately it only adds new items, never removes unwanted items.
23:28 checho shadowsun: any
23:28 moloney iggy: Ok I will give that a shot.  On a related note, I am a bit surprised there isn't more PCI device info in the default grains. I would open a PR but I don't really have the time/resources to sort it out for non-Linux systems (or systems without 'lspci').
23:28 shadowsun checho: See what iggy said then, it uses jinja
23:29 iggy moloney: that kind of stuff can get expensive (the reason the gpu grains are off by default)
23:31 checho shadowsun: Thanks!... I started today with Salt....so far I've been reading several docs, blogs, etc... managed to install a server and using PXE provision an ubuntu + minion and then start playing with sls files..
23:33 kusams joined #salt
23:33 shadowsun checho: I like it a lot, it's very flexible
23:33 bfoxwell joined #salt
23:34 shadowsun checho: I've got two masters, a bunch of minions, and my file backend is all gitfs... for the most part, it works sweet, especially with the dev cycles
23:34 iggy litwol: for example set lookup:config:sections:client:None to avoid rendering the client section... it doesn't look like you can unset individual options (since it's doing a direct pillar.get instead of going through the datamap)
23:34 iggy litwol: I'd open an issue about that
23:35 checho shadowsun: yes...too flexible for newbies like me!....I'm basically converting several  bash scripts into sls ..
23:35 iggy checho: we all started there
23:35 shadowsun checho: Yeah, I converted some into sls too
23:35 shadowsun iggy++\
23:37 coval3nce There a way to look at schedule jobs on the master?
23:37 Tyrm joined #salt
23:38 iggy config.get maybe
23:38 murrdoc salt 'master' schedule.get
23:40 coval3nce that shows miion schedules no?  what about schedules only in /etc/salt/master
23:40 * litwol giving up on mysql-formula for now. too many inflexibilities which i don't know how to fix
23:40 moloney iggy: Should I be using pillars instead of grains for this stuff? Or if I want to do something similiar for SCSI devices (which are much more likely to be hotswapped) I guess grains wouldn't be appropriate?
23:40 Ztyx joined #salt
23:41 Ztyx left #salt
23:44 dwfreed joined #salt
23:44 baconbeckons joined #salt
23:46 litwol Actually. not give up on it. but rather.. sadly.. hack the upstream for own use case.
23:52 coval3nce anyone super familiar with self.loop_interval: in master.py?
23:55 baweaver joined #salt
23:57 otter768 joined #salt
23:57 iggy moloney: won't solve your chicken-egg problem
23:59 iggy moloney: it's dirty, but you could try targeting the package (the one that is targeted using your custom grain in your top file) at everything, and then in the sls file, enclose everything in {% if salt['grains.get']('custom_grain') %} {% endif %}

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