| Time |
Nick |
Message |
| 00:01 |
|
jacksontj joined #salt |
| 00:04 |
|
ronc joined #salt |
| 00:04 |
|
mannyt_ joined #salt |
| 00:06 |
lacrymology |
hm |
| 00:08 |
|
krissaxton joined #salt |
| 00:08 |
lacrymology |
I changed some code in a module, and pushed it to the right gitfs, and ran sync_all and even refresh_modules, but the loaded code isn't changing |
| 00:09 |
|
cro joined #salt |
| 00:13 |
|
pipps joined #salt |
| 00:19 |
|
jbunting joined #salt |
| 00:22 |
|
woebtz joined #salt |
| 00:26 |
|
GoKage joined #salt |
| 00:26 |
|
jbunting joined #salt |
| 00:29 |
|
Gwayne joined #salt |
| 00:29 |
|
Gwayne joined #salt |
| 00:33 |
|
[diecast] joined #salt |
| 00:53 |
|
jacksontj joined #salt |
| 00:54 |
|
Ryan_Lane joined #salt |
| 00:56 |
|
Ryan_Lane1 joined #salt |
| 01:00 |
|
oz_akan_ joined #salt |
| 01:03 |
|
Ryan_Lane joined #salt |
| 01:07 |
|
Tekni joined #salt |
| 01:08 |
|
krissaxton joined #salt |
| 01:12 |
|
mohae joined #salt |
| 01:15 |
|
sibsibsib_ joined #salt |
| 01:29 |
|
[diecast] joined #salt |
| 01:31 |
|
ml_1 joined #salt |
| 01:35 |
|
[diecast] joined #salt |
| 01:36 |
|
avienu joined #salt |
| 01:37 |
|
[diecast] joined #salt |
| 01:51 |
|
[diecast] joined #salt |
| 02:02 |
|
ipmb joined #salt |
| 02:05 |
|
sixninetynine joined #salt |
| 02:09 |
|
krissaxton joined #salt |
| 02:09 |
|
gatoralli joined #salt |
| 02:11 |
|
dcolish joined #salt |
| 02:14 |
|
emocakes joined #salt |
| 02:25 |
andrej |
And more questions about user management ... how would one go about getting e.g. a "group" of users to be present on some machines, but not others? Or, let's say I have a list of 20 people to maintain, 15 of which need to be present on ALL my minions, and 5 only on a few ... do I make a states file specific to each minion, and include e.g. one file that holds the 15 obligatory people, and have individual files for the remaining five? |
| 02:25 |
|
avienu joined #salt |
| 02:25 |
|
andrej left #salt |
| 02:25 |
|
andrej joined #salt |
| 02:25 |
|
NotreDev joined #salt |
| 02:26 |
andrej |
And more questions about user management ... how would one go about getting e.g. a "group" of users to be present on some machines, but not others? Or, let's say I have a list of 20 people to maintain, 15 of which need to be present on ALL my minions, and 5 only on a few ... do I make a states file specific to each minion, and include e.g. one file that holds the 15 obligatory people, and have individual files for the remaining five? |
| 02:28 |
|
tinkster joined #salt |
| 02:29 |
|
Furao joined #salt |
| 02:30 |
tinkster |
Meh |
| 02:30 |
tinkster |
BitchX was having a hissy fit ... did my last question about user & group maintenance show up? |
| 02:32 |
mech422 |
tinkster: you could create a pillar entry with the 2 lists of users... |
| 02:32 |
|
oz_akan_ joined #salt |
| 02:32 |
mech422 |
tinkster: and have the sls file use that to create the users |
| 02:33 |
tinkster |
thx mech - that sounds sane |
| 02:33 |
mech422 |
np |
| 02:34 |
|
deepakmd_oc joined #salt |
| 02:35 |
|
Ryan_Lane joined #salt |
| 02:35 |
|
goki joined #salt |
| 02:36 |
|
log0ymxm joined #salt |
| 02:49 |
tinkster |
Right ... I think this http://dev.mlsdigital.net/posts/SaltStackBeyondJinjaStates/ looks great :) |
| 02:49 |
tinkster |
My next big question: is there a way to have people who don't have a .present removed? |
| 02:50 |
tinkster |
I.e., we're switching to salt, a few machines have the user bill, some have pete ... I don't like the idea of having to scrounge all password files on all machines and make .absent entries for people I don't want |
| 02:51 |
tinkster |
Ignoring system users - how do I easily cull ones not part of my list? |
| 02:51 |
|
jpeach joined #salt |
| 03:00 |
tinkster |
Hmmm ... is there a way to list all users from within jinja, and to determine whether or not they're system user? :) |
| 03:01 |
tinkster |
I can see some scripting in my near future, but would like to avoid re-inventing the whole wheel |
| 03:06 |
|
blee joined #salt |
| 03:06 |
|
emocakes joined #salt |
| 03:07 |
|
cro joined #salt |
| 03:08 |
|
joshe joined #salt |
| 03:08 |
|
gamingrobot joined #salt |
| 03:09 |
mech422 |
tinkster: jijna should shoud grains and pillars.. |
| 03:09 |
mech422 |
tinkster: like {{ grains.os }} or {{ grains.['id'] }} |
| 03:09 |
tinkster |
heh |
| 03:10 |
|
krissaxton joined #salt |
| 03:10 |
mech422 |
I dont use pillars - but I think they are {{ pillar['foo'] }} |
| 03:10 |
|
akitada joined #salt |
| 03:10 |
mech422 |
not sure how you'd tell which are system users though |
| 03:10 |
mech422 |
maybe put the system users in a special entry in the pillar ? |
| 03:10 |
jcockhren |
mech422: you don't use pillars?!?! you monster |
| 03:11 |
jcockhren |
:) |
| 03:11 |
mech422 |
jcockhren: Hey! I only kicked _two_ puppies on the way in to work today!! |
| 03:11 |
mech422 |
:-P |
| 03:11 |
jcockhren |
ha |
| 03:11 |
tinkster |
Well .. there's a salt.states.user system |
| 03:12 |
tinkster |
Not sure how I'd query that in an iterative manner, though, i.e., how do I extract a list of all users, and then eliminate the system ones |
| 03:12 |
mech422 |
jcockhren: btw - I think states.grains needs '-watch' support |
| 03:12 |
mech422 |
jcockhren: so you can do stuff like set a grain after a package installs successfully |
| 03:13 |
mech422 |
jcockhren: sound like a good use to you ? |
| 03:15 |
jcockhren |
hmm |
| 03:15 |
jcockhren |
mech422: grains are meant to be pretty static |
| 03:16 |
mech422 |
jcockhren: yeah - I'm punting a configuration database in my grains :-P |
| 03:17 |
|
whit joined #salt |
| 03:17 |
mech422 |
jcockhren: but I thought that might be useful for people in general... so you can check if something has been done or not,etc ? |
| 03:17 |
jcockhren |
ideally, a grain is used to describe a minion |
| 03:17 |
jcockhren |
using pillar for that would make since however |
| 03:17 |
jcockhren |
I don't think there's a way to "watch" a pillar |
| 03:18 |
jcockhren |
maybe there should be a state for firing an event |
| 03:18 |
jcockhren |
for example at a package installation |
| 03:18 |
jcockhren |
then have a reactor do something |
| 03:19 |
jcockhren |
wait... |
| 03:19 |
jcockhren |
maybe we *can* fire an event at a state completion |
| 03:20 |
jcockhren |
use the state: module.run |
| 03:20 |
jcockhren |
have it require another completed state |
| 03:20 |
|
sssslang joined #salt |
| 03:21 |
jcockhren |
module run can call the event.file module |
| 03:21 |
jcockhren |
event.fire* |
| 03:23 |
jcockhren |
I think mech422 just doesn't like pillar |
| 03:24 |
jcockhren |
:-p |
| 03:25 |
jcockhren |
mech422: keep thinking along your line of thought. that's the only way to ensure salt becomes to most useful |
| 03:25 |
jcockhren |
s/becomes/remains/ |
| 03:28 |
jcockhren |
mech422: how would you propose setting such a grain |
| 03:28 |
jcockhren |
? |
| 03:28 |
|
littleidea joined #salt |
| 03:29 |
jcockhren |
nm |
| 03:31 |
jcockhren |
if we had a way to emit an event (with a payload) when a grain is set or changed, then I think that would help mech422's use case |
| 03:32 |
jcockhren |
mech422: I think I got it |
| 03:32 |
jcockhren |
mech422: How about watching the file the contains the grains? |
| 03:33 |
jcockhren |
by default it's /etc/salt/grains |
| 03:33 |
|
oz_akan_ joined #salt |
| 03:35 |
|
fxhp joined #salt |
| 03:35 |
jcockhren |
a grain is set/changed (via grains.present state) -> file.managed.watch picks it up -> module.run fires an event -> reactor does something |
| 03:37 |
jcockhren |
figuring out 'which' grain was set/changed can happen with the stateID that does the module.run via a jinja is statement |
| 03:38 |
jcockhren |
s/is/if |
| 03:38 |
jcockhren |
and... I'm wired off coffee. my bad for the flood folks |
| 03:39 |
mech422 |
sorry...was on the phone..lemme read the scrollback |
| 03:41 |
mech422 |
jcockhren: lol - my stuff isn't that ambitious... |
| 03:41 |
mech422 |
let me throw up a gist for ya |
| 03:41 |
|
troyready joined #salt |
| 03:42 |
|
nu7hatch joined #salt |
| 03:43 |
|
goki joined #salt |
| 03:44 |
mech422 |
jcockhren: https://gist.github.com/mech422/6633041 |
| 03:45 |
|
shinylasers joined #salt |
| 03:46 |
|
Artanicus joined #salt |
| 03:48 |
offby1 |
eww gross |
| 03:49 |
jcockhren |
mech422: to be honest it looks like you're trying to use grains as an event system |
| 03:50 |
mech422 |
jcockhren: no, actually as a key:value store :-P |
| 03:50 |
|
sinh joined #salt |
| 03:50 |
mech422 |
jcockhren: the basic problem is salt has no config DB baked in |
| 03:50 |
forrest |
lol |
| 03:50 |
mech422 |
jcockhren: so every state has to execute every time to figure out if its up to date |
| 03:51 |
mech422 |
jcockhren: and doing states like a generic 'httpd' that are smart enough not to install nginx if apache is already installed are a pain |
| 03:52 |
mech422 |
jcockren: for simple stuff like this - I'd think an event system would be overkill? |
| 03:53 |
jcockhren |
thanks for the explanation of your scenario |
| 03:54 |
mech422 |
jcockhren: heh...he says backing slowly away from the keyboard... :-P |
| 03:56 |
jcockhren |
ok. then why not use a returner with a redis backend? |
| 03:56 |
|
Furao joined #salt |
| 03:57 |
jcockhren |
the redis backend would store the response to a state that installs package X |
| 03:57 |
mech422 |
jcockhren: cuz I'm lazy :-P |
| 03:57 |
mech422 |
jcockhren: I'm not crazy - I realize grains wouldn't work for everyone... |
| 03:57 |
|
jslatts joined #salt |
| 03:57 |
mech422 |
jcockhren: but I only have a dozen machines and maybe a dozen more vm's |
| 03:58 |
mech422 |
jcockhren: so less then 500 artifacts to track |
| 03:58 |
|
emocakes joined #salt |
| 03:58 |
mech422 |
jcockhren: that just doesn't seem to justify setting up a bunch of extra systems ? |
| 03:58 |
jcockhren |
mech422: I mean I get your point. but every grain that set is stored in a file |
| 03:58 |
jcockhren |
my caffine induced thinking aloud isn't too far off base is it? |
| 03:59 |
mech422 |
jcockhren: no - not at all |
| 03:59 |
jcockhren |
you'll have the file that contains the grains and you can know when it changes |
| 03:59 |
mech422 |
jcockhren: though instead of an event system and redis - if I had to do this 'right' |
| 03:59 |
mech422 |
I'd do a mysql module that just connects to a remote mysql instance and sets/gets key value pairs |
| 04:00 |
mech422 |
something like : |
| 04:00 |
|
bhosmer_ joined #salt |
| 04:00 |
mech422 |
target: |
| 04:00 |
mech422 |
mysql.set: |
| 04:00 |
mech422 |
- key: foo |
| 04:00 |
mech422 |
- value: bar |
| 04:00 |
mech422 |
- watch: |
| 04:00 |
mech422 |
cmd: install_completed |
| 04:00 |
mech422 |
or some such |
| 04:01 |
mech422 |
then all your stuff is in a nice neat sql db for reporting and what-not |
| 04:01 |
jcockhren |
I see |
| 04:02 |
mech422 |
jcockhren: or would you still go event based ? |
| 04:02 |
jcockhren |
http://docs.saltstack.com/ref/modules/all/salt.modules.mysql.html#salt.modules.mysql.query |
| 04:02 |
jcockhren |
mech422: I think I'm beginning to see what you mean |
| 04:03 |
jcockhren |
(this time) |
| 04:03 |
mech422 |
jcockhren: lol - don't feel bad...thats a good thing... I'm usually full of shit :-P |
| 04:04 |
jcockhren |
mech422: the thing is, you're kind of describing the returner system |
| 04:04 |
mech422 |
jcockhren: aww dam... this does look better then my way :-P |
| 04:04 |
mech422 |
jcockhren: yeah - sorta... I just wanted to bypass the event system and the extra setup |
| 04:04 |
mech422 |
jcockhren: like I said, I have _very_ lil data |
| 04:04 |
jcockhren |
everyone has a little until they have a alot |
| 04:05 |
mech422 |
jcockhren: true |
| 04:05 |
mech422 |
jcockhren: I'm growing at 1 machine / year ... |
| 04:05 |
jcockhren |
but the state system is exactly that: the system state |
| 04:06 |
mech422 |
jcockhren: right - the thing is its not _persistent_ state |
| 04:06 |
mech422 |
jcockhren: it has to be re-generated from scratch every run |
| 04:06 |
jcockhren |
yes. it *can* be |
| 04:06 |
jcockhren |
based on your returner |
| 04:06 |
mech422 |
jcockhren: true - if you hook up the returners and what not |
| 04:06 |
jcockhren |
oh... |
| 04:07 |
jcockhren |
how about a returner that affects grains? |
| 04:07 |
jcockhren |
hmmmm |
| 04:08 |
mech422 |
jcockhren: oh - whatever... I'm not partial to grains ... |
| 04:08 |
mech422 |
jcockhren: they were just what I had baked in with no extra work required |
| 04:08 |
jcockhren |
mech422: I thought you *was* partial to grains. LOL |
| 04:09 |
mech422 |
jcockhren: I'm partial to *lazy* - grains are already there, and already setup... so I (ab-)used them |
| 04:09 |
jcockhren |
word |
| 04:10 |
|
krissaxton joined #salt |
| 04:10 |
jcockhren |
yeah. I'm not getting where you'd be making your life easier with that |
| 04:11 |
|
avienu joined #salt |
| 04:12 |
mech422 |
jcockhren: well - for one, now I can say salt * state.sls foo.install or state.sls foo.remove and keep all my logic in one place instead of two... |
| 04:13 |
mech422 |
of course, you could extend that however far ya like : foo.reconfigure, foo.whatever, etc |
| 04:13 |
jcockhren |
mech422: so could that part be solved by allowing dot notation to apply to State designations inside an sls file? |
| 04:13 |
jcockhren |
(b/c we currently can't do that) |
| 04:14 |
mech422 |
jcockhren: umm - yeah - but this works now :-P |
| 04:14 |
jcockhren |
I think someone asked for that a couple days ago actually |
| 04:14 |
jcockhren |
mech422: so it "works" for you? |
| 04:14 |
mech422 |
jcockhren: no, it _works_ for me ? |
| 04:14 |
mech422 |
jcockhren: why does that bother you ? |
| 04:15 |
mech422 |
I found a way to make it work now... I'm happy :-P |
| 04:15 |
jcockhren |
if it works, then that's a write-up/blog or something |
| 04:15 |
jcockhren |
just saying... |
| 04:15 |
mech422 |
I realize it won't work for everyone else - I'm just wierd :-P |
| 04:16 |
mech422 |
hehe - I don't blog - there's enough crazy people on the internet without me addign to it :-P |
| 04:16 |
jcockhren |
but still... if it shows flexibility or limits of the system, it's worth it no? |
| 04:16 |
jcockhren |
call it what you want, gist/blog/wiki... ;-p |
| 04:17 |
mech422 |
well - I gave ya a gist - but I don't blog, twitter, social, or circle |
| 04:17 |
mech422 |
I'm an anti-social old fart :-P |
| 04:17 |
jcockhren |
mech422: do you write descriptions? |
| 04:17 |
jcockhren |
mech422: maybe even more comments |
| 04:17 |
mech422 |
jcockhren: Do irc logs count ? |
| 04:17 |
jcockhren |
then boom, done |
| 04:18 |
jcockhren |
I'm lazy, I'm not gisting this whole thread |
| 04:18 |
mech422 |
jcockhren: no log bot ? |
| 04:18 |
jcockhren |
not my channel |
| 04:18 |
mech422 |
jcockhren: anyway - like we said, no one else is crazy enough to bother with this stuff... |
| 04:19 |
mech422 |
really - I just thought it might be nice for states.grains to be able to write a value conditional on something changing |
| 04:19 |
mech422 |
someone might find a good use for that |
| 04:19 |
mech422 |
I mean... we can already set a grain in an sls via states/grains ... so why not ? |
| 04:20 |
mech422 |
the rest of it is just the mad ramblings of a tired, lazy ole geek :-P |
| 04:21 |
|
micah_chatt joined #salt |
| 04:22 |
jcockhren |
mech422: feel like posting nginx/pkgconfig.jinja? |
| 04:22 |
mech422 |
lol |
| 04:23 |
jcockhren |
that might be exactly like terminalmage's |
| 04:23 |
jcockhren |
who knows |
| 04:23 |
mech422 |
jcockhren: I added it as a comment to that gist |
| 04:24 |
mech422 |
jcockhren: and yeah - its just a cut/paste I ripped from some apache formulae in the repo |
| 04:26 |
|
Katafalkas joined #salt |
| 04:26 |
mech422 |
jcockhren: I can't believe your saving that :-P Now we're both crazy :-P |
| 04:27 |
jcockhren |
nah. I just collect rablings |
| 04:28 |
jcockhren |
ramblings |
| 04:29 |
mech422 |
jcockhren: ahh... you'll make a fine witness for the state at my sanity hearing ;-) |
| 04:29 |
jcockhren |
for whom? the prosecution or the defense? |
| 04:30 |
mech422 |
jcockhren: hehe...the defense, if I buy the beer ? |
| 04:31 |
mech422 |
jcockhren: btw - can you pass arbitrary data back to the returners ? like say a serial number some application installer generates ? |
| 04:31 |
mech422 |
or is it just 'state' information ? |
| 04:31 |
|
jalbretsen joined #salt |
| 04:32 |
jcockhren |
a custom returner can do what it wants |
| 04:32 |
jcockhren |
as for the ones built-in... it's the responses to calls |
| 04:32 |
jcockhren |
this include calls to states and modules |
| 04:33 |
jcockhren |
the responses from those |
| 04:33 |
jcockhren |
mech422: from the docs -> "salt '*' test.ping --return redis_return" |
| 04:34 |
mech422 |
Hmm...I'll have to read up on the custom returner stuff... can you have custom returners per module type? |
| 04:34 |
mech422 |
like say I want that serial number - does my returner have to handle all the state returns, or can I tell it to just wait for stuff from the serial number module ? |
| 04:37 |
|
piffio joined #salt |
| 04:38 |
jcockhren |
I *thought* a saw something that allowed states to define it's returner, BUT I really probably dreamed that up |
| 04:39 |
mech422 |
jcockhren: I'll have to read up... thanks for the pointer :-) |
| 04:40 |
|
littleidea_ joined #salt |
| 04:41 |
jcockhren |
mech422: http://docs.saltstack.com/ref/modules/all/salt.modules.ret.html#module-salt.modules.ret |
| 04:41 |
|
nu7hatch joined #salt |
| 04:42 |
jcockhren |
oh |
| 04:42 |
jcockhren |
that was the scheduler |
| 04:43 |
jcockhren |
where I saw you can set an returner |
| 04:44 |
mech422 |
jcockhren: I'll nosey around a bit tommorrow... |
| 04:44 |
mech422 |
jcockhren: I should prolly head to bed :-) |
| 04:45 |
jcockhren |
later |
| 04:45 |
mech422 |
jcockhren: take care! |
| 04:45 |
|
mgw joined #salt |
| 04:51 |
|
Ryan_Lane1 joined #salt |
| 04:59 |
|
devinus joined #salt |
| 05:11 |
|
krissaxton joined #salt |
| 05:16 |
|
sgviking joined #salt |
| 05:23 |
|
gamingrobot joined #salt |
| 05:24 |
|
gildegoma joined #salt |
| 05:26 |
|
akitada joined #salt |
| 05:36 |
|
sgviking joined #salt |
| 05:36 |
|
sgviking left #salt |
| 06:01 |
|
sfello joined #salt |
| 06:09 |
|
tomtomtomtom joined #salt |
| 06:11 |
|
krissaxton joined #salt |
| 06:13 |
|
SpX joined #salt |
| 06:28 |
|
maveas joined #salt |
| 06:31 |
|
Sypher joined #salt |
| 06:33 |
|
sfello_ joined #salt |
| 06:33 |
|
xl1 joined #salt |
| 06:33 |
|
berto- joined #salt |
| 06:35 |
|
ml_1 joined #salt |
| 06:45 |
|
sfello joined #salt |
| 06:53 |
|
malinoff joined #salt |
| 06:56 |
|
micah_chatt joined #salt |
| 06:58 |
|
jslatts joined #salt |
| 06:59 |
|
lahwran joined #salt |
| 07:00 |
|
havan joined #salt |
| 07:12 |
|
krissaxton joined #salt |
| 07:20 |
|
emocakes joined #salt |
| 07:38 |
|
krissaxton joined #salt |
| 07:38 |
|
cdunklau joined #salt |
| 07:39 |
|
raghavp joined #salt |
| 07:43 |
|
davidone joined #salt |
| 07:50 |
|
adepasquale joined #salt |
| 08:06 |
|
bemehow joined #salt |
| 08:09 |
|
tomspur joined #salt |
| 08:09 |
|
tomspur joined #salt |
| 08:11 |
|
sgviking joined #salt |
| 08:20 |
|
ronc joined #salt |
| 08:44 |
|
unicoletti_ joined #salt |
| 08:49 |
|
fredvd joined #salt |
| 08:50 |
|
oz_akan_ joined #salt |
| 08:50 |
|
oz_akan_ joined #salt |
| 08:57 |
|
sfello joined #salt |
| 08:57 |
|
zach joined #salt |
| 08:59 |
|
sfello_ joined #salt |
| 09:00 |
|
fredvd joined #salt |
| 09:00 |
|
sfello joined #salt |
| 09:02 |
|
lahwran joined #salt |
| 09:02 |
|
krissaxton joined #salt |
| 09:05 |
|
darrend joined #salt |
| 09:05 |
|
fredvd joined #salt |
| 09:11 |
|
bhosmer_ joined #salt |
| 09:13 |
|
ciss joined #salt |
| 09:29 |
|
abk joined #salt |
| 09:32 |
|
sssslang joined #salt |
| 09:39 |
|
fredvd joined #salt |
| 09:41 |
yml |
any idea why this is not working : sudo salt "my-minion" pkg.install elasticsearch sources="[{'elasticsearch':'https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.5.deb'}]" |
| 09:47 |
|
krissaxton joined #salt |
| 09:54 |
|
lemao joined #salt |
| 09:57 |
|
raghavp joined #salt |
| 10:12 |
|
hazzadous joined #salt |
| 10:17 |
|
[diecast] joined #salt |
| 10:25 |
|
TheCodeAssassin joined #salt |
| 10:36 |
|
krissaxton joined #salt |
| 10:37 |
|
ml_11 joined #salt |
| 10:53 |
|
ggoZ joined #salt |
| 11:07 |
|
logix812 joined #salt |
| 11:15 |
|
bemehow joined #salt |
| 11:27 |
|
krissaxton joined #salt |
| 11:29 |
|
sssslang joined #salt |
| 11:32 |
|
emocakes joined #salt |
| 11:41 |
|
krissaxton joined #salt |
| 11:44 |
|
gildegoma joined #salt |
| 11:44 |
|
jslatts joined #salt |
| 11:52 |
|
felixhummel joined #salt |
| 11:54 |
|
jkleckner joined #salt |
| 11:56 |
|
jamiem joined #salt |
| 11:59 |
andrewclegg |
in a custom module, what's the correct way to print output that displays on the master? |
| 12:02 |
andrewclegg |
the "printout configuration" in the modules doc page is woefully thin on detail |
| 12:03 |
andrewclegg |
do you just set it to "txt" for a given function, then return that value? |
| 12:04 |
|
bemehow joined #salt |
| 12:06 |
|
blee joined #salt |
| 12:09 |
andrewclegg |
n/m, think I've figured it out by reading source from existing modules |
| 12:12 |
|
oz_akan_ joined #salt |
| 12:14 |
|
bhosmer_ joined #salt |
| 12:16 |
|
tuxIO joined #salt |
| 12:20 |
|
mech422 joined #salt |
| 12:20 |
mech422 |
Morning |
| 12:23 |
|
sfello joined #salt |
| 12:23 |
|
ggoZ joined #salt |
| 12:37 |
|
krissaxton joined #salt |
| 12:42 |
|
elsmorian joined #salt |
| 12:42 |
|
piffio joined #salt |
| 12:44 |
|
[diecast] joined #salt |
| 12:44 |
|
sfello_ joined #salt |
| 12:47 |
|
az87c joined #salt |
| 12:48 |
|
az87c_ joined #salt |
| 12:51 |
|
matanya joined #salt |
| 12:52 |
andrewclegg |
this is weird. I'm invoking run_all from salt.modules.cmdmod in my own module, and I keep getting this exception: |
| 12:52 |
andrewclegg |
NameError: global name '__salt__' is not defined |
| 12:52 |
andrewclegg |
from File "/usr/lib/python2.6/site-packages/salt/modules/cmdmod.py", line 127, in _render_cmd |
| 12:52 |
andrewclegg |
but I'm using __salt__ in my own module and it's working fine |
| 12:52 |
andrewclegg |
do I need to do something else to inject __salt__ into modules I use? |
| 12:54 |
|
oz_akan_ joined #salt |
| 12:54 |
andrewclegg |
oh, I think it's because I'm calling the function directly, rather than getting it via my own __salt__ object |
| 12:54 |
|
matanya joined #salt |
| 12:56 |
|
matanya joined #salt |
| 13:00 |
|
tuxIO_ joined #salt |
| 13:01 |
|
Brew joined #salt |
| 13:05 |
|
zloidemon joined #salt |
| 13:06 |
|
Gifflen joined #salt |
| 13:08 |
|
jslatts joined #salt |
| 13:09 |
|
jergerber joined #salt |
| 13:10 |
|
JoAkKiNeN joined #salt |
| 13:14 |
|
mohae joined #salt |
| 13:14 |
|
toastedpenguin joined #salt |
| 13:20 |
|
juicer2 joined #salt |
| 13:21 |
|
whit joined #salt |
| 13:23 |
|
mapu joined #salt |
| 13:25 |
|
bemehow joined #salt |
| 13:25 |
|
Kholloway joined #salt |
| 13:28 |
|
sfello joined #salt |
| 13:28 |
|
pdayton joined #salt |
| 13:28 |
|
bemehow joined #salt |
| 13:30 |
|
sfello_ joined #salt |
| 13:32 |
|
sfello joined #salt |
| 13:32 |
|
elsmorian joined #salt |
| 13:33 |
|
APLU joined #salt |
| 13:33 |
|
sfello joined #salt |
| 13:34 |
|
imaginarysteve joined #salt |
| 13:34 |
|
lacrymology joined #salt |
| 13:35 |
ldlework |
anyone here using salt-cloud? |
| 13:35 |
|
sfello_ joined #salt |
| 13:36 |
piffio |
ldlework: not me, at least not yet, sorry |
| 13:36 |
ldlework |
It doesn't work! sshpass fails to login to the newly spun server. |
| 13:37 |
ldlework |
I'm stumped |
| 13:37 |
|
sfello joined #salt |
| 13:40 |
|
jeddi joined #salt |
| 13:43 |
|
faldridge joined #salt |
| 13:44 |
|
jeddi left #salt |
| 13:44 |
|
robertkeizer joined #salt |
| 13:45 |
|
fivethre1o joined #salt |
| 13:46 |
|
tmmt_ joined #salt |
| 13:46 |
|
akitada joined #salt |
| 13:47 |
|
msheiny joined #salt |
| 13:47 |
|
jefferai joined #salt |
| 13:48 |
|
StDiluted joined #salt |
| 13:48 |
|
__number5__ joined #salt |
| 13:50 |
|
xerxas_ joined #salt |
| 13:55 |
|
oz_akan_ joined #salt |
| 13:59 |
|
m_george|away joined #salt |
| 14:00 |
|
ipmb joined #salt |
| 14:01 |
lacrymology |
say I've got a module foo, and I define foo, bar, and foobar that calls foo and bar in order. Is it better to call __salt__['foo'] and __salt__['bar'] than the functions directly, in case they've been overriden somewhere? |
| 14:01 |
|
m_george left #salt |
| 14:06 |
|
mwillhite joined #salt |
| 14:06 |
|
mannyt joined #salt |
| 14:12 |
|
avienu joined #salt |
| 14:14 |
|
micah_chatt joined #salt |
| 14:14 |
|
Hans__ joined #salt |
| 14:14 |
|
bud_ joined #salt |
| 14:16 |
bud_ |
Hello all. |
| 14:16 |
bud_ |
I am trying to send some information in the mine using a custom written module. |
| 14:16 |
bud_ |
Basic stuff nothing hard core. The module is the following - https://gist.github.com/valentinbud/6638247. |
| 14:17 |
bud_ |
I ran salt '*' mine.send oneadmin.get_ssh_public_key and I receive a False response from minions. |
| 14:18 |
bud_ |
The information is not part of the mine. Checked it with salt '*' mine.get '*' oneadmin.get_ssh_public_key |
| 14:18 |
|
kermit joined #salt |
| 14:19 |
|
NotreDev joined #salt |
| 14:19 |
joehh |
bud_: obvious question, the path "/var/lib/one/.ssh/id_rsa.pub" exists? |
| 14:19 |
bud_ |
I have also enabled mine_functions:\n oneadmin.get_ssh_public_key: [] in the minion and ran salt '*' mine.update. |
| 14:19 |
|
teskew joined #salt |
| 14:19 |
bud_ |
Same result. Does anybody have an idea on why it's not working. |
| 14:20 |
|
mannyt joined #salt |
| 14:20 |
joehh |
can you run it directly as a module: salt '*' gistfile.get_ssh_public_key |
| 14:22 |
Hans__ |
Hello, I just wanted to know how you guys are handling the removal of files no longer under configuration management. Let's say you remove a state from a server, do you remove all files (and packages, etc) that were placed by that state manually, do you write an absent state or do you install that server from scratch? |
| 14:22 |
bud_ |
Thanks for the tip. |
| 14:23 |
joehh |
Hans__: depends on the context, where we let developers put many states on for many purposes (ie machine will be used over long period for many tasks) |
| 14:23 |
joehh |
then we require absent states |
| 14:23 |
joehh |
for single purpose systems, we typically just spin up a new vm |
| 14:25 |
|
miva joined #salt |
| 14:26 |
Hans__ |
Hm, I thought as much. It is probably a good idea anyway to set up a new machine if you for some reason decide for example, that a machine no longer requires an apache. |
| 14:27 |
alexandrel |
Heh! cmd.wait's onlyif and unless arguments are pretty kewl. |
| 14:27 |
|
jalbretsen joined #salt |
| 14:28 |
alexandrel |
Hans__: I destroy the machine, and start fresh. |
| 14:28 |
|
racooper joined #salt |
| 14:29 |
alexandrel |
Hans__: if I don't, the possibility of any remaining artefacts positively drive me nuts. |
| 14:29 |
miva |
Can anyone tell me what I'm doing wrong here in pillars? I want to be able to maintain all my "roles" on the master instead of in grains on each minion https://gist.github.com/anonymous/4b489dcbefc31e2bfbfc |
| 14:29 |
miva |
It's trying to load an SLS instead of setting variables, I'm sure I'm just misunderstanding pillars |
| 14:33 |
mohae |
miva: is that file in your srv/salt? |
| 14:33 |
miva |
thats my /srv/pillar/top.sls file |
| 14:33 |
mohae |
miva: you access pillars similar to this: {% if grains['os'] == 'RedHat' %}, http://docs.saltstack.com/topics/pillar/ |
| 14:34 |
miva |
I'm trying to make it so that I can do salt -I 'roles: web server' or whatever the syntax is |
| 14:34 |
miva |
but I want to set the roles for all minions on the master, not in the minions |
| 14:35 |
mohae |
miva: assuming you have a webserver.sls in pillars, how are you trying to access the pillar data in srv/salt? |
| 14:35 |
mohae |
oh...well I'm not sure about setting roles for minions on the master, sorry |
| 14:38 |
miva |
mohae: no problem, thanks anyways. I'm hoping there is a way to do it and I'm just missing it. Is the "standard" to write roles for a minion on the minion each time you spin one up? |
| 14:45 |
|
teskew joined #salt |
| 14:45 |
|
cnelsonsic joined #salt |
| 14:46 |
|
VertigoRay joined #salt |
| 14:47 |
mohae |
miva, so, instead of targeting a minion by its id, you want another way to target minions for roles? |
| 14:48 |
miva |
mohae: Right, I basically just want to make it so that when I'm adding a new minion I can go in the master and add them to a "role" or whatever it is, then run a high state (or something) and have it install all the packages/services, etc. that I've already setup. This is also my first time using salt so I only have the basics going, one master one minion for now, more to be added later |
| 14:49 |
|
tuxIO_ joined #salt |
| 14:49 |
mohae |
miva, try nodegroups http://docs.saltstack.com/topics/targeting/nodegroups.html |
| 14:50 |
|
cloq joined #salt |
| 14:51 |
mohae |
miva: I'm new to salt too, but there's usually quite a few experienced people, including salt devs, in here. Sorry I'm not of much help atm |
| 14:51 |
miva |
mohae: Thanks I will take a look at that, looks like I could use that fairly easily as a "last resort" I'd rather assign the "roles" to minions rather than the minions to "roles". But this would definitely work if the former isn't possible. Thanks! |
| 14:52 |
|
littleidea joined #salt |
| 14:54 |
mohae |
miva: hmmm, I think the thing about assigning roles to minions is that minions may be ephemeral, hopefully roles aren't |
| 14:55 |
mohae |
but I'll have to think more about roles to minions vs minions to roles |
| 14:57 |
|
UtahDave joined #salt |
| 15:00 |
|
mmilano joined #salt |
| 15:01 |
cloq |
hello, I found a msgpack-python-related issue that doesn't seem to be fixed in the 0.16 branch -- state executes and returns properly, however there isn't any output shown, it happens to me about 10 % of cases http://pastebin.com/G8VaYhyi |
| 15:02 |
cloq |
anyone recognize this? I couldn't find any related entry on github |
| 15:02 |
|
uta joined #salt |
| 15:03 |
|
elsmorian joined #salt |
| 15:03 |
|
higgs001 joined #salt |
| 15:03 |
cloq |
anyway, I finally created a 100% reproducible setting |
| 15:04 |
uta |
hey has anybody got a good way of debugging the whole "minion failed to authenticate with the master has the minion key been accepted" error? We've started getting it today constantly with a minion that returns true to 'test.ping'... |
| 15:09 |
UtahDave |
cloq: could you open an issue on that? |
| 15:10 |
andrewclegg |
is there a built-in way to get all the environment variables a minion is running with? |
| 15:10 |
andrewclegg |
not one-by-one but as a dict? |
| 15:10 |
cloq |
UtahDave: alright |
| 15:10 |
andrewclegg |
context: I want to modify the path and pass it back in to the env parameter of cmd.run |
| 15:11 |
andrewclegg |
but I don't think I can just pass one var like PATH -- I need the whole env |
| 15:14 |
|
jpeach joined #salt |
| 15:16 |
|
StDiluted joined #salt |
| 15:19 |
|
nu7hatch joined #salt |
| 15:20 |
andrewclegg |
no, my bad, salt merges in the dict of env vars for a run command, so you only need the ones you're changing... |
| 15:20 |
|
diegows joined #salt |
| 15:28 |
|
elsmorian1 joined #salt |
| 15:29 |
|
unicoletti left #salt |
| 15:29 |
micah_chatt |
jcockhren: UtahDave: I'm just about ready with a PR for the Django ORM ext_pillar |
| 15:29 |
UtahDave |
micah_chatt: cool! |
| 15:30 |
micah_chatt |
UtahDave: what is the recommended way to discuss a PR like this? post the patch to the mailing list and discuss? or just PR and discuss on github? |
| 15:30 |
UtahDave |
micah_chatt: PR and discuss on github |
| 15:30 |
micah_chatt |
Sweet, will do |
| 15:30 |
|
havan joined #salt |
| 15:32 |
|
Kyle_ joined #salt |
| 15:33 |
UtahDave |
thanks, micah_chatt! |
| 15:33 |
micah_chatt |
gladly |
| 15:33 |
micah_chatt |
I'm going to get good use out of it, hopefully someone else will too |
| 15:33 |
|
bud_ joined #salt |
| 15:35 |
cwright |
is there a good tutorial somewhere on using salt mine? |
| 15:35 |
|
movedx_ joined #salt |
| 15:36 |
movedx_ |
Hello. Does Salt have a means of bootstrapping its self onto a new server without the Salt agent? |
| 15:37 |
ipmb |
movedx_: SSH support is coming |
| 15:39 |
ipmb |
movedx_: what do you mean by "bootstrapping itself"? |
| 15:39 |
movedx_ |
Getting the Salt agent installed on a new system without the Salt agent. |
| 15:39 |
movedx_ |
And on a system you had no involvement in the provisioning/building/setup of. |
| 15:40 |
movedx_ |
So basically getting Salt in place after the IP has been handed to you. |
| 15:40 |
ipmb |
you could script it pretty easily |
| 15:41 |
ipmb |
it's 3 steps. Install agent, point to master, accept key on master |
| 15:41 |
movedx_ |
This is true, yes. |
| 15:42 |
ipmb |
Unrelatedââ¬Â¦ I bumped into an using the scheduler yesterday. All my schedules work except `ps.cpu_percent` |
| 15:42 |
|
dyim joined #salt |
| 15:42 |
movedx_ |
What license is Salt under? |
| 15:42 |
ipmb |
My schedule looks like this, https://dpaste.de/YDZqE/. Any ideas on why this one wouldn't work (but all the others do)? |
| 15:42 |
bud_ |
movedx_: Apache2 |
| 15:43 |
ipmb |
it works fine when I run it via salt-call |
| 15:43 |
bud_ |
I am trying to understand how can I run publish.publish from within a state. Does anybody have a working example? |
| 15:44 |
UtahDave |
movedx_: salt-cloud has a "saltify" driver that will install Salt on an existing server |
| 15:44 |
ipmb |
I still haven't figured out how to troubleshoot the scheduler, it's not dumping anything into my logs as far as i can tell |
| 15:44 |
|
bud_ joined #salt |
| 15:44 |
|
_mzito___ joined #salt |
| 15:45 |
UtahDave |
bud_: https://gist.github.com/UtahDave/5217462 |
| 15:45 |
UtahDave |
ipmb: I think there was a bug opened yesterday about the scheduler |
| 15:46 |
bud_ |
Thank you UtahDave :). |
| 15:47 |
|
forrest joined #salt |
| 15:47 |
UtahDave |
np |
| 15:49 |
bud_ |
And I can use the same format for cmd.run state I suppose. |
| 15:49 |
ipmb |
UtahDave: I don't think it applies |
| 15:49 |
ipmb |
I'll check though |
| 15:49 |
UtahDave |
ok, thanks, ipmb |
| 15:51 |
movedx_ |
Thanks UtahDave |
| 15:52 |
VertigoRay |
Hello! Anyone know where the salt-key code is? I seem some forks with it under salt/salt/cli, but I don't see the same key.py on saltstack/salt. |
| 15:52 |
|
havan joined #salt |
| 15:54 |
movedx_ |
I'm basically deciding which I want: Ansible or Salt. The former is GPLv3, which means if I use the Python API, my code must be GPLv3 (and I'm trying to create a proprietary, hosted service). |
| 15:55 |
movedx_ |
I also like the agent-less aspect of Ansible, but having an agent on the box isn't too much of an issue. |
| 15:56 |
ipmb |
UtahDave: is ssh support working in git? |
| 15:56 |
* ipmb |
doesn't know how far along that is |
| 15:56 |
ipmb |
but movedx_ agent-less over SSH is coming very soon afaik |
| 15:56 |
UtahDave |
salt-ssh is working in develop and in the 0.17 RC that was just released |
| 15:57 |
ipmb |
movedx_: https://github.com/saltstack/salt/issues/5914 |
| 15:57 |
movedx_ |
To be honest, it's the license that concerns me the most. I don't want to piss anyone off with a closed-source system. |
| 15:58 |
movedx_ |
The agent-less aspect is cool, but I may want an agent in the long run - I've not decided yet. |
| 15:58 |
UtahDave |
movedx_: yes, Salt is completely Apache 2.0 licensed. |
| 15:58 |
UtahDave |
movedx_: salt-ssh is agentless like that, too |
| 15:58 |
ipmb |
movedx_: the agent let's you do some pretty cool stuff |
| 15:58 |
movedx_ |
UtahDave: Does this mean that I can use it in a closed-source system? A non-distributed closed-source system? |
| 15:59 |
ipmb |
yep |
| 15:59 |
UtahDave |
movedx_: Yes |
| 15:59 |
movedx_ |
Interesting. GPLv3 is very sketchy on that, thus making Ansible less of an option. |
| 16:00 |
|
Gifflen_ joined #salt |
| 16:00 |
|
mgw joined #salt |
| 16:00 |
UtahDave |
movedx_: Yeah, the Apache 2.0 license Salt uses means you can use Salt for ANY use. Open or proprietary |
| 16:00 |
UtahDave |
movedx_: obviously we highly encourage giving code back to the project where possible, but there are no license requirements to do so |
| 16:02 |
movedx_ |
OK guys, here's one for you. We're using Puppet here. It's pretty cool, but we've got a chicken/egg problem. Let me ask you this: can I write plugins for Salt that allow me to pull a new server's IP from an IPAM and then update/store this on the master/server easily? Does that make sense? |
| 16:02 |
|
Gifflen joined #salt |
| 16:02 |
movedx_ |
UtahDave: I will give some elements back, but I want solid product in place before I do anything along thos elines. |
| 16:02 |
|
Lue_4911 joined #salt |
| 16:03 |
UtahDave |
movedx_: yep, that's totally fine. Apache 2.0 is very permissive that way |
| 16:03 |
UtahDave |
movedx_: Salt is extremely pluggable. What you're trying to do would probably be a good use case for an external pillar. |
| 16:03 |
movedx_ |
Interesting. |
| 16:05 |
movedx_ |
So we want agent's gaining an IP via a DHCP pool so they get connectivity to the master. Once they've got that, we will auto-sign the incoming certs (I know, I know), grab an IP from our IPAM, then tell the agent to use the new IP information. |
| 16:07 |
ipmb |
movedx_: agents don't need to know about IPs |
| 16:07 |
ipmb |
as long as the master has a static IP, I think it's fine for agents to jump around |
| 16:08 |
ipmb |
you assign them an ID that defaults to their FQDN |
| 16:08 |
movedx_ |
I think I've failed to communicate my point. We want the agent to have a static IP which is automagically discovered from an IPAM and given to the agent. |
| 16:08 |
|
deepakmd_oc joined #salt |
| 16:10 |
|
shinylasers joined #salt |
| 16:10 |
UtahDave |
movedx_: yeah, you can assign ips to agents. |
| 16:11 |
movedx_ |
I suspected as much, but the problem is how? How does the Salt Master get the IP and then safe it for state persistence later on? Like a kind of, "You're a new server! w00t! *talks to IPAM to get IP*! You can haz this IP now and forev0r!" etc |
| 16:12 |
UtahDave |
movedx_: when you run a highstate it will check the external pillar and the minion will be sure to assign itself the correct IP if it hasn't done so already |
| 16:13 |
movedx_ |
I need to investigate this "external pillar" you've mentioned twice now. |
| 16:13 |
movedx_ |
https://salt.readthedocs.org/en/latest/topics/development/external_pillars.html |
| 16:13 |
movedx_ |
? |
| 16:14 |
|
jefftriplett joined #salt |
| 16:17 |
|
troyready joined #salt |
| 16:19 |
|
lacrymology joined #salt |
| 16:22 |
|
nu7hatch joined #salt |
| 16:24 |
micah_chatt |
movedx_: I'm literally preparing a PR for the same problem you're having |
| 16:25 |
micah_chatt |
rignt now |
| 16:25 |
movedx_ |
PR? |
| 16:25 |
micah_chatt |
pull request |
| 16:25 |
movedx_ |
Nice. |
| 16:25 |
movedx_ |
So you've solved it, then? |
| 16:26 |
micah_chatt |
movedx_: the way I go about it is to use a django server to manage IP information |
| 16:26 |
movedx_ |
We already have an IPAM. |
| 16:26 |
micah_chatt |
ah ok |
| 16:26 |
movedx_ |
Interfacing with it shouldn't be an issue. It apparently offers an SDK/REST API, but it looks terrible. |
| 16:27 |
movedx_ |
Anyway we've invested a lot of time into Puppet so this problem will be resolved one way or another. Shame I can't switch to Ansible or Salt. |
| 16:27 |
|
jacksontj joined #salt |
| 16:27 |
micah_chatt |
movedx_: ok, then you'll need to write your own external pillar for that |
| 16:27 |
micah_chatt |
I'm just using a django server I wrote to do the IPAM thing |
| 16:28 |
movedx_ |
Good idea. I would use Flask personally, but Django is very nice. |
| 16:28 |
LucasCoz |
hellome, Is a mistake between cmd_iter and cmd_iter_no_block in the docs? Which one is blocking? |
| 16:29 |
micah_chatt |
yea, we're a django shop- so my engineers can all contribute to it too: in addition to our product code |
| 16:29 |
LucasCoz |
Here : http://docs.saltstack.com/ref/clients/index.html?highlight=cmd_iter#salt.client.LocalClient.cmd_iter |
| 16:30 |
movedx_ |
micah_chatt: Nice :) |
| 16:30 |
movedx_ |
Thanks for all the help. Be back Monday! :D |
| 16:30 |
movedx_ |
Have a good weekend all. |
| 16:32 |
|
Katafalkas joined #salt |
| 16:32 |
|
bitz joined #salt |
| 16:32 |
|
gildegoma joined #salt |
| 16:37 |
|
Gifflen_ joined #salt |
| 16:38 |
offby1 |
Here's a really dumb question: is salt a deployment system? |
| 16:38 |
offby1 |
That is, can I easily use it to push out updated versions of software that my team writes, and perhaps roll back to a previous version? |
| 16:38 |
offby1 |
I honestly cannot tell after having spent two days going through the docs. |
| 16:39 |
|
Gifflen_ joined #salt |
| 16:39 |
forrest |
you can use it that way offby1 |
| 16:39 |
offby1 |
forrest: is it _intended_ to be used that way, or is it sort of a stretch? Can you point to an example of it being used that way? |
| 16:40 |
forrest |
I actually don't have an example of it being used specifically for deployments, usuall the way I think about it is you build a machine with configuration xyz, then you update the associated files with that configuration, and re-run salt (in essence a deployment) |
| 16:40 |
offby1 |
hmm |
| 16:41 |
|
lacrymology joined #salt |
| 16:41 |
|
redondos joined #salt |
| 16:41 |
forrest |
so you could look at doing something like a jenkins build that deploys to a directory, and then salt drops specific files, or that directory onto the server. |
| 16:41 |
|
felixhummel_ joined #salt |
| 16:41 |
forrest |
you can also stage multiple environments, so you have dev/test/prod, each with their own unique version of app X, as wel as where it pulls the source files from. |
| 16:42 |
offby1 |
that makes sense. |
| 16:42 |
forrest |
yea, take a look at https://github.com/terminalmage/djangocon2013-sls |
| 16:42 |
forrest |
this isn't a deployment specifically |
| 16:42 |
forrest |
but if you consider the items like git, mysql, and pip to be your 'base' items |
| 16:42 |
andrewclegg |
offby1 forrest we very much use it for deployments |
| 16:42 |
forrest |
and then foo is your application, you could simply re-apply foo when you want to do a deployment. |
| 16:43 |
forrest |
yea I assume you just do what I was explaining andrewclegg? |
| 16:43 |
forrest |
update files, rerun your states |
| 16:43 |
* offby1 |
looks |
| 16:44 |
andrewclegg |
yep, exactly, e.g. we have a jenkins build that writes the build artifacts to a directory, which is in our salt file server tree |
| 16:44 |
forrest |
yup yup |
| 16:44 |
andrewclegg |
then it invokes salt to update the config of the machines where that app lives... and they pull the new version off the salt:// file server |
| 16:45 |
andrewclegg |
only downside, the recursive file copy is a bit slow, so we're planning to make it copy a tarball and then expand it on the minion side |
| 16:45 |
forrest |
oh that's a nice idea andrewclegg, should be easy to prep the tar as a last step in Jenkins too |
| 16:45 |
offby1 |
yikes, that terminalmage thing seems complex :-| |
| 16:46 |
forrest |
it's not |
| 16:46 |
forrest |
just look at each item in turn |
| 16:46 |
forrest |
and it makes it much easier to understand |
| 16:46 |
offby1 |
yeah, I guess it's just new to me |
| 16:46 |
forrest |
Have you used config management before offby1? |
| 16:46 |
andrewclegg |
forrest: yep. making your jenkins server and your salt master the same machine, simplifies this stuff a lot -- and you can let the jenkins user invoke the salt command via sudo |
| 16:46 |
forrest |
nice |
| 16:46 |
|
pipps joined #salt |
| 16:47 |
andrewclegg |
there's probably loads of other ways to set that sort of thing up, one thing I like loads about salt is its flexibility |
| 16:47 |
offby1 |
forrest: I've used "deployment systems" before (even wrote one) but I'm not sure if that's the same as "config management". I suspect the latter is, roughly, optimized for stuff that doesn't change as often -- such as /etc/apache2/httpd.conf -- whereas the former is optimized for changing my app's code, frequently |
| 16:48 |
|
jbunting joined #salt |
| 16:48 |
andrewclegg |
offby1: if you have your build system produce rpms or debs or whatever, then the two things become very much the same |
| 16:48 |
forrest |
Hmm, I guess that depends how you look at it, Salt can be used for deploys extremely easily. I just consider config management as a tool that has the additional ability to help you set up servers |
| 16:48 |
offby1 |
andrewclegg: I've been considering producing .debs actually |
| 16:48 |
andrewclegg |
we might end up going that way, instead of having what's basically homemade package management for our own code |
| 16:49 |
piffio |
Hi all |
| 16:49 |
offby1 |
andrewclegg: my fear is that producing a proper .deb entails a lot of overhead. But maybe not. |
| 16:49 |
andrewclegg |
we also use salt as an orchestration system -- kind of what you'd use fabric or mcollective for -- run this command on this set of machines, as long as this condition is true |
| 16:50 |
offby1 |
alas, I don't know what an "orchestration system" is, nor am I familiar with mcollective. (Fabric, as far as I can tell, is merely a convenience wrapper around ssh, which is clearly useful) |
| 16:50 |
|
bhosmer_ joined #salt |
| 16:50 |
offby1 |
Here's another, unrelated question (which I confess I could answer on my own with five minutes' experimentation, but I'm lazy): can I tell salt "please ensure this file has these contents", and then if some process modifies the file, salt will a) write a log noting that the file changed; and then b) fix it? |
| 16:51 |
andrewclegg |
I basically mean a wrapper around ssh, but with a bunch of higher level semantics too |
| 16:51 |
piffio |
question: does it exist an easy way to test that a nodegroup definition is correctly handled when applying highstate? |
| 16:52 |
piffio |
it looks to me that the one I have is not being considered, but I wonder whether there is an easy way for debugging this |
| 16:52 |
andrewclegg |
like things to accidentally stop you running the command on the wrong class of server, or which modify the params based on env vars or the machine's hardware or OS, or whatever |
| 16:52 |
|
KyleG joined #salt |
| 16:52 |
|
KyleG joined #salt |
| 16:52 |
nu7hatch |
is there a way to disable timeout in calling salt? I wanna call state.highstate and wait for the results no matter what. --timeout 0 doesn't seem to work here. |
| 16:53 |
UtahDave |
offby1: yes, Salt excels at software and code deployments |
| 16:53 |
andrewclegg |
offby1: re the other question, you can set up watches on a specific file, but I think you'd have to repeatedly run "state.highstate" on the master to get the minions to actually recheck that file |
| 16:53 |
offby1 |
UtahDave: are there simple concrete examples somewhere that I could look at? |
| 16:53 |
andrewclegg |
I could be wrong tho, it has all sorts of dark corners I've never tried |
| 16:54 |
offby1 |
andrewclegg: fair enough; thanks |
| 16:54 |
|
mesmer joined #salt |
| 16:54 |
UtahDave |
offby1: how do you want to do your code deployment? |
| 16:55 |
|
lacrymology joined #salt |
| 16:55 |
offby1 |
UtahDave: now, there's an open-ended question :-) Firstly I haven't even thought through _builds_, but anyway ... I'd like to have a list of machines which should be running my code, and I'd like to tell the deployment system "Please get version 0x12345 of my code running on those machines RIGHT NOW". |
| 16:55 |
offby1 |
and then when version 0x12345 turns out to be broken I'd like to be able to say "Please roll back to whatever was there previously, RIGHT NOT" |
| 16:55 |
offby1 |
*NOW |
| 16:56 |
|
dml_ joined #salt |
| 16:56 |
UtahDave |
offby1: OK, I have to get on a conference call in a couple minutes, but let me give you a quick rundown |
| 16:56 |
offby1 |
I suspect my deployment needs are the same as everyone else's, albeit perhaps on a smaller scale |
| 16:56 |
offby1 |
thanks |
| 16:56 |
UtahDave |
offby1: keep your code in git |
| 16:56 |
offby1 |
of course :) |
| 16:56 |
UtahDave |
use gitfs to back your salt master's file_roots |
| 16:56 |
offby1 |
I suspected as much. |
| 16:57 |
UtahDave |
your git master branch becomes your base environment in Salt. Other tags and branches become environments in Salt as well |
| 16:57 |
offby1 |
so I could deploy "staging" from a staging branch |
| 16:57 |
offby1 |
test it out |
| 16:57 |
offby1 |
promote it if I like it |
| 16:57 |
UtahDave |
yep |
| 16:57 |
offby1 |
thus avoiding the need for rollback |
| 16:57 |
UtahDave |
developer merges into "Testing" branch |
| 16:58 |
UtahDave |
QA team merges successful code into "staging" branch |
| 16:58 |
piffio |
forget my question, I'm stupid |
| 16:58 |
UtahDave |
finalj merge into master for production |
| 16:58 |
UtahDave |
revert production changes if disaster occurs |
| 16:59 |
offby1 |
UtahDave: sounds reasonable. How do you transform the git repository into a running service? I.e., what's the common way of handling builds? |
| 16:59 |
offby1 |
Or does that vary so much that there's no common way? |
| 16:59 |
UtahDave |
your highstates will target each environment on your infrastructure and execute the commands to deploy your code |
| 16:59 |
UtahDave |
offby1: that really depends on how your code works. |
| 16:59 |
* offby1 |
makes a note to read about "highstates" |
| 16:59 |
offby1 |
UtahDave: yeah, I know :-| |
| 17:00 |
offby1 |
mostly Python web apps |
| 17:00 |
|
whit joined #salt |
| 17:00 |
UtahDave |
is it php code that you can just copy into a directory? file.recurse |
| 17:00 |
offby1 |
nope |
| 17:00 |
UtahDave |
do you need to build an rpm or deb? |
| 17:00 |
offby1 |
some of which are pure python, but others of which have dependencies of native stuff like MySQL client library |
| 17:00 |
offby1 |
I don't _need_ to build a deb but I'm thinking I might do it anyway if it makes other things easier |
| 17:00 |
UtahDave |
then execute the salt commands to do that and then install that package |
| 17:01 |
UtahDave |
Salt can deploy your code pretty much any way you want or need to |
| 17:01 |
offby1 |
are you aware of any publicly viewable examples of this sort of thing? |
| 17:01 |
UtahDave |
offby1: yeah. |
| 17:01 |
UtahDave |
I really have to go now, but I'll be back in an hour or two. I'll try to find something for you then |
| 17:02 |
offby1 |
thanks! |
| 17:02 |
UtahDave |
Does anyone else in here have an example for offby1? |
| 17:02 |
|
KyleG left #salt |
| 17:02 |
offby1 |
In the meantime, my local Python user group seem to use salt too |
| 17:02 |
offby1 |
lessee what they can tell me |
| 17:02 |
|
lacrymology joined #salt |
| 17:05 |
piffio |
offby1: not sure this is what you're looking for |
| 17:05 |
piffio |
but I've recently started playing with salt |
| 17:05 |
offby1 |
piffio: do tell |
| 17:05 |
piffio |
and what I'm trying to achieve is to handle both configuration and deployments |
| 17:05 |
offby1 |
sounds like me too |
| 17:05 |
piffio |
first in a QA environment and then in production |
| 17:05 |
piffio |
right now I'm working on the QA side |
| 17:05 |
offby1 |
I need to, e.g., get Apache configured properly; then I need to get my code onto the box |
| 17:05 |
piffio |
yep |
| 17:05 |
|
pniederw joined #salt |
| 17:05 |
piffio |
we have a pretty "complex" and custom platform |
| 17:06 |
piffio |
100% linux based, and we build our own RPMs through jenkins, deploying in a repository |
| 17:06 |
piffio |
so, basically what I need to plug into salt is to handle these RPMs from the repository |
| 17:06 |
offby1 |
my case is simpler although as I said I will bite the bullet and build .debs if that makes everything else easier |
| 17:06 |
piffio |
using pkg.latest or something like this |
| 17:07 |
piffio |
the only thing that will not be handled is "rollback" |
| 17:07 |
piffio |
since - afaik - there is no easy way to downgrade an rpm from a yum repo to the previous version |
| 17:07 |
piffio |
also, I need to get dependencies right, in order to streamline the deployment process |
| 17:07 |
piffio |
I'd love to share some of my states with you if you need them |
| 17:07 |
piffio |
I'm working with gitfs as backend for my states |
| 17:08 |
miva |
Is there a way to define a pillar variable in two files and have them not overwrite each other, but append instead? https://gist.github.com/anonymous/02aded9018dc69518004 |
| 17:08 |
piffio |
offby1: but I'm still kind of at the beginning... for instance, I still get to understand when I want to use pillars and when I want to use states instead |
| 17:08 |
pniederw |
hi guys. I'm having troubles getting the most basic salt setup to work. anyone who can lend a hand? |
| 17:09 |
offby1 |
pniederw: I can cluck sympathetically |
| 17:09 |
piffio |
pniederw: can you describe your issue? |
| 17:10 |
pniederw |
I've set up a master and minion on a vagrant ubuntu vm, just to play and learn. |
| 17:10 |
|
Teknix joined #salt |
| 17:11 |
pniederw |
installation went fine, but I can't get test.ping to work reliably |
| 17:11 |
|
jdenning joined #salt |
| 17:11 |
pniederw |
works for a few seconds every time I restart master |
| 17:11 |
pniederw |
after that, any invocation to salt blocks for about ten seconds, then returns without any output |
| 17:11 |
|
micah_chatt left #salt |
| 17:11 |
* offby1 |
clucks sympathetically |
| 17:12 |
miva |
pniederw: if you run ps -ax |grep salt is there anything returned? |
| 17:12 |
piffio |
ah |
| 17:12 |
|
micah_chatt joined #salt |
| 17:12 |
piffio |
this is something that I've never encountered |
| 17:12 |
piffio |
my first suggestion |
| 17:12 |
piffio |
set log_level to debug in both master and minion |
| 17:12 |
pniederw |
yes, I see 9 master processes and 1 minion |
| 17:12 |
piffio |
and check the log files |
| 17:12 |
pniederw |
I've done that |
| 17:13 |
pniederw |
seems to execute the ping just fine |
| 17:13 |
pniederw |
(according to logs) |
| 17:13 |
|
mohae_ joined #salt |
| 17:13 |
miva |
pniederw: got ya, I had an issue when I was trying to get them running the daemon process would quit unexpectedlyââ¬Â¦which went away after a couple reboots and I haven't had the issue since, yours sounds different |
| 17:14 |
pniederw |
what I also see in the minion log is "Executing command saltutil.find_job" |
| 17:15 |
pniederw |
I don't know where this comes from. it appears about ten seconds after I've called test.ping, immediately before it returns (w/o any output) |
| 17:16 |
pniederw |
i.. I see "Executing command test.ping" immediately after issueing test.ping, then "Executing command saltutil.find_job" ten seconds later, then test.ping returns w/o output |
| 17:18 |
jcockhren |
micah_chatt: nice. I'll take a look once you put it up |
| 17:19 |
pniederw |
not sure where to go from here. maybe I should try w/ master and minion in separate vms. |
| 17:20 |
jcockhren |
pniederw: I have a gist for that |
| 17:20 |
jcockhren |
pniederw: long-story short. set up the vagrants in the private network |
| 17:20 |
|
gatoralli joined #salt |
| 17:21 |
pniederw |
can you post the link to the gist? |
| 17:21 |
|
jimallman joined #salt |
| 17:21 |
jcockhren |
https://gist.github.com/jcockhren/6606998 |
| 17:22 |
jcockhren |
pniederw: ^ |
| 17:22 |
jcockhren |
I guess... it means little if I don't include the minion and master configs |
| 17:24 |
pniederw |
"with salt provisioning" - does it mean I'll have to install salt on my physical machine? |
| 17:24 |
jcockhren |
nah. it installs it on the master |
| 17:24 |
jcockhren |
then uses the vagrant master to provision the vagrant minion |
| 17:25 |
jcockhren |
with that said, you'll need some salt states at the synced_folder |
| 17:25 |
pniederw |
ok, that sounds good. I'm new to all of this. |
| 17:25 |
pniederw |
dev goes ops, so to say. |
| 17:25 |
jcockhren |
:) |
| 17:26 |
|
bhosmer_ joined #salt |
| 17:26 |
jcockhren |
the minion config is gravy |
| 17:28 |
jcockhren |
set the master key to the private IP address of the vagrant master |
| 17:28 |
jcockhren |
OR |
| 17:28 |
seanz |
Hey everyone. I'm trying to put the pieces together and am ALMOST there...how would I run a command, like a2ensite, just once? |
| 17:28 |
jcockhren |
you can forgo all that and have it masterless |
| 17:28 |
jcockhren |
pniederw: ^ |
| 17:29 |
seanz |
I've got cmd.watch, which seems like an option. |
| 17:30 |
pniederw |
jcockhren: thanks, I'll give that a try. I do want to try with a master. |
| 17:31 |
|
cdsrv joined #salt |
| 17:32 |
|
cdsrv1 joined #salt |
| 17:32 |
|
Ryan_Lane joined #salt |
| 17:34 |
ldlework |
if I have an init.sls, how do I include the state next to it foobar.sls |
| 17:34 |
ldlework |
like I want main/init.sls to include main/foobar.sls so everything under main/ is installed when I apply the main state |
| 17:39 |
mohae_ |
ldlwork: include foobar |
| 17:39 |
|
avienu joined #salt |
| 17:40 |
mohae_ |
include: |
| 17:40 |
|
Gifflen joined #salt |
| 17:40 |
benspaulding |
ldlework: http://salt.readthedocs.org/en/latest/topics/tutorials/states_pt3.html#include-declaration |
| 17:40 |
mohae_ |
- foobar |
| 17:42 |
|
mohae_ joined #salt |
| 17:43 |
|
Gifflen_ joined #salt |
| 17:45 |
ldlework |
so doesn't foobar need a namespace |
| 17:45 |
ldlework |
like main.foobar ? |
| 17:45 |
mohae |
ldlwork, if its in your root, no |
| 17:45 |
mohae |
ldlwork: otherwise its - subdir.foobar |
| 17:45 |
mohae |
ldlwork: replace the / with . in the path |
| 17:46 |
mohae |
root = salt root |
| 17:46 |
ldlework |
mohae: so if as I described main/init.sls and main/foobar.sls, then init.sls would include main/foobar.sls with "include main.foobar" right? |
| 17:46 |
ldlework |
sorry if this is tautological |
| 17:46 |
mohae |
ldlwork: yes, I wasn't sure if main referred to a subdirectory in your question |
| 17:46 |
|
logix812 joined #salt |
| 17:47 |
ldlework |
thanks |
| 17:47 |
mohae |
ldlwork: but since its init.sls it should have been obvious to me that it was a subdirectory off of salt root, sorry it's Friday ;) |
| 17:48 |
mohae |
ldlwork, np, you can also refer to it from your top.sls the same way. depending on how you want it run |
| 17:48 |
ldlework |
mohae: trying to figure out how I can organize my sls files in the most refactored way |
| 17:48 |
mohae |
ldlwork: I understand...I'm still working on that |
| 17:48 |
ldlework |
mohae: any idea why "salt '*' test.ping" hangs around for like 30 seconds after its done pinging all the available servers? |
| 17:49 |
nu7hatch |
hmm, any idea why i'm getting "Function tls.create_self_signed_cert is not available" when calling salt-call? Has the module been removed/renamed? I'm running latest version of salt. |
| 17:49 |
|
troyready joined #salt |
| 17:49 |
mohae |
ldlework: sorry, I do not know |
| 17:51 |
ldlework |
mohae: I have /srv/salt/main/init.sls but calling "salt '*' state.main" says its not available |
| 17:52 |
|
redondos joined #salt |
| 17:52 |
|
hazzadous joined #salt |
| 17:52 |
|
baniir joined #salt |
| 17:53 |
mohae |
ldlwork: try "salt '*' state.sls main" |
| 17:54 |
|
jkleckner joined #salt |
| 17:55 |
|
micah_chatt joined #salt |
| 17:56 |
ldlework |
this is confusing :| |
| 17:57 |
mohae |
ldlework: what is? and what are you trying to accomplish? |
| 17:57 |
luminous |
hello! is it possible to call a salt state from a salt module? |
| 17:58 |
luminous |
eg, are __salt__['state.sls'] or state.highstate available? |
| 17:59 |
luminous |
ldlework: state.sls is a module.function, like state.highstate. so you are trying to call state.sls to apply your 'main' state |
| 18:00 |
ldlework |
I see |
| 18:00 |
ldlework |
mohae: http://hastebin.com/raw/wuqulogalo |
| 18:01 |
luminous |
ldlework: there are salt python modules, and there are python states, and then the .sls you are writing (commonly referred to as 'states') use salt's states )the python states), and these then in turn use the salt modules |
| 18:01 |
luminous |
it is confusing at first :) |
| 18:01 |
luminous |
but it'll all make sense over time |
| 18:02 |
ldlework |
yeah I have no idea what you just said |
| 18:02 |
ldlework |
but I apparently have a syntax error in python.sls |
| 18:02 |
luminous |
heh |
| 18:03 |
luminous |
you are writing sls which use these: https://salt.readthedocs.org/en/latest/ref/states/all/index.html and 'those' use these: https://salt.readthedocs.org/en/latest/ref/modules/all/index.html |
| 18:03 |
|
nu7hatch joined #salt |
| 18:03 |
|
lacrymology joined #salt |
| 18:04 |
mohae |
ldlework: so you are trying to test the iscape/init.sls or do a salt run that ends up installing the stuff in python.sls? Is this a master or standalone? |
| 18:06 |
|
ggoZ joined #salt |
| 18:07 |
|
KyleG1 joined #salt |
| 18:08 |
|
lacrymology joined #salt |
| 18:09 |
|
KyleG2 joined #salt |
| 18:11 |
ldlework |
mohae: its a master. I just want to test applying specific states to my minions |
| 18:11 |
|
KyleG joined #salt |
| 18:11 |
|
KyleG joined #salt |
| 18:12 |
|
mapu joined #salt |
| 18:13 |
|
jkleckner joined #salt |
| 18:13 |
ldlework |
nice it works |
| 18:13 |
ldlework |
yay |
| 18:13 |
mohae |
ldlwork: ic |
| 18:13 |
mohae |
grats |
| 18:14 |
piffio |
I have a question about ordering and dependencies |
| 18:14 |
mohae |
ldlework: btw, looking at your code, I'd recommend changing the id 'packages' to something else, like 'install_python' or something since IDs need to be unique |
| 18:14 |
piffio |
I need service X on host A do depend on changes (restart / upgrade / configuration) on service Y on host B |
| 18:15 |
piffio |
is there a way to express this with states? |
| 18:18 |
|
Gifflen joined #salt |
| 18:19 |
|
krissaxton joined #salt |
| 18:19 |
|
lacrymol1gy joined #salt |
| 18:23 |
|
berto- joined #salt |
| 18:25 |
|
zakm joined #salt |
| 18:25 |
ldlework |
mohae: interesting. I didn't realize I was creating a name there. I thought I was accessing some 'packages' module |
| 18:26 |
|
micah_chatt joined #salt |
| 18:26 |
|
mgw joined #salt |
| 18:26 |
zakm |
hey folks, is there to force pillars to support of overriding pillars? Example i have a "base" pillar that i include that contains say ntp/dns/mta settings for a given host (defaults if you will). then futher down the pillar definition i decide to override them |
| 18:27 |
zakm |
a quick test proved this didnt seem to work.. the initial included values were not overwritten |
| 18:27 |
mohae |
ldlework: ya, it took me longer than I'd admit to grok that too |
| 18:27 |
|
Teknix joined #salt |
| 18:27 |
zakm |
bah. is there a "way to support overriding of pillars"... |
| 18:29 |
|
hazzadous joined #salt |
| 18:29 |
|
nu7hatch joined #salt |
| 18:30 |
|
mnemonikk joined #salt |
| 18:30 |
ldlework |
mohae: does that name create an iscape.packages state? |
| 18:31 |
ldlework |
despite being in iscape/python.sls |
| 18:31 |
ldlework |
? |
| 18:31 |
ldlework |
or does it create a iscape.python.packages state |
| 18:31 |
mohae |
idlework: no, it creates a packages state id, which must be unique within your state tree |
| 18:33 |
mohae |
idlework the iscpate.python part is just the way paths are handled in the templates |
| 18:34 |
|
druonysuse joined #salt |
| 18:34 |
|
druonysuse joined #salt |
| 18:34 |
mohae |
idlework: so think of the state id as global to your salt tree, which can have other side affects if your reusing pillars and are using data from them to generate states. |
| 18:35 |
mohae |
*not sure if state id is the proper term there... |
| 18:40 |
nu7hatch |
hum, is there anything magic i have to install to enable file.copy module? It tells me that the function is not available o_O" |
| 18:44 |
|
mapu joined #salt |
| 18:50 |
|
mgw1 joined #salt |
| 18:51 |
|
kenbolton joined #salt |
| 18:57 |
|
SunSparc joined #salt |
| 18:58 |
|
redondos joined #salt |
| 18:59 |
|
mgw joined #salt |
| 18:59 |
|
KyleG joined #salt |
| 18:59 |
|
KyleG joined #salt |
| 18:59 |
|
jacksontj joined #salt |
| 19:00 |
|
mgw1 joined #salt |
| 19:01 |
ldlework |
mohae: is there a way to have this in an sls file without having to create a unique name? |
| 19:02 |
ldlework |
I have a number of files that start with pkg.installed and they all conflict |
| 19:03 |
UtahDave |
are the files named the same? |
| 19:03 |
ldlework |
no |
| 19:03 |
ldlework |
iscape/security.sls |
| 19:03 |
ldlework |
iscape/utilities.sls |
| 19:03 |
ldlework |
etc |
| 19:03 |
UtahDave |
can you pastebin an example of what you have so far? |
| 19:03 |
ldlework |
yeah |
| 19:06 |
ldlework |
UtahDave: http://hastebin.com/raw/toqogofaxo |
| 19:07 |
UtahDave |
Ah, ok |
| 19:07 |
UtahDave |
pkg.installed can't be the top level there. |
| 19:07 |
ldlework |
so I have to just make up arbitrary state names? |
| 19:07 |
UtahDave |
you need some kind of name on top. That's called the ID Declaration |
| 19:07 |
UtahDave |
so something like: |
| 19:07 |
ldlework |
:/ |
| 19:08 |
|
mgw joined #salt |
| 19:08 |
UtahDave |
python-pkgs: |
| 19:08 |
UtahDave |
pkg.installed: |
| 19:08 |
UtahDave |
- pkgs: |
| 19:08 |
UtahDave |
- python |
| 19:08 |
UtahDave |
- python-dev |
| 19:08 |
ldlework |
but what if I want a python-pkgs somewhere else? |
| 19:08 |
ldlework |
that it doesn't use the filesystem as a namespacing mechanism is kind of annoying |
| 19:08 |
|
VertigoRay joined #salt |
| 19:08 |
UtahDave |
also, when installing packages, use - pkgs instead of - names |
| 19:09 |
|
absolute joined #salt |
| 19:09 |
VertigoRay |
Hello! Anyone know where the salt-key code is? I seem some forks with it under salt/salt/cli, but I don't see the same key.py on saltstack/salt. |
| 19:09 |
UtahDave |
- pkgs will install all the packages with one call to the package manager. |
| 19:09 |
UtahDave |
- names will call the package manager once for each package |
| 19:09 |
ldlework |
UtahDave: I understand correctly that I cannot then use "python-pkgs" *anywhere else ANYWHERE* globally in any other sls file right? |
| 19:10 |
UtahDave |
Yes. that's correct. |
| 19:10 |
|
sgviking joined #salt |
| 19:10 |
UtahDave |
all the sls files get compiled into one huge python dict |
| 19:10 |
UtahDave |
dicts can't have duplicate keys |
| 19:14 |
VertigoRay |
absolute: Hi friend. |
| 19:14 |
|
eculver_ joined #salt |
| 19:15 |
absolute |
VertigoRay: oh hai Ray |
| 19:15 |
VertigoRay |
absolute: no ruby talk in this channel... k thx ;) |
| 19:19 |
|
devinus joined #salt |
| 19:21 |
|
eculver joined #salt |
| 19:21 |
|
cro joined #salt |
| 19:22 |
|
imaginarysteve joined #salt |
| 19:23 |
|
p3rror joined #salt |
| 19:24 |
|
kenbolton joined #salt |
| 19:26 |
|
micah_chatt joined #salt |
| 19:27 |
mohae |
ldlwork: sorry was afk...well the pkg.installed is fine, that's a state call |
| 19:27 |
mohae |
ldlework: its the ID that needs to be unique |
| 19:28 |
|
scristian joined #salt |
| 19:28 |
|
whit joined #salt |
| 19:28 |
ldlework |
mohae: right I didn't want to have to specify an ID for includes |
| 19:29 |
mohae |
ldlework: ya, I just caught up on my reading. |
| 19:29 |
|
bitz joined #salt |
| 19:31 |
mohae |
ldlework: well think of the state id as a function name...which means you can also include that state, using the ID, elsewhere, extend it, etc. |
| 19:31 |
|
cmthornton joined #salt |
| 19:36 |
ldlework |
so if I have main/sub/init.sls main/sub/foobar.sls, in sub/init.sls I have to import everything as - main.sub.foobar |
| 19:36 |
|
jslatts joined #salt |
| 19:36 |
ldlework |
that could get annoying for deeply organized state collections... |
| 19:38 |
ldlework |
nm I see relative imports, yay |
| 19:39 |
ldlework |
hmm not working.. |
| 19:39 |
|
sw joined #salt |
| 19:40 |
|
Gifflen joined #salt |
| 19:40 |
|
mgw joined #salt |
| 19:41 |
|
hazzadous_ joined #salt |
| 19:42 |
|
copelco joined #salt |
| 19:42 |
ldlework |
ah there we go |
| 19:42 |
mohae |
ldlework: grats |
| 19:45 |
|
Gifflen_ joined #salt |
| 19:47 |
|
Ryan_Lane joined #salt |
| 19:49 |
|
Sky__ joined #salt |
| 19:51 |
|
Gifflen joined #salt |
| 19:51 |
Sky__ |
So I'm a new user to salt... I've been looking through the docs and found many ways to send stuff from Master -> Minions, but is there a simple built in way to retrieve files from a minion -> master? |
| 19:51 |
|
cro joined #salt |
| 19:52 |
|
jpeach joined #salt |
| 19:56 |
Corey |
Sky__: Yes. cp.push |
| 19:58 |
|
backjlack joined #salt |
| 19:58 |
UtahDave |
micah_chatt: :) nice pull req! |
| 19:58 |
micah_chatt |
@UtahDave thanks! |
| 19:59 |
UtahDave |
tom thought that was freaking cool. :) |
| 19:59 |
micah_chatt |
thats great! I'm glad to hear it |
| 19:59 |
piffio |
UtahDave: hi! I might have another question for you |
| 19:59 |
piffio |
reading the documentation I can't find the answer I'm looking for |
| 20:00 |
micah_chatt |
UtahDave: I'll probably be making some updates to it, mostly validation checks: but I'm glad you all like it |
| 20:00 |
UtahDave |
very nice, micah_chatt |
| 20:00 |
|
m_george|away joined #salt |
| 20:00 |
UtahDave |
piffio: what are you trying to figure out. |
| 20:00 |
piffio |
I have an environment that's pretty complex |
| 20:00 |
|
m_george left #salt |
| 20:00 |
piffio |
and I have dependencies across different modules / servers |
| 20:01 |
piffio |
for instance, I need to upgrade package X on server A and then upgrade package Y on server B since this one depends on some configuration that it gathers from server A |
| 20:01 |
Sky__ |
thanks corey |
| 20:01 |
piffio |
is this something that's possible to achieve using states / requires? |
| 20:01 |
|
devinus joined #salt |
| 20:01 |
piffio |
or do I need to handle that at salt call, by first calling highstate on server A, then highstate on server B? |
| 20:01 |
Corey |
Sky__: No worries. |
| 20:02 |
piffio |
my goal is to come up with a "salt -N all-qa state.highstate" that does all the magic |
| 20:02 |
Sky__ |
err, who runs it though, master or minion? |
| 20:02 |
Corey |
Sky__: Minion, but I think you can spark it off from the master easily enough. |
| 20:03 |
piffio |
not sure if it's clear enough |
| 20:03 |
Sky__ |
ok cool thanks for the help. |
| 20:03 |
UtahDave |
piffio: you'll want to look at the overstate |
| 20:03 |
piffio |
what is overstate? |
| 20:03 |
piffio |
sounds uberpower |
| 20:03 |
piffio |
link? |
| 20:03 |
|
whit joined #salt |
| 20:03 |
piffio |
http://docs.saltstack.com/ref/states/overstate.html?highlight=overstate |
| 20:04 |
piffio |
found this, I'm reading |
| 20:04 |
piffio |
thanks |
| 20:04 |
piffio |
sounds exactly what I'm looking for |
| 20:04 |
piffio |
great |
| 20:04 |
UtahDave |
cool, piffio! |
| 20:06 |
|
littleidea joined #salt |
| 20:07 |
|
mapu joined #salt |
| 20:08 |
|
faldridge joined #salt |
| 20:12 |
|
higgs001 joined #salt |
| 20:13 |
|
cmthornton joined #salt |
| 20:15 |
jacksontj |
is there a nice way to dump a pillar structure into an sls file? i have a dict in pillar that i wand to pass directly to a state module but i'd rather not loop over all the data to generate yaml is there a "yaml dump"? |
| 20:17 |
|
Ryan_Lane1 joined #salt |
| 20:24 |
micah_chatt |
@UtahDave: is there a standard wan you all write tests for pillars? |
| 20:24 |
micah_chatt |
s/wan/way |
| 20:25 |
micah_chatt |
I didn't see any tests for pillars |
| 20:29 |
|
nu7hatch joined #salt |
| 20:30 |
|
czarneckid joined #salt |
| 20:33 |
StDiluted |
Does anyone have any code for adding a "This file is managed by SaltStack, do not edit" header to file.managed files? |
| 20:37 |
jesusaurus |
micah_chatt: testing formulae (and therein testing pillars) without just running a deploy and seeing what breaks in an unsolved problem |
| 20:37 |
jesusaurus |
im working on some hackish scripts to do just that, but its slow going |
| 20:38 |
micah_chatt |
jesusaurus: ok. I'm mostly asking for an ext_pillar I wrote |
| 20:39 |
jesusaurus |
micah_chatt: ahh, hmmm |
| 20:39 |
micah_chatt |
I mean, its a system integration thing. I COULD write a dummy django project with a sqlite db to test against |
| 20:40 |
micah_chatt |
and a salt state to create the test environment |
| 20:43 |
jesusaurus |
yeah, im not sure how to test that you have compiled a valid salt.pillar.Pillar object |
| 20:43 |
|
whit joined #salt |
| 20:44 |
|
krissaxton joined #salt |
| 20:45 |
jcockhren |
micah_chatt, jesusaurus: maybe create fixtures to simulate the cases you want to test? |
| 20:46 |
micah_chatt |
essentially, yea. The fixture being a django project |
| 20:46 |
jcockhren |
I mean fixtures within that project |
| 20:46 |
micah_chatt |
oh, yes. |
| 20:46 |
micah_chatt |
an hour ago |
| 20:46 |
micah_chatt |
*wrong channel |
| 20:48 |
jcockhren |
integration checks can be using pillar.items (forces recompile of pillars) |
| 20:49 |
jcockhren |
that's level 1 |
| 20:49 |
jcockhren |
then put expected data from the pillar |
| 20:49 |
jcockhren |
as level 2 |
| 20:49 |
|
jbunting joined #salt |
| 20:49 |
jcockhren |
I'm late to the convo, so you two may already be past this |
| 20:49 |
|
Ryan_Lane joined #salt |
| 20:50 |
|
higgs001 joined #salt |
| 20:51 |
|
tuxIO joined #salt |
| 20:52 |
jesusaurus |
is anyone here using log_granular_levels? is that supposed to be working? because I can't get it to make a difference |
| 20:58 |
|
bitz joined #salt |
| 20:59 |
|
redondos joined #salt |
| 20:59 |
|
CheKoLyN joined #salt |
| 21:04 |
|
jbunting joined #salt |
| 21:04 |
|
mgw joined #salt |
| 21:15 |
|
redondos joined #salt |
| 21:17 |
|
miva joined #salt |
| 21:17 |
|
Ryan_Lane joined #salt |
| 21:19 |
|
seanz joined #salt |
| 21:20 |
|
czarneckid joined #salt |
| 21:21 |
|
cmthornton joined #salt |
| 21:23 |
|
pdayton joined #salt |
| 21:42 |
|
emocakes joined #salt |
| 21:47 |
|
krissaxton joined #salt |
| 21:54 |
|
Linuturk joined #salt |
| 21:54 |
Linuturk |
so, anything exciting about the 0MQ 4 in regards to Salt? |
| 21:58 |
|
emocakes joined #salt |
| 22:01 |
whyzgeek |
hey guys I am trying to run a cmd after cloning a git repo. I added require and also tried watch. But it seems that it always tries to run the cmd too soon while the whole repo is not cloned. When I use require, it doesn't run it at all. It says a reuqirment file is not there. But in fact it is there after successful cloning. Any suggestions? |
| 22:01 |
Code_Bleu |
ok, maybe 3rd times a charm: what is the format for using USE flags in sls file? |
| 22:05 |
|
absolute joined #salt |
| 22:06 |
jesusaurus |
Code_Bleu: on gentoo? |
| 22:06 |
Code_Bleu |
jesusaurus: yes |
| 22:07 |
jesusaurus |
does http://docs.saltstack.com/ref/states/all/salt.states.portage_config.html#module-salt.states.portage_config not work? |
| 22:10 |
jcockhren |
whyzgeek: I think overstate could help with that |
| 22:11 |
jesusaurus |
whyzgeek: can you pastebin what you are trying? a watch should work fine |
| 22:12 |
Code_Bleu |
jesusaurus: i never fount that doc. Everything i found showed how to do it from the command line, but not how to config the sls file. This will prob work. Thanks! |
| 22:13 |
Code_Bleu |
s/fount/found/g |
| 22:13 |
|
hazzadous left #salt |
| 22:17 |
robawt |
aloah! |
| 22:17 |
robawt |
aloha even |
| 22:17 |
robawt |
I've got a directory that I want to set permissions to a specific user, but also download a git repo |
| 22:18 |
robawt |
how would I maintain ownership of the git repo and the directory? |
| 22:20 |
|
nu7hatch joined #salt |
| 22:33 |
whyzgeek |
jesusaurus: http://pastebin.com/h2iqQ5Sj |
| 22:33 |
whyzgeek |
jesusaurus: I read a bit about overstate, I couldn't figure out how that can help |
| 22:34 |
whyzgeek |
is there any sample for it? |
| 22:34 |
|
littleidea joined #salt |
| 22:34 |
|
jamiem_ joined #salt |
| 22:34 |
jesusaurus |
im not familiar with overstate myself |
| 22:35 |
jesusaurus |
but what I think you are missing is: http://pastebin.com/qur29yqk |
| 22:35 |
|
sixninetynine joined #salt |
| 22:36 |
jesusaurus |
that way the cmd will only run if the git repo changes |
| 22:36 |
jesusaurus |
whyzgeek: does that change make sense to you? |
| 22:37 |
whyzgeek |
jesusaurus: I already did try that |
| 22:37 |
whyzgeek |
didn't work and I had came up with this |
| 22:37 |
whyzgeek |
because it would fail in the middle |
| 22:38 |
jesusaurus |
did you blow away the git repo first? if the git repo doesnt change then the cmd wouldnt run |
| 22:38 |
whyzgeek |
and I couldn't figure out why |
| 22:38 |
jesusaurus |
fail in the middle? |
| 22:38 |
whyzgeek |
yes |
| 22:38 |
whyzgeek |
ya so it started doing the command while the repo was in the middle of cloning |
| 22:38 |
|
[diecast] joined #salt |
| 22:38 |
whyzgeek |
so the command wasn't working properly |
| 22:38 |
|
Damoun joined #salt |
| 22:38 |
whyzgeek |
and then we I changed to this |
| 22:39 |
whyzgeek |
I noticed it says that file is not there so it failed the requirments |
| 22:39 |
whyzgeek |
but cloning bit works fine |
| 22:39 |
whyzgeek |
everytime I tested I removed everything |
| 22:39 |
whyzgeek |
and started from scratch |
| 22:39 |
jesusaurus |
if the cmd started after the git started but before the git ended, that sounds like a bug |
| 22:40 |
whyzgeek |
I used watch before the require statement |
| 22:40 |
whyzgeek |
let me try puting it after |
| 22:40 |
whyzgeek |
I doubt it makes any change |
| 22:40 |
whyzgeek |
because its dictionary |
| 22:41 |
jesusaurus |
hold on, is the file you are requiring a file in the git repo? |
| 22:42 |
whyzgeek |
yes |
| 22:42 |
jesusaurus |
salt has no idea what files are in the repo, those dont exist as file resources within salt, you cant require/watch them |
| 22:42 |
whyzgeek |
ic |
| 22:42 |
jesusaurus |
you can only require/watch things that you define within salt |
| 22:42 |
whyzgeek |
I added that to ensure the checkout is complete |
| 22:42 |
whyzgeek |
because the watch itself |
| 22:43 |
whyzgeek |
wasn't doing the trick |
| 22:43 |
whyzgeek |
can I add a delay somehow |
| 22:43 |
whyzgeek |
to ensure we have the time problem? |
| 22:43 |
|
nu7hatch joined #salt |
| 22:44 |
jesusaurus |
salt is only going to perform one action at a time. it will not be doing anything else while cloning the repo |
| 22:45 |
whyzgeek |
jesusaurus: ic so I have to look somewhere else for the problem |
| 22:45 |
|
p3rror joined #salt |
| 22:47 |
jesusaurus |
well, if you try to require a "file", but never have a matching file.managed or file.exists or file.other_file_function, then salt will give an error that the file doesn't exist. which has absolutely nothing to do with the actual filesystem on disk |
| 22:49 |
whyzgeek |
jesusaurus: ya I got, so how can I do watch on existance of the file? |
| 22:49 |
jesusaurus |
in this case you should watch the git function, not a file function |
| 22:55 |
|
nu7hatch joined #salt |
| 23:18 |
|
GoKage joined #salt |
| 23:24 |
|
mwillhite joined #salt |
| 23:33 |
|
kermit joined #salt |
| 23:37 |
|
czarneckid joined #salt |
| 23:40 |
|
Ryan_Lane joined #salt |
| 23:46 |
|
mwillhite joined #salt |
| 23:52 |
|
littleidea joined #salt |
