Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-10-07

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

All times shown according to UTC.

Time Nick Message
00:00 Ryan_Lane yep
00:00 Ryan_Lane ok, so it's not completely true
00:00 Ryan_Lane you can also set a variable in jinja
00:00 Ryan_Lane but you need to consider that it'll always run before the states do
00:01 nickjj hmm, that's kind of neat
00:01 Ryan_Lane http://ryandlane.com/blog/2014/09/02/saltstack-patterns-grainstate/
00:01 nickjj i'm not sure where i'd use that but it sounds like it could be useful on occasion?
00:01 Ryan_Lane I actually use that a lot
00:01 Ryan_Lane it works inside of a single run as well. you can register a grain, and later use the value of that grain
00:02 murrdoc u say occasionally in the wiki
00:02 murrdoc uh blog
00:02 murrdoc WHICH IS IT RYAN
00:02 Ryan_Lane :D
00:02 gfa joined #salt
00:02 nickjj ah cool, so you don't need to force reload it?
00:02 Ryan_Lane I use it in exactly 3 places right now
00:02 murrdoc nope
00:02 Ryan_Lane but in those 3 places I'm doing pretty awesome things :)
00:02 __number5__ If Ryan say wiki it means Wikipedia...
00:03 Ryan_Lane I'm using it one place to set a random port for a service
00:03 Ryan_Lane using the random jinja function
00:03 nickjj that first gist in your post looks really awesome
00:03 murrdoc which reminds me, whats the wikipedia bot again
00:03 Ryan_Lane @info
00:03 wm-bot4 http://bots.wmflabs.org/dump/%23salt.htm
00:03 Ryan_Lane !ping
00:04 Ryan_Lane !ping
00:04 wm-bot4 pong
00:04 nickjj do you guys agree with using "require" all of the place too? even if it's not technically needed?
00:04 murrdoc i meant the github for it
00:04 nickjj *all over
00:04 Ryan_Lane nickjj: I never use require
00:04 Ryan_Lane in fact, my internal docs say it's not allowed
00:04 Ryan_Lane using require will modify the order of the states
00:04 Ryan_Lane either you always use it or you never do
00:04 nickjj i watched some tutorial vid where a dude was giving a talk and said to use it, so it's explicit on your intent
00:05 Ryan_Lane if you want to use salt like you do puppet, then require is the way to go
00:05 nickjj i never used puppet
00:05 nickjj i just know it's likely i'll require dependencies
00:05 Ryan_Lane you don't need to
00:05 nickjj quite a few of my ansible roles are used in 10+ other roles
00:05 Ryan_Lane the run is sequential
00:06 nickjj i mean using dependencies in the meta file
00:06 kusams joined #salt
00:06 Ryan_Lane oh, for that you just use include
00:06 Ryan_Lane they'll be included in order
00:06 nickjj perfect
00:07 nickjj i was kind of surprised to see there doesn't seem to be any type of formula package manager
00:07 QuinnyPig Yet!
00:07 nickjj QuinnyPig: are you working on one?
00:07 murrdoc formula package manager ?
00:08 nickjj murrdoc: yeah a place to upload your formulas and then download them through a tool, like pip/gem/ansible-galaxy/etc.
00:08 murrdoc right now thats github/saltstack-formulas
00:08 murrdoc is all
00:08 nickjj and more importantly, version them + resolve deps
00:09 TyrfingMjolnir joined #salt
00:13 eflynn joined #salt
00:13 nickjj Ryan_Lane: would you use jinja variables for what you would consider "private" variables?
00:14 Ryan_Lane I'd use pillars for private variables
00:14 Ryan_Lane ho
00:14 Ryan_Lane er
00:14 Ryan_Lane oh
00:14 mosen hey RL,
00:14 Ryan_Lane you mean private to a module?
00:14 Ryan_Lane if so, then yes.
00:14 Ryan_Lane mosen: sup?
00:15 nickjj Ryan_Lane: private to a formula
00:15 mosen I've probably asked before but cant remember your answer. because pillars arent hierarchical, I'm doing sorta 1 per host type. What's your feeling about organising those?
00:16 nickjj like if you had to do some really gross parsing and you wanted to abstract that to a var to use in 1 or more spots in your states but you don't expect users to ever overwrite it
00:16 Ryan_Lane nickjj: yeah. in jinja
00:16 Ryan_Lane mosen: I make a hierarchu
00:16 nickjj what if that changes to 10 variables, you'd still set them inline to the state file?
00:17 Ryan_Lane man. I can't type today
00:17 aparsons joined #salt
00:17 Ryan_Lane nickjj: not sure. I haven't had that issue yet :)
00:17 Ryan_Lane I try not to set many variables in states or templates
00:17 nickjj Ryan_Lane: to give you a real example https://github.com/debops/ansible-rails_deploy/blob/master/vars/main.yml
00:18 nickjj first 15 lines are definitely something i want to keep tucked away, and are used in multiple areas (tasks and templates)
00:19 shoemonkey joined #salt
00:19 Ryan_Lane I'd probably still use pillars for that
00:19 Ryan_Lane this is something you'd override per host or per service or something?
00:19 nickjj nope, they are internal to the role
00:20 Ryan_Lane sorry. I call roles services
00:20 Ryan_Lane something internal to my implementation
00:20 Ryan_Lane I'd use pillars for that
00:20 nickjj yeah, i think of them as "they benefit me, the developer of the role"
00:20 Ryan_Lane and match by the role
00:20 shoemonkey joined #salt
00:20 nickjj where as defaults/main.yml would be "go nuts overwriting everything here"
00:21 nickjj but also sane defaults would be set there of course
00:25 kusams joined #salt
00:27 Ryan_Lane mosen: my basic hierarchy is generic -> specific
00:28 Ryan_Lane where specific overrides generic
00:28 Ryan_Lane base -> service -> service-environment -> service-environment-region
00:28 nickjj one last question Ryan_Lane, when you said you keep your pillars flat
00:28 nickjj do you mean you don't use foo.lookup.bar but instead foo_bar?
00:28 mosen Ryan_Lane: i see!
00:29 Ryan_Lane nickjj: depends on the situation
00:29 nickjj every single example i see in the formulas organization uses a dict
00:29 Ryan_Lane if I don't expect that pillar to be overriden then I use a dict
00:29 murrdoc nothing wrong with dicts, unles u have the heira burn makrs
00:29 murrdoc marks*
00:29 cads joined #salt
00:29 nickjj let's use a real example https://github.com/saltstack-formulas/nginx-formula/blob/master/pillar.example
00:30 Ryan_Lane yeah...
00:30 nickjj compare that to something like https://github.com/debops/ansible-nginx/blob/master/defaults/main.yml
00:30 Ryan_Lane well, in that case they also implement defaults in the key lookups
00:30 nickjj the ansible one is clearly flat, except for defining a custom vhost (bottom)
00:30 Ryan_Lane so, when you override the entire dict, you still get all the defaults
00:31 murrdoc yeah
00:31 Ryan_Lane I don't like that. it's magical
00:31 murrdoc it reflects how u think of the server
00:31 murrdoc base + decorate
00:31 Ryan_Lane I like to have all my values set in a top level pillar file that gets overridden in more specific places
00:31 Ryan_Lane that way I can go look at the most generic file and see all of the settings
00:31 murrdoc how many types of servers would u be supporting
00:32 nickjj what do you mean by defaults in the key lookup? by using foo.get('var', 'default')?
00:32 Ryan_Lane nickjj: yep
00:32 nickjj i'm with you on that, i don't want defaults scattered everywhere
00:32 nickjj they should be in 1 file
00:32 murrdoc well
00:32 murrdoc defaults for a server ?
00:32 murrdoc or defaults for an implementation
00:32 shoemonkey joined #salt
00:32 murrdoc the nginx formula isnt part of the defaults for the server
00:33 nickjj defaults for some functionality, like setting up nginx, redis, postgresql, ruby, etc.
00:33 murrdoc which u can see in the map.jinja for nginx
00:33 nickjj is it well accepted/common to put a ton of defaults there?
00:34 murrdoc defaults to setup the nginx app
00:34 murrdoc maybe
00:34 murrdoc i like it
00:34 nickjj what if you had a bunch of defaults you wanted to use on both debian and redhat?
00:36 nickjj from what i see so far people seem to be duplicating them
00:36 Ryan_Lane for that you use a map file
00:36 Ryan_Lane and you use the default listed in the map file
00:36 nickjj for example https://github.com/saltstack-formulas/apache-formula/blob/master/apache/map.jinja
00:37 nickjj this guy has the default_site set for all 3 distros, but it's the same value
00:37 murrdoc i guess u could do two merges
00:37 murrdoc but that will lead to regret
00:37 murrdoc :D
00:37 nickjj would most people tend to reserve the map file for things that only change between distros?
00:38 nickjj so it would be 99% different between them
00:38 murrdoc <— is lucky, its all ubuntu
00:38 murrdoc so i havent planned for non ubuntu
00:38 murrdoc still have to handle 10.04 vs 12 vs 14
00:38 nickjj me too, except i use debian wheezy
00:39 murrdoc so for those yeah map.jinja
00:39 nickjj which tend to work on ubuntu
00:39 nickjj 10.04, ouch
00:39 murrdoc its dying
00:39 murrdoc sloooowly
00:42 nickjj are you going to support it until it's eol'd?
00:43 nyx joined #salt
00:44 murrdoc have to
00:44 murrdoc well have to support it till the servers are rebuilt
00:45 murrdoc when they are, build em to 1404 or 1204
00:45 __number5__ ouch, I have much pain even just stay on 1204... can't imagine 1004...
00:45 murrdoc its not too much pain yet
00:46 chayak joined #salt
00:46 murrdoc its all about QoS, on 1004 all thats supported is monitoring
00:47 davidli joined #salt
00:48 davidli I'm struggling a lot with getting pillar data into my state files
00:48 n8n joined #salt
00:48 davidli I'm running a masterless minion in a Vagrant VM
00:49 davidli and looking at the salt directory, all my stuff is correctly defined there.
00:49 davidli But when I call salt-call --local pillar.raw
00:49 davidli I don't see the pillar data I've defined
00:53 pdayton joined #salt
00:57 shoemonkey joined #salt
00:58 __number5__ davidli: is you pillar files in /srv/pillar ?
00:58 davidli It's in /srv/server-config/pillar
00:58 davidli And I have pillar_roots pointing to that
00:59 davidli I see salt parsing the top file and compiling the relevant pillar files
00:59 davidli But when it goes to render the state files, the pillar object does not contain the key
01:01 loz-- joined #salt
01:03 jnials joined #salt
01:04 viq joined #salt
01:06 n8n joined #salt
01:07 malinoff joined #salt
01:09 QuinnyPig Can you set a role in the top.sls file?
01:09 QuinnyPig I don't know why you would, but it's the only thing I'm seeing that would make sense here.
01:09 davidli What is a role?
01:10 QuinnyPig Apparently a custom grain here.
01:10 QuinnyPig Which modifies my question to be "can you set a grain (custom or otherwise) in the top.sls file?"
01:11 RKD that's what pillars are for, no?
01:11 Ryan_Lane QuinnyPig: when you say "set", what do you mean?
01:11 aurynn so, I'm looking at using salt-cloud to bootstrap some VMs. It looks like salt-cloud, the command, will auto-set up the new VMs and hook them back to my master. That's great. But I want to use the orchestration runner as well. Do these things work in together? Or do I use salt-cloud to bring up tin, and then the runner to provision
01:12 davidli And are you referring to the top.sls file for the pillar or for the state?
01:12 aurynn as discrete steps?
01:12 Ryan_Lane you mean you want to set a grain in the top that will apply to the states?
01:12 tru_tru joined #salt
01:12 Ryan_Lane if so, you really want to do that in pillars
01:12 __number5__ QuinnyPig: http://docs.saltstack.com/en/latest/topics/targeting/grains.html#matching-grains-in-the-top-file
01:12 Ryan_Lane since you'd use the same matching level as the state
01:13 davidli If I do a salt-call --local pillar.items, that should return to me all pillar data targeted at the minion, right?
01:15 Ryan_Lane davidli: yep
01:15 Ryan_Lane well, assuming you're not using a master
01:15 QuinnyPig Ryan_Lane, davidli: What I'm seeing here is nutty; they're using an external top, and it returns states (which makes sense) and roles (which makes zero sense; only slightly more when you realize that 'role' is a custom grain)
01:15 Ryan_Lane if you're using a master you may not be able to use --local
01:16 davidli Do you mean the docs?
01:16 davidli *QuinnyPig
01:16 Ryan_Lane QuinnyPig: I'm not sure what roles are
01:18 kickerdog joined #salt
01:18 kickerdog Does anyone remember what you put in the minion config to make it execute state.highstate on it's own on a interval?
01:19 Ryan_Lane kickerdog: http://docs.saltstack.com/en/latest/topics/jobs/schedule.html
01:19 kickerdog Perfect! Thanks!
01:19 QuinnyPig davidli, Ryan_Lane: Sorry. I was misreading this. It's even nutsier than I thought.
01:19 Ryan_Lane yw
01:19 QuinnyPig Disregard me. :-)
01:20 davidli Hah. I feel like this is the most basic incarnation of pillars. I'm not doing anything particularly strange.
01:20 Ryan_Lane davidli: ?
01:21 davidli I'm not sure what I can do to do debug the issue.
01:21 Ryan_Lane davidli: is a pillar not showing up?
01:21 thehaven joined #salt
01:21 Ryan_Lane are you using master/minion or masterless?
01:22 davidli I'm running a masterless minion in a Vagrant VM
01:22 davidli When I provision, I see [DEBUG   ] Rendered data from file: /srv/server-config/pillar/top.sls:
01:22 davidli and [DEBUG   ] Rendered data from file: /srv/server-config/pillar/docker-registry/init.sls:
01:22 N-Mi joined #salt
01:22 Ryan_Lane heh. I made a state for a docker registry just the other day :)
01:23 davidli =]
01:23 anotherZero joined #salt
01:23 Ryan_Lane i'm not totally sure the vagrant provisioner does a great job of setting salt up
01:23 * Ryan_Lane doesn't use the vagrant provisioner
01:24 Ryan_Lane what's in /etc/salt/minion?
01:24 Ryan_Lane also, what problem are you having?
01:24 Ryan_Lane the pillar items just aren't showing up?
01:25 davidli Hmm
01:25 davidli Rendering SLS "base:docker-registry.server" failed: Jinja variable 'dict object' has no attribute
01:26 davidli id: docker-registry0  failhard: True  file_client:   local  file_roots:   base:     - /srv/server-config/salt  pillar_roots:   base:     - /srv/server-config/pillar  grains:   vagrant: true   # Set this to the IP address of the mysql server accessible from the guest.   vagrant_host_mysql: 10.20.30.1
01:26 davidli That's my /etc/salt/minion
01:26 thehaven joined #salt
01:26 davidli If you can.. somehow mentally insert newlines =P
01:29 toddnni joined #salt
01:32 Ryan_Lane heh
01:32 Ryan_Lane davidli: docker-registry.server ?
01:33 Ryan_Lane do you have /srv/server-config/pillar/docker-registry/server.sls ?
01:33 Ryan_Lane or /srv/server-config/pillar/docker-registry.server ?
01:33 Ryan_Lane docker-registry.server is the former
01:33 Ryan_Lane the latter isn't supported
01:34 Ryan_Lane salt treats its sls files like python includes
01:34 Ryan_Lane test/me.sls == test.me
01:36 n8n joined #salt
01:36 jalaziz joined #salt
01:36 jsm joined #salt
01:39 davidli The former
01:39 Ryan_Lane can I see what's in your top.sls and in your docker-registry/server.sls?
01:40 Ryan_Lane (via gist or pastebin or something)
01:40 jalaziz_ joined #salt
01:42 davidli https://gist.github.com/Ghiblian/acddb1609c96260ebccd
01:45 Ryan_Lane is docker-registry in the hostname?
01:45 davidli It's the minion ID
01:45 jnials joined #salt
01:45 davidli and it doesn't work even if I put '*'
01:45 desposo joined #salt
01:45 shoemonkey joined #salt
01:45 Ryan_Lane ok, so what I don't get is why it's complaining about a jinja variable
01:45 Ryan_Lane are you using jinja in server.sls at all?
01:47 ilbot3 joined #salt
01:47 Topic for #salt is now Welcome to #salt | 2014.1.10 is the latest | Help us test the 2014.7 RC! http://bit.ly/salt-rc | 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:47 Ryan_Lane that's the only key in the file?
01:47 davidli Also, it seems to render just fine
01:47 Ryan_Lane and it has a simple value?
01:47 __number5__ content_pillar is your friend for storing key in pillar
01:47 Ryan_Lane salt-call --local pillar.get test
01:47 Ryan_Lane should return the value
01:49 davidli Yah, nothing
01:49 davidli I can't use content_pillar just yet
01:49 Ryan_Lane and the only value you have in your service.sls is test?
01:49 davidli as the Vagrant provisioner uses a slightly older bersion of Salt
01:50 Ryan_Lane just put: 'test: me' into it
01:50 davidli and we haven't yet determined how we'll be handling versioning of salt on our non-vagrant instances
01:51 davidli Yah, that's what I have right now
01:51 davidli Jinja variable 'dict object' has no attribute 'test'
01:51 davidli And doing salt-call --local pillar.items returns nothing
01:51 homelinen joined #salt
01:51 homelinen joined #salt
01:52 Ryan_Lane salt-call --local saltutil.refresh_pillar
01:53 Ryan_Lane I don't see how that would help... but give that a try
01:53 Ryan_Lane I'm not totally sure how the vagrant provisioner sets things up
01:53 Ryan_Lane oh
01:54 shoemonkey joined #salt
01:54 Ryan_Lane do you have '- docker-registry' in your top.sls pillar file still?
01:54 davidli Yes
01:54 Ryan_Lane and if so, do you have a docker-registry.sls or docker-registry/init.sls file?
01:54 davidli docker-registry/init.sls
01:54 __number5__ davidli: try put your pillar under /srv/pillar on your minion, that's the default root for pillar
01:54 Ryan_Lane use: salt-call --log-level debug pillar.get test
01:55 davidli When I do refresh_pillar, I get local: None as the output
01:55 Ryan_Lane it should show you the rendered pillars and such
01:55 davidli Yah, no rendered pillars
01:55 Ryan_Lane there must be something wrong with your config
01:55 davidli when I do pillar.get
01:56 davidli Yah =\
01:56 davidli I'll try number5s suggestion
01:56 Ryan_Lane can you post it in a gist?
01:56 davidli What would you like to see?
01:56 Ryan_Lane I use a non-default location
01:56 Ryan_Lane I'd like to see your pillar roots
01:58 hasues joined #salt
01:58 Ryan_Lane also, is anything in /etc/salt/minion.d/ ?
01:59 shoemonkey joined #salt
02:00 davidli https://gist.github.com/Ghiblian/c2448eaf8e0bf0a0959c
02:00 davidli No there is not
02:00 davidli It exists but is empty
02:01 * Ryan_Lane nods
02:01 Ryan_Lane and in /srv/server-config/pillar/top.sls you have: https://gist.githubusercontent.com/Ghiblian/acddb1609c96260ebccd/raw/3838ca043d02464ece8f148daf4ac04edf3acc20/top.sls
02:02 Ryan_Lane and in /srv/server-config/pillar/docker-registry.sls, you have: test: me
02:02 Ryan_Lane err
02:02 Ryan_Lane and in /srv/server-config/pillar/docker-registry/server.sls, you have: test: me
02:02 jnials joined #salt
02:02 Ryan_Lane and in and in /srv/server-config/pillar/docker-registry/init.sls you have nothing?
02:03 davidli Sorry, that was me fooling around with the name and value
02:03 davidli When I was doing the salt-calls
02:03 davidli It's not a typo issue there
02:03 davidli and as for init.sls, there is stuff
02:03 davidli I replaced the values with ...
02:03 davidli since they are private
02:03 Ryan_Lane right. that's no problem
02:04 Ryan_Lane so. I'd remove docker-registry/server.sls
02:04 Ryan_Lane remove that section from the top file as well
02:04 Ryan_Lane and in init.sls, just put: test: me
02:04 Ryan_Lane and try to get the value of test via pillar.get
02:07 davidli Sorry, I have to run. Thanks for the help so far. That didn't seem to work. But I'll try trimming
02:07 davidli until I just have the two files
02:07 Ryan_Lane cool. yw.
02:07 davidli the state and the pillar
02:13 otter768 joined #salt
02:16 ingwaem joined #salt
02:16 shoemonkey joined #salt
02:20 DenkBrettl joined #salt
02:21 heewa joined #salt
02:21 __number5__ Anyone get 2014.7.0rcX salt-master upstart job working on Ubuntu 12.04?
02:21 __number5__ I can only run master manually using 'salt-master -l debug'
02:25 tkharju joined #salt
02:37 bhosmer joined #salt
02:37 shoemonkey joined #salt
02:41 zz_Cidan joined #salt
02:45 nitti joined #salt
02:47 ingwaem __number5__: hmm, not sure on the specific version but I did have salt-master 2014.7.x running the other day, with minions, was having some trouble with the cloud stuff which was still being updated but as far as I'm aware should be working ok...did it install correctly after you pulled from github?
02:50 hasues joined #salt
02:54 lahwran joined #salt
03:01 shoemonkey joined #salt
03:02 shoemonkey joined #salt
03:02 jnials joined #salt
03:06 toddnni joined #salt
03:06 bhosmer joined #salt
03:08 anotherZero joined #salt
03:09 ramishra joined #salt
03:18 pdayton joined #salt
03:19 pdayton joined #salt
03:25 __number5__ ingwaem: installed is all ok, actually running well if not using the upstart script
03:25 juan_ joined #salt
03:25 juan_ howdy
03:25 juan_ I have a question on syndic
03:26 juan_ so this is my first time setting it up. I have a masterofmaster at home, and have a master in ec2. I launched the master using salt-cloud.
03:27 juan_ I configured the master(slave) to point to my masterofmasters
03:28 juan_ I was able to get the key exchange, and on the master(slave) I can see the confirmation that the masterofmaster has accepted the key
03:28 juan_ but when I try to send a command from the masterofmasters
03:28 juan_ I get no response
03:29 primechuck joined #salt
03:29 juan_ anyone?
03:29 juan_ ..
03:31 ramishra joined #salt
03:33 malinoff juan_, don't think syndic is used widely, its better to ask on mailing list i think
03:34 ramishra joined #salt
03:34 TheThing|laptop joined #salt
03:37 SheetiS joined #salt
03:38 mosen joined #salt
03:43 minkeofh left #salt
03:55 Furao joined #salt
03:56 ek6_ joined #salt
03:57 n8n joined #salt
03:57 juan_ ok thanks
03:59 dccc_ joined #salt
04:05 hjst left #salt
04:10 kickerdog joined #salt
04:19 AGinsberg-0x71 joined #salt
04:19 AGinsberg-0x71 left #salt
04:24 ingwaem __number5__: sorry had gone afk...not sure what has gone wrong...have you tried starting salt-master with debug to see what could potentially be breaking? Additionally run the minion in the debug incase the master is failing on a point that the minion makes contact. failing that would be worth while submitting an issue via github
04:26 __number5__ ingwaem: okay, will try turn on upstart's debug log to see if I can find anything.
04:29 l0x3py joined #salt
04:30 baconbeckons joined #salt
04:50 felskrone joined #salt
04:53 ramteid joined #salt
04:59 n8n joined #salt
05:01 kermit joined #salt
05:03 jnials joined #salt
05:26 linjan joined #salt
05:33 quickdry21 joined #salt
05:39 scalability-junk is salt-cloud going to integrate with kubernetes v1 soon? So you can control the api, start new pods, migrate tasks etc. or should I do that via states, which call the api instead?
05:40 jdmf joined #salt
05:41 linjan_ joined #salt
05:42 schimmy joined #salt
05:44 SheetiS joined #salt
05:46 schimmy1 joined #salt
05:57 jnials joined #salt
06:00 n8n joined #salt
06:01 desposo joined #salt
06:02 jnials joined #salt
06:04 linjan_ joined #salt
06:12 ttrumm_ joined #salt
06:17 n8n joined #salt
06:18 roolo joined #salt
06:23 jalaziz joined #salt
06:23 jalaziz joined #salt
06:30 mechanicalduck_ joined #salt
06:37 stanchan joined #salt
06:46 kingel joined #salt
06:52 superseb joined #salt
06:52 trikke joined #salt
06:53 harkx joined #salt
06:54 oyvjel joined #salt
06:54 flyboy joined #salt
06:57 superted joined #salt
07:01 robinsmidsrod I have this odd problem, that when I leave my salt cluster without doing anything for some extended time (like a day), and when I run salt-run manage.status most of my nodes show up as "down", but if I just wait for like a minute, they eventually all show up as "up". Does anyone know what might cause this? And obviously, while they show up as "down", they are not responding to commands.
07:02 jnials joined #salt
07:04 lcavassa joined #salt
07:07 xtalk joined #salt
07:08 bhosmer joined #salt
07:12 masm joined #salt
07:12 agend joined #salt
07:17 duncanmv joined #salt
07:19 kaictl joined #salt
07:19 zz_Cidan joined #salt
07:23 intellix joined #salt
07:25 zemm joined #salt
07:25 akafred joined #salt
07:27 superted robinsmidsrod - I've seen a bug report around this. If you fire a test.ping equally they come back. I'll see if i can find it if you like?
07:28 robinsmidsrod superted: very much!
07:28 linjan_ joined #salt
07:29 robinsmidsrod superted: I think it might be related to the minions not being able to respond to commands, but if I'm not mistaken, they call in at certain intervals to the master, and that is when the listeners are sort of reactivated - at least that is what it looks like
07:29 superted https://github.com/saltstack/salt/issues/14343#issuecomment-54932256
07:30 superted Your description reminded me of that ticket which is still open if your on 2014.1.x
07:31 robinsmidsrod superted: yep, what the poster wrote is exactly what I experience
07:32 ramishra joined #salt
07:33 adsisco joined #salt
07:34 adsisco any idea why i get "augeas.execute" is not available? i already have it installed on the minion
07:34 CeBe joined #salt
07:36 CeBe1 joined #salt
07:37 stephanbuys joined #salt
07:37 CycloHex joined #salt
07:37 CycloHex Is it possible to use jinja in pillars, yes, right?
07:38 superted robinsmidsrod Probably worth making a note on the case your getting the same issue and your versions, so they know when more people are affected etc...
07:38 markm joined #salt
07:38 robinsmidsrod superted: yeah, I'll make a +1 comment as well
07:40 adsisco anybody have exoerience with salt.states.augeas? can i have an exmaple to add binding 0.0.0.0 please? thanks
07:40 zerthimon joined #salt
07:43 alanpearce joined #salt
07:45 bhi_ joined #salt
07:50 babilen CycloHex: It is. You can also use other renderers for pillars by defining a suitable shebang (e.g. "#!py" for Python -- http://docs.saltstack.com/en/latest/ref/renderers/all/ )
07:51 CycloHex ok, thanks!
07:51 the_drow babilen: It turns out that when writing tests you have to patch __salt__ manually
07:52 babilen the_drow: Yeah, I saw your discussion yesterday. Salt does some funky monkey patching there (which is, IMHO, an ugly solution) and it makes sense that you'd have to replicate that.
07:53 the_drow A fake loader should probably be run before each unit test
07:54 the_drow Why does salt need that?
07:54 the_drow Because of __virtual__?
07:56 fredvd joined #salt
07:56 Schmidt joined #salt
07:56 ramishra joined #salt
07:57 astol joined #salt
07:58 astol1 joined #salt
07:59 chiui joined #salt
08:03 jnials joined #salt
08:15 wnkz joined #salt
08:27 Schmidt joined #salt
08:34 ingwaem joined #salt
08:36 intellix joined #salt
08:38 ndrei joined #salt
08:50 alanpearce_ joined #salt
08:52 ingwaem joined #salt
08:53 msciciel joined #salt
08:54 ingwaem joined #salt
09:01 glyf joined #salt
09:02 jnials joined #salt
09:08 ingwaem joined #salt
09:10 PI-Lloyd joined #salt
09:12 ingwaem joined #salt
09:15 swa joined #salt
09:18 superseb joined #salt
09:18 baconbeckons joined #salt
09:19 swa i want to check for the presence of an item in a pillar list.. i tried this with no luck: {% if "{{ domain }}" in pillar['dns-public']['domain-splitdns'] %}
09:19 swa any idea?
09:20 che-arne joined #salt
09:28 ingwaem left #salt
09:29 ingwaem joined #salt
09:29 PI-Lloyd swa try {% if pillar['dns-public']['domain-splitdns'] is defined %}
09:29 nkuttler swa: is "{{ domain }}" supposed to be a var? i think you just want domain.. but then i'm not a jinja specialist..
09:30 PI-Lloyd oops forgot the bit you are after - {% if pillar['dns-public']['domain-splitdns']['domain'] is defined %}
09:31 swa thanks PI-Lloyd i'll try that
09:32 baconbeckons joined #salt
09:32 PI-Lloyd not sure if that will work or not, just pulling that out of some blog post
09:32 nkuttler swa: or something like {% if var in pillar.get('foo:bar', ()) %}
09:32 swa and indeed {{ domain }} if a var, this whole thing is within a for loop
09:33 swa nkuttler: i found that example, but not sure how it applies in my case since i have nested lists
09:33 swa foo:bar stands for ['foo']['bar'] ?
09:33 nkuttler swa: well, it won't fail if either is undefined
09:35 nkuttler oh wait
09:36 nkuttler you need salt['pillar.get']() syntax for :
09:36 nkuttler http://docs.saltstack.com/en/latest/topics/pillar/#pillar-get-function
09:37 PI-Lloyd from my understanding you only need .get if you want to retrieve the value, not check for the presence of a value
09:37 swa nkuttler: thank didn't find that link
09:37 swa actually i want to check the presence of the value in the list
09:37 nkuttler PI-Lloyd: {% if pillar['dns-public']['domain-splitdns'] is defined %} will error is dns-public isn't set
09:38 PI-Lloyd true
09:39 superted Question on targeting chaps, if i want to run a command on a set of servers, can i make it run on a subset of the target if they meet a certain condition? Example being remove duff-file if /var < 20% free?
09:39 nkuttler swa: {% if domain in salt['pillar.get']('dns-public:domain-splitdns', ()) %} should work i think
09:39 PI-Lloyd ^^
09:39 nkuttler swa: but if you trust your pillar data 100% to be complete you can make it simpler..
09:40 swa nkuttler: ok how would that be? :)
09:40 nkuttler swa: how would what be?
09:41 swa simpler
09:41 swa i'm all for making things as simple as possible, but jinja can be a pain
09:41 nkuttler swa: your first attempt was almost right, but "{{ domain }}" should be interpreted as string, "{{ domain }}"
09:41 nkuttler e.g., not the var
09:42 swa yeah that's what i figured
09:42 nkuttler personally, i don't trust pillar data to be well-formed
09:42 swa oooh i could use "set"
09:42 unbmatt joined #salt
09:43 zemm_ joined #salt
09:43 nkuttler swa: why not just {% if domain in pillar['dns-public']['domain-splitdns'] %}
09:43 hotbox joined #salt
09:43 wedgie_ joined #salt
09:43 nihe_ joined #salt
09:43 wedgie_ joined #salt
09:43 minaguib_ joined #salt
09:43 DenkBret1l joined #salt
09:43 eliasp_ joined #salt
09:44 swa nkuttler: alright here's the code
09:44 swa {% for domain in pillar['dns-public']['domain'] %}
09:44 swa zone "{{ domain }}" {
09:44 swa {% if pillar['dns-public']['master'] == grains['nodename'] %}type master;
09:44 swa {% if {{ domain }} in salt['pillar.get']('dns-public:domain-splitdns', ()) %}
09:44 swa so apparently in an if statement, {{ domain }} is processed as a string, right
09:45 nkuttler swa: if domain is a var just use the word domain, no quotes or braces
09:45 nkuttler afaik you can't nest {{}} in {%%}, surised it's not an error
09:45 nkuttler surprised
09:46 swa nkuttler: thanks!
09:46 swa that works
09:46 kalail_ joined #salt
09:46 moderation_ joined #salt
09:46 akafred joined #salt
09:46 swa seriously this is confusing at best
09:46 mpoole joined #salt
09:47 jagardaniel joined #salt
09:47 superseb joined #salt
09:47 nkuttler swa: well, you don't *have* to use jinja :)
09:49 nkuttler swa: you can write pure python if you like, see renderers
09:49 chronojam joined #salt
09:53 swa nkuttler: i need to learn python a bit more before i can do that :)
09:53 swa nkuttler: thanks again, really appreciated, i've been trying for an hour :)
09:53 kingel joined #salt
09:57 jrluis joined #salt
09:57 ttrumm joined #salt
09:59 ttrumm_ joined #salt
09:59 kingel joined #salt
09:59 chronojam joined #salt
10:00 martoss joined #salt
10:02 jnials joined #salt
10:03 jagardaniel hi :) just a simple question - i'm using a map.jinja to separate package name for debian and centos - which works fine for debian. but when i'm running my state towards a centos machine, i got errors where the variable couldn't be found. So it seems like it doesn't read the centos part of the map.jinja at all
10:03 jagardaniel grains.items looks nice and i tried to match on osfullname (not sure what the default is)
10:04 giantlock joined #salt
10:04 chronojam Heya guys, im at my wits end over here and hoped you might be able to help! - Ive got a minion that ive recently set to use dual master mode, but it doesnt seem to be able to pull files( states, modules or anything really) from the base environment directory on the new master (/srv/salt), using cp.get_dir/file simply returns nothing likewise state.show_top returns empty. Ive verified the file_roots on both minion and master and they
10:05 chronojam (we only use a single environment so running with the default file_roots in both cases)
10:05 johtso argh, I'm having trouble with my masterless minion, none of the pillar data seems to be there
10:05 johtso the /etc/salt/minion config looks kosher, and if I enable verbose logging I can see the relevant pillar files being rendered
10:06 johtso but when I call `sudo salt-call pillar.items` I don't see any of the data
10:06 johtso is there some way to debug?
10:09 bhi_ joined #salt
10:10 johtso Yeah, I'm really confused, what could cause pillar data that's being rendered, not to appear in the output of `pillar.data`?
10:13 ntropy johtso: does running salt with 'salt-call --local' not help?
10:17 ttrumm joined #salt
10:19 acabrera joined #salt
10:21 johtso ntropy: nope, it's running locally anyway
10:21 johtso salt-call 2014.1.11 (Hydrogen)
10:23 johtso If I see this in the logs after running `sudo salt-call pillar.data -l debug`.. that data should be visible in the output right? http://hastebin.com/zopeniqusu.yaml
10:26 chiui I think I'm having the same problem, trying to downgrade to 2014.1.10
10:29 chiui it works on 2014.1.10 :)
10:30 chiui so pillar data is empty on 2014.1.11
10:30 chiui seems that it's rendered, but it is not available
10:30 chiui I'd blame this https://github.com/saltstack/salt/commit/280e1fe4500d2145d16b1d92c9f4053b78863235
10:33 ttrumm_ joined #salt
10:34 johtso chiui: how did you install 2014.1.10?
10:36 chiui yes
10:36 ndrei joined #salt
10:36 chiui wget and dpkg from the ppa
10:37 djstorm joined #salt
10:39 johtso @chiui want to chime in on https://github.com/saltstack/salt/issues/16428 ?
10:40 chiui sure
10:42 ntropy johtso: please also add your debugging output showing how to reproduce the issue
10:44 TyrfingMjolnir joined #salt
10:52 seblu42 joined #salt
10:56 chiui ntropy, added a comment there, hope it's sufficient :)
10:58 martoss joined #salt
10:59 martoss1 joined #salt
11:01 johtso well, at least I'm back in action now on 2014.1.10 :)
11:02 jnials joined #salt
11:06 ttrumm joined #salt
11:06 cloudshare joined #salt
11:06 cloudshare hi
11:06 scottpgallagher joined #salt
11:08 giantlock joined #salt
11:08 rattmuff joined #salt
11:08 rlarkin joined #salt
11:08 jeffrubic joined #salt
11:08 hellome joined #salt
11:08 martin_ joined #salt
11:10 cloudshare anyone here how to supress the stdout from cmd.script?
11:10 cloudshare anyone here know how to supress the stdout from cmd.script?
11:13 rattmuff cloudshare: You should be able to use "output_loglevel"
11:13 cloudshare rattmuff: already tried 'output_loglevel = quiet'
11:14 giantlock_ joined #salt
11:14 ingwaem joined #salt
11:14 johtso Is it normal for the previous version to be unavailable when a new version is pushed to the ubuntu salt PPA?
11:15 johtso seems a little extreme
11:15 hobakill joined #salt
11:16 ingwaem joined #salt
11:17 rattmuff cloudshare: and set it to quiet
11:17 rattmuff cloudshare: last attribute in the list: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.cmd.html#salt.states.cmd.script
11:17 cloudshare rattmuff: I'm trying to run in the salt states a 'configure make install script'
11:18 rattmuff cloudshare: I never used it myself unfortunately so I'm afraid I can't be of much assistance. Perhaps someone else has more in-depth knowledge?
11:21 martoss joined #salt
11:24 cloudshare here is the actual state I've used http://pastebin.com/raw.php?i=dZSnwewy
11:24 cloudshare running it under  'salt-call --local state.highstate'
11:31 homelinen joined #salt
11:31 intellix joined #salt
11:32 agend hi - how can I install salt on coreos - bootstrap script is not working
11:32 the_drow agend: coreos has a readonly file system
11:32 the_drow It's probably not possible yet
11:32 diegows joined #salt
11:32 the_drow agend: Ask on #coreos
11:33 agend the_drow: i did ask, but got no response - does it mean i should do everything in containers?
11:34 the_drow Don't use salt minion in a container
11:34 the_drow Just use dockerfiles for now
11:34 agend the_drow: i want to use salt to create and start containers for me
11:34 the_drow well you can start containers but you can't create them using salt yet
11:35 the_drow agend: See https://github.com/docker/docker/issues/8032
11:35 the_drow agend: Systemd takes care of starting your containers in coreos
11:36 diegows joined #salt
11:36 bhosmer joined #salt
11:36 agend the_drow: i'm confused
11:36 the_drow agend: about?
11:36 agend the_drow: thought i could provision containers just like i did with vm's
11:37 the_drow not really
11:37 the_drow You can install a minion in a container and use that to provision the container but you won't get any caching
11:38 agend i dont want minion in container
11:38 the_drow That is unless you run your states manually (without the highstate)
11:38 agend i want salt to create the containers for me
11:38 cloudshare found it to supress the output from the script had to redirect the output stdout > /dev/null
11:38 the_drow agend: It's not possible
11:38 the_drow Read the docker issue I opened
11:39 the_drow agend: Define create,
11:39 the_drow Salt can execute a build
11:39 agend the_drow: thought that states.dockerio.running would do it for me
11:40 the_drow But it won't provision the container itself. It will simply ensure that it is running
11:40 agend the_drow: Ensure that a container is running. If the container does not exist, it will be created from the specified image. (docker run)
11:40 agend the_drow: from docs
11:41 the_drow agend: That's not the same as provisioning the container
11:41 the_drow agend: You can't build a container with a set of salt states
11:41 the_drow You can only use a dockerfile
11:42 johtso what's the correct way to include a private ssh key in a pillar file?
11:42 the_drow agend: But on coreos you don't want to use docker run because systemd is the component that takes care of doing that for you
11:42 johtso I'm struggling with the salt multi-line syntax and the hyphens being interpreted as list syntax
11:42 the_drow johtso: Are you familiar with blackbox?
11:42 johtso nope, is that an external datastore for keys?
11:42 the_drow johtso: https://github.com/StackExchange/blackbox
11:43 the_drow Not exactly
11:43 agend the_drow: so i shouldnt use salt at all on coreos - should i go with 'fig'?
11:43 wnkz__ joined #salt
11:43 the_drow agend: No. Systemd takes care of deamonizing the containers
11:43 johtso ah yes, I'd heard of that, haven't played with it yet though
11:44 the_drow It's probably a good idea
11:44 the_drow johtso: If you're using gitfs just write a reactor that invokes the blackbox scripts in order to decrypt the keys
11:44 agend the_drow: sorry - u mean i should use salt or not - and for what then if yes?
11:45 the_drow You can manage the os's configuration with salt (/etc/*)
11:45 the_drow You can use salt cloud to scale instances or define autoscale groups
11:45 the_drow You can use salt to generate HAProxy config for load balancing
11:46 the_drow And lots of other stuff
11:46 agend the_drow: but i can do it with dockerfile as well
11:46 the_drow You can pull/push/run containers
11:46 agend the_drow: except salt cloud thing
11:46 the_drow But you shouldn't on core os
11:47 wnkz joined #salt
11:48 agend the_drow: thanks for now - have to think about it, and read some more docs
11:49 Voziv joined #salt
11:49 wnkz joined #salt
11:50 johtso why does this throw a rendering error? http://hastebin.com/oqajarosod.yml
11:50 agend the_drow: one more thing - u said not to put salt-minion inside docker - why - i've read some people do it
11:51 istram joined #salt
11:52 ndrei joined #salt
11:56 wnkz joined #salt
11:58 martoss joined #salt
11:58 wnkz joined #salt
11:58 the_drow agend: Because a container should run only one process unless it is not possible
11:59 the_drow try to do it and see if you benfit anything
12:00 heewa joined #salt
12:01 wnkz joined #salt
12:01 jeffspeff joined #salt
12:02 flyboy82 joined #salt
12:02 jnials joined #salt
12:06 wnkz joined #salt
12:06 TheRealBill joined #salt
12:07 wnkz joined #salt
12:08 wnkz joined #salt
12:09 CycloHex anyone here with some experience with reactors? I just found out about the reactor system and am trying to create myfirst reactor file.. whenever I try to run a highstate now, it gives me an error, compiling my reactor file.. Although I almost copied the content from saltstack docs
12:11 CycloHex here is my reactor setup: https://gist.github.com/Cyclohex/9a5d7bdee63ebd4fe423
12:11 bhosmer joined #salt
12:15 ttrumm__ joined #salt
12:16 wnkz joined #salt
12:17 wnkz joined #salt
12:18 martoss joined #salt
12:19 martoss joined #salt
12:20 CycloHex ok, I no longer get an error.. probably because I shoul'dve ran a highstate first or a sync_all..
12:21 ttrumm joined #salt
12:22 giannello joined #salt
12:23 CycloHex I want some of my minions to have an sls-file named after their ID, is it possible to make salt store a file on the salt-maste ritself? Or do I have to manually create it?
12:24 bhosmer joined #salt
12:26 teebes joined #salt
12:28 wnkz joined #salt
12:30 eflynn joined #salt
12:30 wnkz joined #salt
12:30 scott_w joined #salt
12:30 wnkz joined #salt
12:32 cpowell joined #salt
12:36 ingwaem joined #salt
12:37 ingwaem left #salt
12:37 scott_w joined #salt
12:39 vejdmn joined #salt
12:41 martoss joined #salt
12:43 martoss1 joined #salt
12:47 nitti joined #salt
12:49 wnkz joined #salt
12:53 jalaziz_ joined #salt
12:53 martoss joined #salt
12:53 ndrei joined #salt
12:55 martoss1 joined #salt
12:56 scott_walton joined #salt
12:57 wnkz joined #salt
13:02 jsm joined #salt
13:07 martoss joined #salt
13:08 gmcwhistler joined #salt
13:09 miqui joined #salt
13:10 martinp joined #salt
13:10 higgs001 joined #salt
13:13 wnkz joined #salt
13:13 analogbyte joined #salt
13:14 mpanetta joined #salt
13:16 mpanetta_ joined #salt
13:17 wnkz joined #salt
13:18 scott_w joined #salt
13:20 ajolo joined #salt
13:20 kusams joined #salt
13:20 kusams joined #salt
13:20 salt-n00b joined #salt
13:21 martoss joined #salt
13:22 wnkz joined #salt
13:23 XenophonF joined #salt
13:27 elfixit joined #salt
13:30 wnkz joined #salt
13:31 anotherZero joined #salt
13:32 tomspur joined #salt
13:33 wnkz joined #salt
13:34 wnkz joined #salt
13:38 CycloHex Is it possible to check if a certain file existson the master in a sls file (also located on the master)
13:38 perfectsine joined #salt
13:40 manfred only if you are running a minion on the master
13:40 manfred then you would need to do a publish.publish to ask the master if it has the file
13:42 manfred CycloHex:  you don't run the reactor when you run a highstate
13:42 manfred you configure the reactor in /etc/salt/master, and it should only run on events
13:42 wnkz joined #salt
13:43 CycloHex yes, that is what happens now
13:43 manfred https://github.com/gtmanfred/blog-sls/tree/master/reactor
13:44 _mel_ joined #salt
13:44 NotreDev joined #salt
13:44 DaveQB joined #salt
13:44 rallytime joined #salt
13:45 CycloHex I'm now trying to work some minion-specific things... This is why I need to check in and init.sls whether a file exists or not.. if it exists use include, esle just don't do anything
13:45 CycloHex right now i get a data compile failed
13:45 CycloHex because in this case the file doesn't exist
13:45 wnkz joined #salt
13:46 _mel_ Hi. i try to create a simple vsftpd sls file. but i can't test it, because i always get an error: http://pastebin.com/8LYiCV5Y
13:47 _mel_ what am i doing wrong?
13:48 CycloHex not sure if it will help, _mel_, but try to require the conf file in the service as well.. As it might be needed to start the service
13:48 CycloHex not sure though, since I haven't used vsftpd
13:49 DaveQB_ joined #salt
13:49 wnkz joined #salt
13:50 avn hi all! Can you suggest me tool/howto for continious integration/deploy/delivery using salt?
13:50 to_json joined #salt
13:53 micah_chatt joined #salt
13:54 martoss joined #salt
13:56 scott_walton joined #salt
13:56 rojem joined #salt
13:57 dude051 joined #salt
13:58 kaptk2 joined #salt
13:58 _mel_ CycloHex: still the same error
13:59 CycloHex _mel_: sorry, can't help you then :/
14:00 CycloHex Is it possible to teel an sls file with jinja to include a specified file, only if condition
14:00 CycloHex teel=tell*
14:01 wnkz joined #salt
14:01 UtahDave joined #salt
14:02 UtahDave left #salt
14:02 stephanbuys joined #salt
14:03 jnials joined #salt
14:04 CycloHex Is it possible to tell an sls file with jinja to include a specified file, only if condition
14:05 jaimed joined #salt
14:07 martoss joined #salt
14:08 _mel_ maybe it can't be tested?
14:08 jwitrick joined #salt
14:09 N-Mi joined #salt
14:12 manfred CycloHex:  so, the problem you are going to run into, you can't include the .sls from the minion, that all has to be included from the master, where the highstate data is rendered
14:12 martoss1 joined #salt
14:13 martoss2 joined #salt
14:14 CycloHex What I'm trying to achieve, manfred, is that all my minions upon highstate check whether the file {{ grains.get('id') }}.sls exists, else they just do nothing. now, every minions tries to include that file, but for some minions it doesn't exist, so they get a data failed tocompile and won't run highstate
14:16 CycloHex For now i've set up the following workaround: I create the {{id}}.sls and then give that minion a grain generic:true. In my top file I filter for grain generic:true, then include the file
14:17 CycloHex So it works, but I was wondering if it was possible to use jinja to see if the file exists, so that I didn't have to set the grain
14:18 timoguin CycloHex: I *think* there's a function somewhere to list the available SLS files...
14:18 timoguin Can't find it right now though, so I may be making that up
14:18 CycloHex timoguin, thanks, i'll look for it
14:20 CycloHex timoguin, I think it's a module you are talking about, salt.modules.state.show_sls
14:21 timoguin that's different. that'll show the rendered version of a specific SLS file
14:21 djstorm joined #salt
14:22 SheetiS joined #salt
14:22 intellix joined #salt
14:22 rattmuff I'm looking at the documentation for grains.filter_by and I'm having problems wrapping my head around what this really does: "merge=salt['pillar.get']('apache:lookup'))". Anyone that could explain?
14:23 rattmuff Especially this part: "'apache:lookup'"
14:23 timoguin rattmuff: so grains.filter_by will filter based on the os_family by default, or you can filter on some other grain by passing an argument
14:23 manfred timoguin:  show_low_sls?
14:24 jsm joined #salt
14:24 timoguin rattmuff: what that piece will do is look things under the apache:lookup pillar and overwrite any matching keys it finds
14:24 timoguin the lookup part is just a convention. it could be any other pillar you'd want to override with
14:25 rattmuff timoguin: oh ok, I thought it was magic :P. I seem to run into it in all examples I look at but noone really seems to use it
14:25 rattmuff timoguin: thanks
14:25 timoguin rattmuff: I use it so our devs can spin up local VMs without having to configure pillar or anything
14:25 timoguin but on our prod machines i have pillar values that override the defaults
14:26 ramishra joined #salt
14:27 KennethWilke joined #salt
14:28 timoguin manfred: that's different than what i was thinking to. i don't think the function i was thinking of exists.
14:30 manfred kk
14:30 heewa joined #salt
14:31 rattmuff timoguin: nice, I'm looking at it for user handling based on this gist: https://gist.github.com/viq/ec276c183bd84e90606d . Trying to figure out if I can use multiple pillar keys in the same template (like 'users', 'priv_users' defined in separate pillars)
14:33 timoguin rattmuff: you could have two variables defined in map.jinja. right now it just defines 'users'
14:33 timoguin could have a second import line like this: {% from "users/map.jinja" import priv_users with context %}
14:34 rattmuff timoguin: oh, nice
14:35 timoguin that formula by default will look for a sudouser key under the user and configure sudo if it's there
14:37 TyrfingMjolnir joined #salt
14:39 rattmuff timoguin: So I could just extract the lookup_dict like "{% set my_dict = {'Debian': ... } %} and reuse it as the argument for both variable declarations?
14:39 minektur joined #salt
14:39 quickdry21 joined #salt
14:40 timoguin rattmuff: yep
14:40 rattmuff timoguin: ooo, really starting to like Jinja :D
14:40 scoates joined #salt
14:41 timoguin I hated jinja at first. Loving it more and more as I continue to use it.
14:41 rattmuff timoguin: yup, found it annoying 2 weeks ago, now it's becoming nicer and nicer!
14:42 primechuck joined #salt
14:43 dccc_ joined #salt
14:45 aquinas joined #salt
14:47 dvestal joined #salt
14:49 conan_the_destro joined #salt
14:49 scoates joined #salt
14:50 to_json1 joined #salt
14:51 mitsuhiko joined #salt
14:52 mitsuhiko Hi. since when does state.highstate return all the output even if no change is performed?
14:52 SheetiS joined #salt
14:53 N-Mi joined #salt
14:54 hobakill anyway to check if the salt-master is properly pulling from a git repository?
14:55 pdayton joined #salt
14:55 wendall911 joined #salt
14:56 anotherZero joined #salt
14:56 bhosmer_ joined #salt
15:00 eunuchsocket joined #salt
15:00 StDiluted joined #salt
15:00 thedodd joined #salt
15:01 tmh1999 joined #salt
15:02 CycloHex I have made a reactor.conf in master.d, this file has a salt/cloud/*/created in it, it should then run startup_highstate.sls.. Whenever I deploy a cloudVM, it doesn't highstate automatically :(
15:02 CycloHex I know this because I cannot log in to the server as it asks root pw, while it should have my keys
15:05 SheetiS CycloHex: Have you tried to look at the events to make see if your reactor is triggered?
15:06 CycloHex to do that I have to service salt-master stop, then start in -l debug mode
15:06 CycloHex ?
15:06 conan_the_destro joined #salt
15:07 SheetiS No 1 second I'll get you a link
15:07 jonasbjork joined #salt
15:07 SheetiS http://docs.saltstack.com/en/latest/topics/reactor/#knowing-what-event-is-being-fired look at the eventlisten script mentioned in this link
15:07 SheetiS It will help you see exactly what is going on.
15:08 CycloHex ok, thanks
15:08 timoguin CycloHex: you could also configure that in the cloud profile, so you don't have to use reactors
15:08 gibigiana joined #salt
15:08 timoguin startup_states can be configured with a list of SLS files
15:08 jonasbjork I have started to try out Saltstack for my servers in Amazon EC2 and have an issue with instances that auto starts (autoscale). They attach to salt-master but key needs to be verified on salt-master before minions work. Is there any best practices for how to solve this?
15:08 SheetiS timoguin++
15:08 zerthimon joined #salt
15:09 CycloHex timoguin, yes, but sometimes the startup_states= highstate interfere with salt-cloud so that the highstate will never be ran
15:09 timoguin jonasbjork: https://github.com/saltstack-formulas/ec2-autoscale-reactor
15:09 SheetiS jonasbjork: I use a reactor that auto-accepts keys if the hostname matches what I expect
15:09 mechanicalduck joined #salt
15:10 timoguin jonasbjork: that uses amazon SNS and salt reactors to bootstrap servers when they get spun up
15:10 pdayton1 joined #salt
15:10 jonasbjork wow, that was a fast response :) I'll check it out. Thanks!
15:12 penguin_dan joined #salt
15:14 CycloHex SheetiS, I have the script running and I can see the event with the tag, but it doesn't say whether a reactor is being called or not
15:14 CycloHex should it show that it called a reactor?
15:14 SheetiS You'd see another state trigger from the reactor
15:15 bhosmer_ joined #salt
15:15 CycloHex So I guess I can assume my reactor is just not working
15:16 jonasbjork timoguin: as I understand from the docs it uses the instance id (i-xxxxxx) as identifier. I am looking for something that can select salt config based on hostname (like www-001, www-002, mail-001, ...). Is that possible? Do you know?
15:18 to_json joined #salt
15:20 bmonty joined #salt
15:20 timoguin jonasbjork: I'm sure it could be modified to use any information that SNS can send.
15:20 ttrumm joined #salt
15:21 hasues joined #salt
15:22 jonasbjork timoguin: thanks, I'll dive into it.
15:22 kickerdog joined #salt
15:22 thedodd joined #salt
15:24 kickerdog left #salt
15:26 pdayton joined #salt
15:27 ipmb joined #salt
15:29 higgs001 joined #salt
15:31 ericof joined #salt
15:33 fannet joined #salt
15:34 MTecknology I have some dev guys that have host-*-dev, host-*-test, and host-*. They currently have one git repo that manages all hosts. However, they're now looking to have a dev and test branch in the repo. How hard is it to transition to different branches being used for different server groups?
15:34 kingel joined #salt
15:34 MTecknology I've never played with anything like that at all.
15:34 ckao joined #salt
15:35 iggy not terribly difficult (once you get some of the basic stuff sorted in your head)
15:35 eliasp I agree
15:36 eliasp as I mentioned multiple times here: make sure your top.sls files are not part of the branches… use a separate git repo for them
15:36 iggy if you're already using salt, it should be pretty quick
15:38 jonasbjork_ joined #salt
15:38 babilen MTecknology: git branches are seen by salt as different environments (and no, you have no control over that) and you can, naturally, assign different hosts to different environments.
15:39 eunuchsocket interesting idea to use a separate repo for top.sls.  I was struggling with how to handle that
15:40 babilen There is no other way if you want to use proper git workflows
15:40 babilen (unfortunately I have to say)
15:41 iggy eunuchsocket: ikr, he said that yesterday and blew my mind
15:41 schimmy joined #salt
15:41 eunuchsocket it makes sense but it unfortunately makes promotion of changes in top.sls kind of ugly
15:42 XenophonF does Salt require Python 2.7, or will it build under 2.6?
15:42 iggy 2.6
15:43 iggy at least (that's what epel has for ancient redhat)
15:43 MTecknology I have one top.sls that I'm using in a different repo (my repo) of things I want applied to every system regardless of anything. Their repo has no top.sls in it
15:44 schimmy1 joined #salt
15:45 PI-Lloyd joined #salt
15:45 eunuchsocket so I'm trying to imagine how this would work (I'm using subversion hence not gitfs).. I would have a base repo that only has top.sls and then a different repo with all the states/pillars/formulas
15:45 babilen You cannot, yet, keep pillars in your repo, but pray continue
15:46 eunuchsocket babilen: why not?
15:46 eunuchsocket babilen: I'm not using gitfs
15:46 babilen Because you cannot set the "root" parameter specifically for pil ......
15:46 babilen Ah, yeah, sure ... no problem then if you manage that manually.
15:46 kedo39 joined #salt
15:47 eunuchsocket babilen: I guess I'd have to keep my  top pillar out of the repo too
15:47 babilen I guess so, but it really depends on how you use your subversion repo. (haven't used that in something like seven years)
15:52 beneggett joined #salt
15:53 scottpgallagher joined #salt
15:54 babilen eunuchsocket: Branches are a pain in SVN (I seem to remember) so you will probably end up with explicit directories for your different environments anyway and configure those in your master configuration. There isn't much "merging" going on in that case, but more of a copying around though.
15:55 snuffeluffegus joined #salt
15:58 dvestal joined #salt
16:00 TheThing|laptop joined #salt
16:00 cromark joined #salt
16:03 linjan_ joined #salt
16:05 joem86 joined #salt
16:06 tmh1999 joined #salt
16:07 joem86 Is salt the right provisioning solution to learn if I'm new to the scene? i.e., is it pretty noob friendly? I have minimal experience with chef-solo
16:07 honestly salt is pretty easy.
16:07 tcotav ruby background -> chef, python background -> salt
16:07 Eugene I found it easy. Give the intro docs a read-through and enjoy.
16:07 joem86 java/groovy/C++ background :-)
16:08 tcotav hehe
16:08 joem86 though I did do some python in college. Is it still a mess between python2/3?
16:08 dalexander joined #salt
16:08 tcotav no idea -- I don't go near python3 :D
16:08 iggy salt is python2, but yes... still a mess
16:08 tcotav ^
16:08 PI-Lloyd joined #salt
16:09 joem86 haha, well python2 was fun. Cool, I'll dive into the docs today then
16:09 tcotav salt is pretty easy to get rolling though.
16:09 joem86 thanks for the advice
16:09 iggy there's an article on ryan_lane's blog that compares salt and some others
16:10 iggy http://ryandlane.com/blog/2014/08/04/moving-away-from-puppet-saltstack-or-ansible/
16:10 iggy joem86: ^
16:10 joem86 cool, thanks. will read
16:11 forrest joined #salt
16:12 utahcon grains.filter_by, can you match on wildcards? http://pastie.org/9628071
16:13 desposo joined #salt
16:13 scottpgallagher joined #salt
16:13 hardwire joined #salt
16:13 johtso how would I best use something like os.path.join in a salt state?
16:14 XenophonF left #salt
16:14 johtso I'm surprised I haven't seen any info anywhere.. constructing paths is such a common thing in states
16:16 perfectsine joined #salt
16:17 jayne joined #salt
16:19 * geekatcmu actually recommends playing with several systems if you have the time/energy.  The compare/contrast is useful.
16:20 geekatcmu Build something with salt.  Then build it with Puppet.  Then build it with cfengine.  Then build it again with salt (you'll do things differently the second time)
16:20 geekatcmu They point being that different systems have different idioms.
16:21 geekatcmu Note that the three that I suggested are all declarative CMs.  chef is imperative, and thus even more different.
16:21 Gareth joined #salt
16:21 geekatcmu Well, OK, Chef has a declarative DSL, too.
16:21 Ryan_Lane joined #salt
16:21 geekatcmu But it *feels* more imperative.
16:22 joem86 Would you recommend a salt+vagrant workflow?
16:22 ipmb joined #salt
16:23 smcquay joined #salt
16:23 * geekatcmu recommends "whatever is an appropriate fit for your environment"
16:23 * TheThing|laptop recommends all the things
16:24 forrest joem86, I've been using salt + lxcs pretty well for testing
16:25 tcotav joem86: I use salt+vagrant, yes
16:25 tcotav but agree with geetatcmu.  whatever works.  I dev with vagrant
16:28 KyleG joined #salt
16:28 KyleG joined #salt
16:28 drybjed joined #salt
16:29 aparsons joined #salt
16:32 baconbeckons joined #salt
16:32 pdayton joined #salt
16:33 Gareth morning morning
16:33 joem86 cool, this is gonna be a fun week :-P
16:33 forrest hey Gareth
16:33 bivers joined #salt
16:34 N-Mi joined #salt
16:34 nebuchadnezzar joined #salt
16:35 aleszoulek joined #salt
16:35 NV joined #salt
16:36 thedodd joined #salt
16:36 jonasbjork joined #salt
16:38 davidli joined #salt
16:39 ajolo_ joined #salt
16:41 modafinil joined #salt
16:41 johtso joined #salt
16:43 thunderbolt joined #salt
16:43 Gareth forrest: morning.
16:43 forrest YARR
16:43 octarine joined #salt
16:45 akafred joined #salt
16:46 joeyparsons joined #salt
16:46 kermit joined #salt
16:47 munhitsu__ joined #salt
16:49 aleszoulek joined #salt
16:50 copelco joined #salt
16:52 wnkz joined #salt
16:53 akoumjian joined #salt
16:53 aparsons joined #salt
16:53 sag47 joined #salt
16:54 aparsons joined #salt
16:54 wavis joined #salt
16:54 johtso Why do the docs say "Process group names should not include a trailing asterisk" and then show an example with a trailing asterisk? http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.supervisord.html#salt.modules.supervisord.restart
16:55 JonGretar_ joined #salt
16:55 TheThing|laptop joined #salt
16:56 mihait__ joined #salt
16:56 schimmy joined #salt
16:56 grepory joined #salt
16:57 schimmy1 joined #salt
17:00 whiteinge joined #salt
17:00 spookah joined #salt
17:00 to_json joined #salt
17:01 pipps joined #salt
17:05 forrest johtso, which example has a trailing asterisk?
17:05 johtso forrest: all of them. "salt '*' supervisord.restart <group>:"
17:05 johtso oh crap, brain fart.
17:05 forrest johtso, :P
17:05 johtso asterisk /= colon
17:06 felskrone joined #salt
17:06 micah_chatt joined #salt
17:06 johtso that's what happens when your brain is expecting to read something :P
17:06 forrest hah
17:08 whiteinge utahcon: grains.filter_by does not support wildcards. there is an open feature request for it, iirc.
17:08 stephanbuys joined #salt
17:08 whiteinge utahcon: depending what data points you're matching on the match.filter_by function may work instead
17:10 timoguin johtso: I use jinja for joining paths in SLS files: {% set directory = ['dir1', variable, 'dir2']|join('/') %}
17:11 johtso timoguin: I'd rather use the more robust os.path.join though :/
17:11 johtso as far as I know you can't define custom jinja filters though right?
17:11 TheThing|laptop joined #salt
17:11 timoguin no, you can't.
17:11 forrest johtso, just use the pydsl
17:11 stanchan joined #salt
17:11 johtso but I could define a custom module?
17:11 johtso really dislike the look of pydsl :/
17:12 forrest yeah you could write a custom module for it I guess.
17:14 utahcon thanks whiteinge
17:14 * robawt highfives whiteinge
17:14 aw110f joined #salt
17:14 * whiteinge chest-bumps robawt
17:15 johtso does the supervisord state automatically watch it's own config for changes and restart?
17:15 johtso or do I need to specify that myself?
17:15 TheThing|laptop joined #salt
17:15 heewa joined #salt
17:17 whiteinge timoguin, johtso: custom jinja filters are basically custom execution modules. we added one for os.join() recently too:
17:17 whiteinge http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.file.html#salt.modules.file.join
17:18 johtso whiteinge: oh nice!!
17:18 dave_den joined #salt
17:18 timoguin ah cool
17:18 timoguin johtso: I don't think it's automatic. I have supervisord.running watching the main config and the service configs.
17:18 whiteinge it's in 2014.7 but it would be trivial to pull that in to a custom /srv/salt/_modules/myutil.py file
17:19 johtso timoguin: ah, cheers
17:19 johtso whiteinge: I'm running 2014.7 anyway :)
17:19 whiteinge ah :)
17:19 johtso too many cool things in there to wait!
17:19 whiteinge hehe
17:20 joem86 left #salt
17:25 jonasbjork joined #salt
17:27 tie joined #salt
17:33 dvestal joined #salt
17:33 eliasp weird thing… I have a minion, which shows the correct pillars via 'pillar.get' and 'pillar.items', but state.highstate still uses old pillar data… Master + Minion both running 2014.1.11 on Ubuntu 14.04 amd64 …
17:33 eliasp saltutil.refresh_pillar doesn't change anything (although it should work without it)
17:33 possibilities joined #salt
17:34 eflynn joined #salt
17:34 eliasp could this have something to do with test=True for state.highstate?
17:34 * geekatcmu wants a minion
17:34 geekatcmu Just sayin'
17:34 eliasp geekatcmu: there you go: http://i.imgur.com/WoraMIW.jpg
17:36 tmh1999 joined #salt
17:38 bivers joined #salt
17:41 geekatcmu You're all heart
17:42 ramishra joined #salt
17:42 darvon joined #salt
17:43 xmj <3
17:44 smcquay joined #salt
17:49 ajolo joined #salt
17:49 spookah joined #salt
17:51 murrdoc joined #salt
17:52 mechanicalduck_ joined #salt
17:52 do_monkey joined #salt
17:54 jsm joined #salt
17:55 funzo joined #salt
17:58 ramishra joined #salt
17:58 mechanicalduck joined #salt
18:00 johtso how do I pip install something from a git repo with the pip state?
18:00 johtso I'm getting "Invalid version specification in package git+git@github.com:foo/bar.git@develop#egg=bar. '=' is not supported, use '==' instead."
18:01 smcquay joined #salt
18:01 aparsons joined #salt
18:01 forrest are you trying to specify a version with just one equals sign?
18:02 johtso forrest: no, that's specifying the egg name
18:02 aparsons joined #salt
18:02 johtso I'm not specifying a version because I'm specifying a git ref instead
18:02 iggy I don't think that's supported
18:02 StDiluted joined #salt
18:02 meteorfox joined #salt
18:03 forrest johtso, did you try using editable?
18:03 iggy or someone else was having issues with it too
18:03 johtso the pip install module has this as an example: "salt '*' pip.install markdown,django                 editable=git+https://github.com/worldcompany/djangoembed.git#egg=djangoembed upgrade=True no_deps=True"
18:03 johtso but name is a required parameter..
18:03 forrest http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pip_state.html#salt.states.pip_state.installed, and if you search for editable it shows an example using an egg like that.
18:03 tmh1999 joined #salt
18:05 pdayton joined #salt
18:05 forrest johtso, populate the name value with the actual name, then try the editable option.
18:06 johtso looks like it might work :)
18:06 linjan_ joined #salt
18:07 dusel joined #salt
18:08 perfectsine joined #salt
18:11 kermit joined #salt
18:12 kusams joined #salt
18:13 to_json1 joined #salt
18:13 kballou joined #salt
18:14 to_json2 joined #salt
18:15 Imtnt joined #salt
18:16 beneggett joined #salt
18:16 kingel joined #salt
18:18 Ryan_Lane joined #salt
18:18 Ryan_Lane joined #salt
18:20 to_json joined #salt
18:20 oncallsucks joined #salt
18:21 kusams joined #salt
18:21 druonysus joined #salt
18:22 jalaziz joined #salt
18:22 fllr joined #salt
18:23 whytewolf joined #salt
18:24 kusams joined #salt
18:24 perfectsine joined #salt
18:25 tkharju joined #salt
18:25 stephanbuys1 joined #salt
18:26 thedodd joined #salt
18:27 wnkz joined #salt
18:29 nitti joined #salt
18:30 fllr joined #salt
18:30 A||SySt3msG0 joined #salt
18:31 fllr joined #salt
18:31 fllr left #salt
18:32 A||SySt3msG0 joined #salt
18:33 n8n joined #salt
18:34 beneggett joined #salt
18:34 debian112 joined #salt
18:35 higgs001 joined #salt
18:36 tristianc joined #salt
18:40 darvon joined #salt
18:40 TheRhino04 joined #salt
18:41 TheRhino04 Hey guys I have a quick question about pillar
18:41 TheRhino04 I am generating json as part of my cloud infrastructure
18:41 TheRhino04 I'm then using the generated json as a pillar state file
18:42 aparsons joined #salt
18:42 TheRhino04 what I was wondering: how do I generate this json as part of every pillar render
18:42 TheRhino04 It currently generates off a python function call
18:42 heewa joined #salt
18:43 TheRhino04 Any ideas?
18:43 SheetiS Using an external pillar might be good for that http://docs.saltstack.com/en/latest/topics/development/external_pillars.html
18:43 TheRhino04 I thought about that, but it seems external pillars want me to return a python dictionary
18:44 TheRhino04 while I would really like to generate the json and then read pillar from that
18:44 linjan_ joined #salt
18:44 SheetiS hmm you could do some dirty  things
18:45 SheetiS does the script output the json to a file then, or stdout?
18:45 TheRhino04 a file
18:47 SheetiS Well technically you can do this in your jinja in the pillar {% set output = salt['cmd.run']('your_command') %} to force it to run at the top of your pillar
18:47 smcquay joined #salt
18:47 nitti joined #salt
18:48 SheetiS then load your json in the pillar below it
18:49 pipps joined #salt
18:49 SheetiS look at import_json http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html to import the json into your pillar file then.
18:49 SheetiS It wouldn't be what I'd want to do long-term, but it would probably do what you want generally to combine those 2 together.
18:50 pipps_ joined #salt
18:50 SheetiS keep in mind that a cmd.run from the pillar would be run on your master since that is where pillars are generated.
18:51 TheRhino04 Which would essentially be executing the python script
18:51 TheRhino04 kind of sucks that salt cmd module needs to be run
18:52 murrdoc morning
18:52 TheRhino04 Good morning!
18:54 tempytemptemp joined #salt
18:54 SheetiS TheRhino04: If you want to run your script, and it's not an existing salt module, and you don't want to use an external pillar, I don't see another option.
18:55 SheetiS Since you always want to make sure it is up-to-date when using the pillar.
18:55 TheRhino04 Absolutely, that is the conclusion I was coming to as well
18:55 TheRhino04 my only other idea was to add a custom module essentially to do the same thing
18:55 TheRhino04 but I think that would be adding unnecessary confusion
18:56 murrdoc on the contrary
18:56 TheRhino04 since all it is really doing is executing the python script
18:56 murrdoc why you no ext_pillar ?
18:56 tempytemptemp left #salt
18:57 TheRhino04 since ext_pillar expects a python dictionary return when what I'd really like is to output my return to a json file that is then parsed into pillar using the json renderer
18:57 murrdoc which is still fine
18:58 murrdoc i d keep stuff the 'salt way' till it seems overkill
18:58 murrdoc thats how i d decide (not that u asked)
18:58 TheRhino04 haha
18:58 TheRhino04 so in salt pillar execution, does ext_pillar happen before pillar?
18:58 ramishra joined #salt
18:59 jalaziz joined #salt
18:59 iggy is it that hard to put an import json; return json.loads(out);
18:59 TheRhino04 well best ext_pillar practices dictate that you should only be rendering updates to pillar
18:59 iggy seems a lot less hackish than using cmd.run in pillars
18:59 felskrone joined #salt
19:00 beneggett joined #salt
19:00 murrdoc http://docs.saltstack.com/en/latest/topics/development/external_pillars.html
19:00 murrdoc 'How it is called depends on how it is configured in the Salt master configuration. The first argument is always the current pillar dictionary, this contains pillar items that have already been added, starting with the data from pillar_roots, and then from any already-ran external pillars.'
19:00 murrdoc so i assume it means you can pick whether its before your pillars dir
19:00 murrdoc or after
19:00 murrdoc ok standup time
19:00 murrdoc brb
19:01 mattl joined #salt
19:02 mattl built a new VM on wheezy, installed salt-minion but when i apply my highstate i'm seeing this: AttributeError: 'str' object has no attribute 'get'
19:02 mattl https://www.irccloud.com/pastebin/9GFBVLGz
19:03 iggy mattl: what version?
19:03 mattl salt-minion 2014.1.11 (Hydrogen)
19:04 Gareth mattl: can you pastebin the state you used that references pkg.installed?
19:04 mattl https://www.irccloud.com/pastebin/D79ytgnu
19:04 iggy I would file a bug either way this works out... you should generally not get tracebacks from salt
19:05 iggy mattl: it's git
19:05 iggy not git-core
19:06 mattl it's git-core on debian, IIRC.
19:06 iggy used to be
19:06 iggy although it looks like git-core should work too in 14.04
19:06 tmh1999 joined #salt
19:06 mattl aha, i'll update that. i got a whole bunch of these tracebacks though.
19:07 scoates joined #salt
19:07 iggy oh, for every package or just some?
19:07 mattl every package, yeah
19:07 mattl htop, emacs, dtrx, openssh-server (in another state), etc
19:07 iggy in the future, just pastebin all the errors you get
19:08 mattl yeah, i was trying to avoid giving away some SSH related secrets...
19:08 iggy fair enough
19:08 thedodd joined #salt
19:12 eunuchsocket babilen: & iggy: I've been thinking more about tiered promotion and top.sls does this seem like a sane approach https://www.refheap.com/91362
19:12 * babilen takes a look
19:12 eunuchsocket babilen: & iggy:  the assumption is that I'm putting everything in one repo and managing it manually (without gitfs/svnfs)
19:14 iggy I thought the only file that was read as a "top" file was top.sls, but you're treating topstate.sls like it's a top file
19:14 dvestal joined #salt
19:14 babilen I gathered as much. In that case I would rather choose /srv/salt/{dev,qa,prod} -- What is "base" for you (semantically that is) ?
19:14 giannello joined #salt
19:15 babilen That scheme would allow you to simply have {dev,qa,prod} directories directly in your repository. I also don't quite understand what you plan to use topstate for.
19:15 Ozack1 joined #salt
19:15 babilen Ah, that wouldn't work.
19:15 eunuchsocket in that configuration I wouldn't ever need to modify top.sls
19:15 linjan_ joined #salt
19:16 iggy to shorten top.sls and/or allow whoever maintains those branches to have their own top file
19:16 eunuchsocket I could cleanly keep my dev work in the dev branch an
19:16 babilen Well, but you cannot simply introduce new top files. Topstate would, in this case, be parsed as a "normal" case and you cannot target other states to your minions in there.
19:16 eunuchsocket iggy: that's the idea... keep the "top" of each branch maintained independently
19:16 eunuchsocket babilen: ahhhh, make sense
19:16 babilen *"normal" state file
19:16 iggy the problem we ran into when trying to use multiple branches like that was that we had files that would never converge, so we lost all the niceties of git (merging, etc.)
19:17 babilen +1
19:17 babilen exactly
19:17 iggy we ended up manually merging stuff all the time and at that point, you might as well have separate repos (or dirs in a single repo)
19:18 eunuchsocket darn, I thought I was on to something for a minute there
19:18 babilen iggy: Keep in mind that eunuchsocket is not planning to use git but svn for that which means that (s)he lost all niceties of git already ;)
19:18 * eunuchsocket wishes he could just use git
19:18 iggy yeah, well... I didn't want to rub it in
19:19 druonysuse joined #salt
19:19 druonysuse joined #salt
19:19 babilen eunuchsocket: I like that idea, but in the end top files will simply be merged. The main problem with having multiple top files in your dev,prod,qa branches is *not* that it does not allow you to keep the qa configuration on the qa branch, the prod configuration on the prod branch, (and so on) -- it does allow you to do that! -- but that you cannot merge changes on one branch to easily to another (as you would end up with changes to your top file ...
19:20 babilen ... that you don't want to merge)
19:21 eunuchsocket babilen: I'm having trouble imagining such a change
19:21 babilen What kind of change exactly?
19:21 iggy they happen
19:22 eunuchsocket babilen: i might merge some stuff that salt doesn't use when I promote top from dev->prod
19:23 eunuchsocket babilen: my brain keeps getting twisted around because I'm dealing with dev,qa,prod code and dev,qa,prod servers
19:23 teebes joined #salt
19:23 jalbretsen joined #salt
19:24 JoeyJoeJo joined #salt
19:24 babilen Okay, I might have to elaborate a little on how git works I guess. A git branch, quite literally, branches off from another branch. That is you end up with the *exact* same data on that branch than you have on another. Lets say that you have some states on which you want to work. First, this means that you have an identical top.sls on all branches (duplicates!), but also that you cannot make changes to the top.sls that will only be specific to that ..
19:24 murrdoc joined #salt
19:24 babilen ... branch. You cannot change top.sls to include a state on qa, merge that to prod and hope that it'll magically hop from "qa: ..." to "prod: ..."
19:25 possibilities joined #salt
19:25 JoeyJoeJo I've started reading the docs on salt and I want to make sure I'm clear on how it works. Before reading I thought that hosts didn't need any sort of agent or client running on them and that everything happened over SSH. After reading it seems like hosts need to run the Salt Minion. Is that correct?
19:25 iggy sometimes it does! ... sometimes
19:25 eunuchsocket babilen: that's all true in my svn environment too
19:25 babilen So, what you typically want it to work *on your states* on different branches and then be able to merge/cherry-pick those changes from one branch to the next. That is you change foo/bar/baz.sls and test it in dev. It works wonderfully and therefore merge that commit into qa. Your QA people give you the thumbs up and somebody finally merges it into prod.
19:25 smcquay joined #salt
19:26 kusams joined #salt
19:26 babilen JoeyJoeJo: You can use salt ssh, but having a master allows you to do a bunch of things that you cannot do with salt-ssh alone (e.g. reactors)
19:26 iggy JoeyJoeJo: salt-ssh is a newish, limited way of doing some of what salt can do on hosts
19:27 babilen eunuchsocket: yeah, I just wanted to elaborate on the reason why you have to keep your top file in a different repo.
19:27 to_json joined #salt
19:27 iggy ianad but I generally discourage people using salt-ssh unless they have good reason to
19:27 eunuchsocket babilen: thanks for talking it through with me.  looks like I'm going back to plan A
19:27 JoeyJoeJo What if you have a device that can't run salt minion (ie cisco devices)
19:28 JoeyJoeJo Is that what salt-ssh is for?
19:28 babilen JoeyJoeJo: It should also be pointed out that salt ssh is quite new and that you will definitely not have the the "full" salt experience without a master. That doesn't have to be a problem though. It might be perfectly fine and okay for what you want to do.
19:28 eunuchsocket JoeyJoeJo: check out salt proxy minions
19:28 Ahrotahntee if I want to put key-value pairs in top.sls (pillar) what is the syntax? I can get it to 'compile' but it doesn't store the data I'm expecting.
19:28 babilen JoeyJoeJo: No, you'd use proxy minions for that: http://docs.saltstack.com/en/latest/topics/topology/proxyminion/index.html
19:29 Ahrotahntee damn it it looks like I "can't" do that
19:29 iggy Ahrotahntee: you don't... top files are different than sls files
19:29 babilen Ahrotahntee: You don't put it directly in your top.sls, but it pillar files targeted in your top.sls.
19:29 iggy the same way you wouldn't put pkg.installed in your state top file
19:29 babilen Ahrotahntee: Could you paste what you have to http://refheap.com so that we might be able to show you how you would rather do it? The top.sls simply decides which minion gets which data.
19:29 Ahrotahntee that pretty much results in one pillar for each host
19:30 Ahrotahntee where some hosts may share (some) of the same data
19:30 iggy that's where things like ext_pillar come into play
19:30 Ahrotahntee for example a role attribute that describes what the server is used for; something I may want to edit in bulk, but not something I'd want to fork off into 5+ different files
19:30 babilen Ahrotahntee: Why don't you keep data in dictionaries and look it up based on minion id? (or some other datum)
19:30 * Ahrotahntee looks closer at ext_pillar
19:30 babilen Ahrotahntee: I would suggest to show us what you want to do and we can then think about to achieve that best.
19:31 iggy ^
19:31 babilen You don't need an ext_pillar for that. You can define dictionaries in jinja or write your pillar in pure Python (if appropriate)
19:32 Ahrotahntee I'm looking to add a 'roles' pillar to each server, allowing me to select by role; for example: salt -I 'role:web:load-balancer'
19:32 babilen An ext_pillar might still be a good solution, but it really depends on what you want to do exactly.
19:32 jsm joined #salt
19:32 babilen Okay, why can't you define a dictionary in which the minion ids are the keys and a list of roles is the value?
19:33 babilen Ah, targeting by that might be slightly trickier ...
19:33 babilen You actually want to have multiple roles per minion, don't you?
19:33 Ahrotahntee minions can have 'n' roles
19:33 Ahrotahntee literally 0 or more
19:34 babilen So you would actually want to say something like "'load-balancer' in salt['pillar.get']('role:web', [])"
19:34 Ahrotahntee since I am breaking them down by service: web:load-balancer db:node
19:34 iggy Ahrotahntee: we use instance tags for that
19:34 murrdoc salt['pillar.get']('webscale') == 'mongo'
19:34 murrdoc NOPE
19:35 beneggett joined #salt
19:35 iggy then we have a grain that reads instance tags
19:35 babilen yeah, mongo is never a good idea ;)
19:35 Ahrotahntee remember I'm new; so it is possible that I'm just going about this back asswards
19:36 mapu joined #salt
19:37 babilen There are multiple approaches, but I guess iggy can elaborate on one approach and we can then discuss that one. Another would involve writing top.sls dynamically in such a way that you would, essentially, have conditions like the one I showed above in there and then list/include the appropriate states.
19:37 babilen You will *not* get alt -I 'role:web:load-balancer' if you want "role:web" to have multiple values.
19:38 murrdoc you could also put the grains for role
19:38 murrdoc into the /etc/salt/grains file
19:38 murrdoc so when u 'make' a server, you can place those values there
19:38 babilen I don't like grains for roles, but I'm in a minority there (how do you manage those grains?)
19:38 murrdoc shut down ssh!
19:39 murrdoc you are correct tho, grains for roles are dangerous no doubt
19:39 babilen I just don't like it. I simply don't want to have to login to minions (and depend on *local* state) to assign them a state.
19:39 mapu joined #salt
19:40 murrdoc do you use an external source
19:40 murrdoc to define the 'role' of a server
19:40 Ahrotahntee I need to step away for a few minutes
19:40 Ahrotahntee this is clearly a more complicated/interesting talking point than I had intended
19:40 babilen The alternative is to manage those grains based on *something else* and you can, IMHO, just target your states based on that to begin with. A bunch of cloud hosters allow you to "tag" your instances and I think that's a more appropriate approach.
19:40 kingel joined #salt
19:40 Ahrotahntee and I'm full of coffee and resentment
19:40 Ahrotahntee (not towards you guys, just in general)
19:41 babilen iggy: How do you guys get the "tags" on the boxes?
19:42 smcquay_ joined #salt
19:42 iggy we used to push roles into grains on deployment, but now we just read the tags directly... makes it easier for some of the less command line inclined people to just login to the Google Console and set tags there
19:42 iggy babilen: our deployment system puts some
19:43 iggy and then like I said, some people just put them on manually
19:44 babilen Ahrotahntee: It is really quite hard to suggest something suitable without knowing your setup. The most common approach (and the easiest) is to target states to minions based on minion id and values defined in grains. This assumes that you have some suitable naming scheme for your minions that you can exploit here in some way. So you would have foo-lb1, foo-web1, ... for load balancer and webserver.
19:44 Ahrotahntee babilen: the servers are named for the physical locations (and not their roles)
19:44 Ahrotahntee so no leverage there at this time
19:44 babilen This, obviously, isn't always the right way to go about things as you don't necessarily have such a naming scheme to exploit so you have to base your decision on some other data.
19:45 babilen The question now is how to target those data to the minions.
19:46 babilen Again the easiest approach is to simply define grains *on the minion* and then target states based on grains. This works, but is IMHO idiotic as you have to login to the boxes to set those grains which renders the whole configuration management system you want to use pointless.
19:46 murrdoc joined #salt
19:46 iggy yeah, if you can't use names or some sort of outside metadata... think you're stuck with a targeting mess in your top.sls or manually settings grains
19:46 iggy or!
19:47 murrdoc compound matching ?
19:47 murrdoc '*' : base stuff
19:47 babilen So, you need some other way. And this way *really* depends on how you create those instances and if you can automate associating a role with a box in some way during its creation or in an *automated* way.
19:47 murrdoc '@G:role:mom': learntocook;call_a_lot;
19:47 iggy ext_pillar if you have some other system that keeps track of things (presumably all these systems haven't been manually installed and setup till this point)
19:47 murrdoc '@G:role:dad': atmftw;
19:48 iggy but how do you tell dad that he's dad?
19:48 tcotav generally over whiskey
19:48 Ahrotahntee cigars
19:48 murrdoc totally serious btw
19:48 babilen So, if you want to be able to have "one click" provisioning of new database servers it might be perfectly fine to give those new db server minions a random hostname *but* write information about their "database" role into a PostgreSQL data which you use as external pillar. You could then dynamically generate the top.sls (and assign states) from those pillar data in your management database.
19:48 tcotav at some point -- you have to map this stuff
19:49 murrdoc you can use compound matching in top.sls
19:49 iggy yeah, but now we're at the point of how do you get those roles set on everything
19:50 babilen exactly
19:50 iggy and unfortunately we don't have enough information to make very informed suggestions here
19:50 babilen It simply isn't that easy and I just wanted to say that "read data from grains/pillars" doesn't solve anything as you would have to get *those* to the minions in some way to begin with.
19:50 iggy so we're all just shotgunning everything we know and hoping to hit something
19:50 tcotav hehe this is true
19:51 babilen So, Ahrotahntee, it's story time now. Tell us what you want to do.
19:51 babilen (and what you work with/can develop)
19:51 Ahrotahntee babilen: I am looking to set each minion with a set of roles
19:51 Ahrotahntee these roles will determine what states are pushed
19:51 Ahrotahntee (currently matching via pillar)
19:52 Ahrotahntee for example: 'role:web:load-balancer':
19:52 Ahrotahntee - nginx.load-balancer
19:52 Ahrotahntee configs are all bulletproof, cloud provider does not support "tagging"
19:52 Ahrotahntee thinking I am going to just bite the bullet and keep a <server>.roles pillar
19:53 iggy how do the systems get deployed?
19:53 Ahrotahntee they're provisioned from a base image
19:53 dvestal joined #salt
19:53 Ahrotahntee and then configurations and services are pushed to them for the brief moment that they're accepting connections remotely
19:53 iggy and you have no way of injecting anything during that process?
19:54 tcotav are all hosts identical then since they don't have roles assigned?
19:54 Ahrotahntee the base image is fairly stock, I can get the salt minion in there but that's about it
19:54 Ahrotahntee all hosts are identical before roles are assigned
19:54 babilen What makes one of your minions a "load balancer" and how can you/do you want to manage those associations?
19:54 tcotav so databases don't have a boatload of RAM and fast disk or anything?
19:55 tcotav or are size: large VMs
19:55 Ahrotahntee tcotav: since they're virtual environments the resources available to each minion can but does not necessarily vary
19:55 Ahrotahntee I can specify some system-level resource requirements (HDD space, CPUs, RAM)
19:55 teebes joined #salt
19:56 iggy how do you currently say "hostname 091824nfo8u1243nf is a database server"?
19:56 perfectsine joined #salt
19:56 babilen (and how do you want to do that in the future?)
19:56 * Ahrotahntee holds up a whiteboard marker
19:57 Ahrotahntee ideally I would like to do it via salt
19:57 babilen Well, you can. Just target a database state to the minion with the 091824nfo8u1243nf id.
19:57 iggy it sounds like you're going to be stuck maintaining a map of hosts to roles/states/etc...
19:58 tcotav ^
19:58 iggy whether that's best done in salt is still a little unclear
19:58 Ahrotahntee hosts to roles is OK
19:58 Ahrotahntee I'm even OK with doing it in a pillar
19:58 Ahrotahntee the original question was if I can get the key-value pairs in the pillar top.sls file
19:58 Ahrotahntee which no, I cannot
19:58 iggy but don't get stuck with "everything needs to be done with salt"
19:58 babilen So you do want a manually managed map in which you assign roles/states groups to minions?
19:59 Ahrotahntee I would be perfectly OK with that
19:59 babilen Ahrotahntee: You can not target by foo:bar:baz if the value of foo:bar is a list.
19:59 babilen (and baz is just an element)
19:59 ramishra joined #salt
19:59 eflynn left #salt
20:00 Ahrotahntee I was (in my test jig) targetting 'role:web:load-balancer' where web is a key and load-balancer is the value
20:01 iggy we have systems with multiples tags and we match items in that list
20:01 Ahrotahntee brb a minute again
20:01 iggy 'G@tags:brkr': - match: compound
20:02 iggy we don't have any instances with only one tag, so I know that's working as we expect
20:02 iggy or are you describing something else?
20:03 babilen Ahrotahntee: https://www.refheap.com/91365 -- write a pillar that returns the correct list by minion id somehow and implement states for each "role".
20:03 babilen (that is not tested in any way)
20:04 iggy {% if 'roles' in salt['pillar'] %} ?
20:05 babilen Ahrotahntee: As I said: Targeting "role:load-balancer' does *not* work if the value of "role" is a list. Alternatively you could also use the aforementioned '{% if 'load-balancer' in salt['pillar.get']('role:web', []) %}' in there or even write your top.sls in Python.
20:05 babilen iggy: yeah
20:05 babilen absolutely, damn :)
20:05 jalaziz joined #salt
20:06 iggy and ) on the line after, but I figured that would throw a parse error, not just silently not work
20:06 iggy but I don't think you really need the if
20:07 iggy the for loop won't do anything if there are no roles as it'll loop over the empty list
20:08 beneggett joined #salt
20:09 babilen I never tested that, just wanted to formulate my idea :)
20:11 gmcwhistler joined #salt
20:12 murrdoc joined #salt
20:13 cpowell joined #salt
20:13 cpowell joined #salt
20:14 CryptoMer joined #salt
20:15 TheRhino04 joined #salt
20:16 TheRhino04 joined #salt
20:16 kingel joined #salt
20:18 higgs001 joined #salt
20:20 TheRhino04 joined #salt
20:22 elfixit joined #salt
20:24 dvestal joined #salt
20:24 to_json joined #salt
20:24 saltnoob joined #salt
20:25 wramthun joined #salt
20:26 __TheDodd__ joined #salt
20:27 jalaziz joined #salt
20:27 saltnoob Hi Guys, just wondering when structuring states and storing passwords in pillars, is there a way to encrypt / hash them?
20:28 teebes joined #salt
20:28 murrdoc the serious way to do it is . http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html
20:28 babilen ^
20:28 babilen (not yet supported)_
20:29 babilen But will be soon with .7
20:29 murrdoc or http://docs.saltstack.com/en/latest/topics/sdb/
20:30 saltnoob saw that, any other methods in the meantime before the next release?
20:31 saltnoob interesting, anxiously waiting for next release
20:31 murrdoc implement that using cmd.run
20:31 giannello joined #salt
20:31 saltnoob in a statefile on a minion?
20:32 murrdoc yeah
20:32 murrdoc basically generate the gpg encrupted data and put it on the master
20:32 murrdoc also the key
20:32 smcquay joined #salt
20:32 SheetiS you could also steal the gpg renderer from 2014.7 and place it as a module in _renderers of your current instance.
20:33 murrdoc yeah
20:33 pssblts joined #salt
20:33 murrdoc thats easiest
20:33 murrdoc https://github.com/saltstack/salt/blob/develop/salt/renderers/gpg.py
20:33 saltnoob interesting, I'm going to try that, thanks murrdoc
20:34 SheetiS http://docs.saltstack.com/en/latest/ref/renderers/#writing-renderers has more details about where things go if you need to look further.
20:35 SheetiS the gpg renderer didn't look to be doing anything too crazy, so I think it should run cleanly on 2014.1
20:36 murrdoc uses python gnupg to decrypt/encrypt
20:37 SheetiS Yeah, but I saw no 'gotchas' going from 2014.7 -> 2014.1 with the module itself.
20:38 saltnoob awesome
20:38 murrdoc yeah pip install gnupg at most
20:38 saltnoob thanks for the help
20:39 pipps joined #salt
20:39 giannello left #salt
20:39 to_json joined #salt
20:40 cromark joined #salt
20:40 to_json joined #salt
20:40 smcquay_ joined #salt
20:41 Ahrotahntee joined #salt
20:41 Ahrotahntee joined #salt
20:42 johnthedebs joined #salt
20:43 schimmy joined #salt
20:43 johnthedebs left #salt
20:45 schimmy1 joined #salt
20:46 dalexander joined #salt
20:47 debian112 iggy: I figured it out about the custom program yesterday. I use cmd.wait with watch works prefectly
20:47 debian112 iggy: thanks for the pointers
20:48 novice joined #salt
20:48 jalaziz joined #salt
20:49 roolo joined #salt
20:49 TheThing|laptop joined #salt
20:50 MasterJ joined #salt
20:50 n8n joined #salt
20:51 debian112 Is there anyway to exclude a node group, when I run this:  salt '*' state.sls nrpe --batch-size=25%
20:52 n8n_ joined #salt
20:53 iggy salt -C '* and not G@kernel:Darwin' test.ping
20:53 iggy or something similar
20:53 debian112 ok cool
20:53 debian112 thanks
20:54 iggy and not L@minion1,min3,min9
20:54 iggy etc
20:54 iggy compound matchers are (dangerously) powerful
20:56 murrdoc well you could just make a node group
20:56 murrdoc safer way to do compounds
20:56 murrdoc http://docs.saltstack.com/en/latest/topics/targeting/nodegroups.html ftw
20:56 TheRhino04 joined #salt
20:57 DaveQB joined #salt
20:58 eliasp I have a SLS where I have a general "include" in the first line and then a conditional "include" in a Jinja {% if … %} block … this produces an invalid SLS/YAML, as there are now 2 "include" keys… is there a way to write an include differently to use another primary key for an include statement?
20:58 manfred no
20:59 manfred you could wrap part of your first include in jinja
20:59 manfred include:
20:59 manfred - something
20:59 Ryan_Lane https://github.com/saltstack/salt/issues/14899
20:59 manfred {% if thing %}
20:59 manfred - otherthing
20:59 Ryan_Lane eliasp: ^^
20:59 manfred {% endif %}
20:59 eliasp well… to be exact… the 2nd include is not only {% if %} conditional, but also part of a bit more complex loop over pillars…
21:00 manfred yeah can't do that unfortunately, check ryans feature request
21:00 eliasp so I'd have to create a variable to which I append all includes and "include" all the results at the end?
21:00 eliasp Ryan_Lane: thanks!
21:00 Ryan_Lane yw
21:00 eliasp manfred: thanks too
21:00 eliasp ;)
21:00 ramishra joined #salt
21:00 skyler joined #salt
21:00 Daemonik joined #salt
21:00 tristianc joined #salt
21:00 Daemonik How may I set a host's hostname to match its minion_id?
21:01 skyler So in a lot of map.jinja files I see something like " }, merge=salt['pillar.get']('mongodb:lookup')) %}"
21:01 Daemonik Also,  salt $host system.hostname web01.example.net    is valid?
21:01 skyler Where does lookup come from? I dont see it in the example pillars.
21:05 eliasp skyler: I'm not 100% sure, but I think foo:lookup is a "virtual" pillar which is provided within the scope of salt['grains.filter_by']()
21:07 eliasp http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.grains.html#salt.modules.grains.filter_by
21:07 eliasp s/pillar/grain/g
21:08 eliasp corrections/better explanations welcome… I think forrest might be the one who could provide more info here
21:09 manfred skyler: that would be something that would be specified in side the pillar file
21:09 pipps joined #salt
21:09 manfred mongodb:
21:09 manfred lookup:
21:10 murrdoc yeah its a structure sorta decided on in the stack formulas
21:10 iggy and yeah, most of the pillar examples seem to get it wrong
21:10 manfred forrest: what is the :lookup, cause it actually isn't in the pillar.example either… https://github.com/saltstack-formulas/mongodb-formula/blob/master/mongodb/map.jinja#L14
21:10 murrdoc :) pull request!
21:11 iggy ugh, my salt todo list is long enough
21:11 manfred skyler:  https://github.com/saltstack-formulas/mongodb-formula/pull/8
21:12 perfectsine joined #salt
21:13 pipps_ joined #salt
21:13 jonasbjork joined #salt
21:14 manfred skyler:  they mention the :lookup variable here in the besst_practices http://docs.saltstack.com/en/latest/topics/best_practices.html
21:14 manfred it just allows you to override the defaults in map.jinja using your pillars
21:15 TheThing_ joined #salt
21:15 eliasp aah, ok
21:15 forrest sorry was grabbing lunch, manfred I don't know why that one doesn't have a lookup, either way it should just be adding a 'lookup' section to the pillar
21:15 manfred nevermind, figured it out <3
21:15 forrest manfred, alright
21:15 manfred yeah, it was used so you could override stuff in the maps.jinja file
21:16 forrest right
21:16 forrest someone just didn't put in a lookup section inside the pillar it seems
21:16 forrest so it's understandably confusing
21:17 timoguin I explained lookup to someone earlier today too. (things to moar document)
21:17 forrest Yeah, I can't remember if I talk about how that works in the talk I did.
21:17 bhosmer_ joined #salt
21:18 iggy a lot of people don't put lookup in the pillar example
21:19 iggy maybe not a lot... but I've certainly seen it more than once
21:19 forrest iggy, Hmm, I wonder if people are doing that because it isn't a value you would overwrite?
21:20 forrest either way, should still be in there even with a fake value
21:20 forrest so people aren't confused.
21:20 skyler Thanks for all the responses. So lookup should be in the example pillar and is NOT magic? correct?
21:20 murrdoc lookup: {}
21:20 iggy correct
21:20 babilen :lookup should be used to override values in the, well, looup table in maps.jinja and shouldn't be (ab)used for settings a user would genruinely want to set on a more regular basis
21:21 iggy that should be in the documentation then
21:21 forrest skyler, no it's not magic, just imagine it like this, the lookup in the map file, and the lookup (when it exists) in the pillar are like a zipper, the map file and pillar are 'merged' together (like the teeth closing), but the pillar always has precedence, so if there is a conflict between the tooth from the map, and the tooth from the pillar, the pillar will always win to ensure things keep zipping up properly.
21:21 iggy because it's use is very inconsistent
21:21 babilen iggy: I agree .. I should finish writing that.
21:21 murrdoc i vote for u finishing that too :)
21:21 babilen heh
21:21 murrdoc once u get the doc
21:22 murrdoc i ll even offer to send u 5 pull requests
21:22 murrdoc :D
21:22 murrdoc updating formulas that dont match
21:22 murrdoc and i sign up iggy for 10
21:22 murrdoc just cos
21:22 skyler Thanks forrest: So lookup is a section in pillars that holds things that are say grain specific. Not something the user would like to change, but something that would change often based on the system you are deploying to.
21:23 forrest skyler, the lookup section itself from the map is for OS specific items. You COULD put other stuff under the lookup, it depends on what you want to do depending on your setup.
21:23 perfectsine joined #salt
21:24 forrest skyler, does that make sense?
21:24 skyler forrest, if I just had a parameter that would never change based on the map, then there is no reason to put it in the lookup section, right?
21:24 martoss joined #salt
21:24 forrest skyler, exactly
21:24 forrest skyler, If you wanted to, sure you could, but it doesn't REALLY make sense.
21:24 forrest since it's a 'lookup' of data
21:25 forrest there's a lot of differing opinions as to whether that's just for OS specific stuff, or grain based data. So that one is up to you :)
21:25 forrest for lookup that is
21:25 iggy the docs should be fixed so there aren't differing opinions
21:26 skyler Alright, awesome! I finally get that section now.
21:26 forrest iggy, I don't know if it's documented somewhere, but I agree
21:26 iggy in best_practices
21:26 forrest iggy, I think even in that talk I did, I might have just said OS specific items
21:26 forrest but that was when formulas were still quite new
21:28 iggy skyler: which formulat were you looking at?
21:28 skyler iggy: I was looking at https://github.com/saltstack-formulas/mongodb-formula
21:29 skyler but I was not actually using it, just looking to style my own states better.
21:29 micah_chatt joined #salt
21:30 possibilities joined #salt
21:30 dccc joined #salt
21:30 skyler Speaking of style, what is the perferred method nested dictionary lookups? should I do foo.get('bar',{}).get('baz','default') or should I set bar = foo.get('bar',{}) and then do bar.get('baz'.'default')?
21:30 iggy okay, that one actually looks fine because it's not using mongodb incorrectly
21:31 iggy I generally do .get().get() if it isn't going to make the line super long
21:31 iggy but I'm sure some python purist somewhere is killing puppies every time I do
21:32 skyler Do you do that even if you the first .get() a few times?
21:32 iggy do whatever looks/works best for you
21:32 pssblts joined #salt
21:32 skyler iggy: okey dokey :)
21:33 iggy in that case, no, I will usually try to avoid the extra lookups
21:34 iggy probably unnecessary, but my brain can't handle not micro-optimizing everything
21:34 rap424 joined #salt
21:36 martoss left #salt
21:37 quickdry21 joined #salt
21:37 joehoyle joined #salt
21:38 micah_chatt_ joined #salt
21:39 novice joined #salt
21:41 kermit joined #salt
21:42 jalaziz joined #salt
21:42 jblack joined #salt
21:42 jblack Hello, I'm new to salt and getting an error for a state that I don't understand.
21:42 sacha joined #salt
21:43 jblack salt -v 'harabbit*' state.highstate with the listed sls file returns the following errors: http://pastebin.com/ZEhKDtZe
21:44 eliasp jblack: why the  ¦ in front of the pkgs list items?
21:44 jblack sorry, those aren't really there. that's a plugin for vim that shows indentation
21:44 eliasp ah, ok
21:46 eliasp jblack: looks like your indentation is off in your "deps" state
21:46 eliasp "- pkgs:" should be one level deeper
21:46 eliasp and all items in the "pkgs" list should be one deeper than "pkgs" itself
21:46 iggy in general...
21:46 iggy indentation is very important in yaml
21:47 eliasp jblack: you can always use something like http://yamllint.com/ or http://yamltojson.com/ to validate your YAML
21:47 eliasp jblack: or use something like syntastic in vim
21:47 jblack I am using syntastic.
21:48 jblack I didn't actually edit this file (it should be off in production by other people), and autoindent might be playing odd games on me
21:48 sacha Howdy all
21:48 jblack no, apparently that is the actual indentation.
21:49 sacha I am having troubles starting postgres using salt on freebsd
21:49 eliasp jblack: it should look like this: http://pastebin.com/ZgDC297q
21:49 sacha sudo salt-call cmd.run '/usr/local/etc/rc.d/postgresql start'            [INFO    ] Executing command '/sbin/zfs help || :' in directory '/root' [INFO    ] Executing command '/sbin/zfs help || :' in directory '/root' [INFO    ] Executing command '/usr/local/etc/rc.d/postgresql start' in directory '/root'
21:50 sacha and it just hangs there
21:50 sacha starting postgres manually works find
21:50 sacha using salt to stop postgres once it's running also works
21:50 sacha Any ideas?
21:50 peters-tx joined #salt
21:50 iggy salt-call service.running postgresql
21:51 sacha That does not work either
21:51 heewa joined #salt
21:51 sacha I tried the other to see if running the command directly would work
21:51 jonasbjork joined #salt
21:51 iggy that's a state, should be service.start
21:52 jblack lsof and curl should be in the same column, correct?
21:52 iggy jblack: all of the pkgs should be
21:53 iggy sacha: you might try opening an issue, I've not heard of many people using salt on fbsd in here, but the devs will certainly want to take a look
21:54 sacha iggy: thanks I will do that
21:54 cromark joined #salt
21:54 eliasp sacha: does it work when using "salt your-bsd-minion cmd.run 'fooo/postgresql start/stop'"?
21:54 cromark joined #salt
21:56 thedodd joined #salt
21:56 sacha iggy: I am running a masterless minion (Vagrant box provisioned via salt)
21:58 TheThing|laptop joined #salt
22:00 iggy I'm guessing you meant that for eliasp
22:00 joehoyle left #salt
22:00 heewa joined #salt
22:00 nitti joined #salt
22:00 skyler joined #salt
22:01 eliasp sacha: ah, sorry… no idea then
22:02 aparsons joined #salt
22:03 bhi_ joined #salt
22:07 smcquay joined #salt
22:08 teepark joined #salt
22:08 smcquay joined #salt
22:08 druonysus joined #salt
22:08 druonysus joined #salt
22:11 teepark is there any way to make use of the gitfs backend from a masterless setup? it appears to only be accessible via a master
22:11 micah_chatt joined #salt
22:11 possibilities joined #salt
22:12 __number5__ teepark: nope
22:12 teepark use-case is that I'm setting up a vagrant-based development environment, but lots of my states are just in forks of github.com/saltstack-formulas repos
22:13 __number5__ you can use a state to manage the git checkout though
22:13 aparsons joined #salt
22:14 teepark __number5__: I think I'd rather just put a salt master on my dev vm, and not have that much extra setup for every formula I fork
22:14 micah_chatt_ joined #salt
22:17 smcquay joined #salt
22:18 skyler When writing a formula, would you rather have the configuration file explicitly set all default values if they are not provided, or omit that line in the config file entirely and fall back to application defaults?
22:20 cads joined #salt
22:20 mosen joined #salt
22:23 __number5__ teepark: that make sense. I'm avoiding gitfs because of it's mandatory branches-environments mappings, I prefer to have different envs in same checkout other than different branches
22:24 smcquay joined #salt
22:25 teepark __number5__: ooh, wonder if I'm going to bump my head against that. so far I'm able to customize everything the way i want with pillar environments
22:27 aparsons_ joined #salt
22:32 babilen skyler: formula defaults should follow/be the same as application defaults
22:33 TyrfingMjolnir joined #salt
22:34 Singularo joined #salt
22:37 smcquay joined #salt
22:39 iggy is that upstream defaults or distro defaults?
22:39 teepark http://docs.saltstack.com/en/latest/topics/targeting/grains.html gives an example of selecting on a custom "node_type" grain which seems to have a single string value, but what about something more like "roles" that might point to a list of strings?
22:40 teepark what would be the 'node_type:web' selector equivalent for saying "where 'web' in roles"?
22:40 iggy someone was claiming that didn't work, but it works for me
22:40 iggy 'G@tags:salt and G@tags:master':\n    - match: compound
22:41 iggy I have that in my state top file and it works
22:41 tedski 2014.1.11 was released, but docs don't exist? http://salt.readthedocs.org/en/v2014.1.11/ref/states/all/index.html
22:42 iggy tedski: readthedocs is deprecated
22:42 tedski oh
22:43 iggy unfortunately the replacements on docs.saltstack.com aren't up yet
22:43 tedski oh
22:43 iggy stick with the old docs for now
22:43 tedski so, then, there is no documentation at all for current release?
22:44 jcockhren tedski: http://docs.saltstack.com/en/latest/topics/releases/2014.1.11.html
22:44 tedski or previous release
22:44 iggy it shouldn't have changed appreciably from the older 2014.1.x releases
22:44 tedski shouldn't being key word :)
22:45 iggy well... you're short on options
22:45 jblack my problem was that python-apt is not installed on the system.
22:45 tedski iggy: so, where would you find docs for any version other than latest develop?
22:45 iggy read the old docs or nothing
22:45 jblack on the new minions, no python apt, so packages was breaking
22:46 iggy http://salt.readthedocs.org/en/v2014.1.4/
22:46 pssblts joined #salt
22:46 skyler joined #salt
22:47 Corey joined #salt
22:47 jcockhren tedski: on the link I just posted, look to the right under "Previous Topic". You can traverse through the release notes for all previous versions
22:48 jcockhren tedski: this also works -> http://docs.saltstack.com/en/latest/topics/releases/index.html
22:48 tedski jcockhren: yeah, those are release notes, not documentation :)  appreciate that, though
22:48 jcockhren ah. you mean _versions_ of the docs. heh. may bad
22:48 tedski yah
22:53 aquinas_ joined #salt
22:53 TheRhino04 joined #salt
22:54 UtahDave joined #salt
22:57 kusams joined #salt
22:58 woop joined #salt
22:58 woop is there support for installing a gemset based on a gemfile?
23:01 StDiluted joined #salt
23:02 ramishra joined #salt
23:04 __number5__ woop: there is a rvm state if that's what you looking for https://salt.readthedocs.org/en/latest/ref/states/all/salt.states.rvm.html?highlight=rvm#salt.states.rvm.gemset_present
23:06 woop but there's nothing that actually reads Gemfile or Gemfile.lock to install a gemset?
23:07 __number5__ woop, that's bundler, AFAIK no state for bundler
23:08 woop mmk
23:13 jonasbjork joined #salt
23:16 philipforget joined #salt
23:16 philipforget Hey guys, I've got a new one here: unicode key does not match against pillar dictionary keys because they are non-unicode strings. Anyone have a workaround / is this a documented thing?
23:18 philipforget basically, I'm pulling pillar data and using that as a key to access a dict from the pillar as well
23:19 forrest philipforget, unfortunately unicode stuff is problematic, there are some open issues for it, though I don't know if those will be relevant at all.
23:19 __number5__ philipforget: are you using python3? or use non-ascii characters as keys?
23:20 forrest __number5__, salt doesn't work with python3 yet
23:20 philipforget __number5__ no, it's just an ascii key
23:20 philipforget and no, this is python 2.7, installed minion and master from PPA
23:21 philipforget the gist of it is that I have a {% set some_var = grains['some_var'] %}
23:21 __number5__ philipforget: can you paste the errors/part of you pillar somewhere?
23:22 philipforget then I use {{ pillar[some_var]['some_other_key'] }}
23:22 philipforget in my pillar yaml, some_var is a regular ascii string (in this case 'tokyo')
23:23 philipforget but the initial `set` is setting the var as a unicode string, and u'tokyo' and 'tokyo' are not the same thing from a key equality standpoint
23:23 iggy try pillar.get(some_var)['key']
23:23 philipforget The error is, as expected, Unable to manage file: Jinja variable 'dict object' has no attribute u'toyko';
23:24 philipforget but hard coding 'tokyo' into the templated file works, so I know it's because of the unicode string vs string as a key
23:25 philipforget I tried a few combinations of that, and also passing it to |string on the `set`, but that still returns a unicode string
23:25 philipforget I want to correct myself above, I'm getting the key from grains, and then using that as a key against a pillar dict, not that it really matters I imagine
23:28 iggy salt['grains.get']('some_var') to set it?
23:28 joehoyle joined #salt
23:29 philipforget iggy: no dice, same thing with salt['grains.get'](...) vs grains.get(...)
23:29 iggy I know I've done something like that before
23:29 skyler If I have a file that I want to change manage most options in, but has a few that I do not want to change, what is the best approach?
23:30 skyler For example, I want to manage a configuration file, but it generates a random secret when I install the program and I do not wish to change the secret.
23:30 aquinas joined #salt
23:30 aquinas_ joined #salt
23:30 iggy blocks?
23:30 UForgotten joined #salt
23:30 iggy nah, that wouldn't work
23:31 joehoyle left #salt
23:31 UForgotten joined #salt
23:31 skyler So far my best solution is a LOT of file.sed states
23:31 quickdry21 joined #salt
23:32 murrdoc eugh
23:32 murrdoc can u not use a .d directory ?
23:32 iggy you could use some strings in the file as start/stop markers for block replace
23:32 iggy but that's pretty hackish
23:32 murrdoc http://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.blockreplace
23:33 murrdoc mark start stop areas
23:33 kingel joined #salt
23:33 murrdoc and manage those
23:33 iggy but they want the generated key, so a template conf file is a no go
23:33 skyler murrdoc: I don't think there is a .d directory, unfortunately (it is bugzilla localconfig file).
23:34 skyler So yeah, if I did block replace, I need a way to mark out the block ahead of time...
23:35 iggy I'd just template the whole thing and generate your own code
23:36 skyler iggy: thanks, that would be cleanest. I guess we can just generate a string and put it in our pillars each time. The only thing that concerns me is that I will have to provide a default, and if it doesn't get overridden then, that would be  serious security concern. I guess I just have to count on people to override it...
23:37 iggy don't put a default
23:38 murrdoc u still using bug zilla
23:38 murrdoc props
23:38 iggy if they don't put a value in, it fails, they have to go from there
23:41 skyler iggy: Yeah, that should work. Thanks.
23:42 skyler murrdoc: Yep still got bugzilla! You using redmine or something like that?
23:43 iggy github!
23:43 murrdoc jira man
23:43 murrdoc jira
23:43 * murrdoc shrugs
23:44 SheetiS joined #salt
23:46 pipps joined #salt
23:52 woop left #salt

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