Time |
Nick |
Message |
00:08 |
|
fxhp joined #salt |
00:08 |
|
glyf joined #salt |
00:11 |
|
bfoxwell joined #salt |
00:14 |
|
Kelsar joined #salt |
00:15 |
|
jdipierro joined #salt |
00:17 |
|
diegows joined #salt |
00:17 |
|
elfixit joined #salt |
00:22 |
|
kballou joined #salt |
00:23 |
|
TheThing joined #salt |
00:27 |
|
sunkist joined #salt |
00:37 |
|
atbell joined #salt |
00:42 |
|
jeffrubic joined #salt |
00:46 |
|
TheThing joined #salt |
00:50 |
|
davesque joined #salt |
01:03 |
|
yomilk joined #salt |
01:07 |
|
tjs joined #salt |
01:10 |
|
felskrone joined #salt |
01:12 |
|
ajolo joined #salt |
01:14 |
|
thawes joined #salt |
01:15 |
skyler_ |
Anyone know how to get a date in jinja? I want to embed the date in a file name for a file created by salt. |
01:15 |
|
glyf joined #salt |
01:16 |
|
atbell joined #salt |
01:18 |
|
druonysuse joined #salt |
01:18 |
|
druonysuse joined #salt |
01:20 |
|
forrest joined #salt |
01:22 |
|
thawes joined #salt |
01:22 |
|
forrest joined #salt |
01:25 |
|
aquinas joined #salt |
01:30 |
|
nitti joined #salt |
01:30 |
|
aquinas joined #salt |
01:36 |
dimeshake |
skyler_: you could use output of cmd.run 'date +whateverformatyouwant' |
01:38 |
dimeshake |
salt['cmd.run']('date ...') |
01:39 |
skyler_ |
dimeshake: Oh, that is a very good idea! Thanks, I didn't think of using {{ salt[...] }} for this. |
01:40 |
|
mpanetta_ joined #salt |
01:41 |
dimeshake |
i'm not sure it's a great idea, but it'll work :D |
02:01 |
moos3 |
skyler_: {{ datetime|strftime("%u") }} this would do your date |
02:01 |
dimeshake |
that's a much better idea |
02:01 |
moos3 |
anyone have ideas now how implements salts built in network module ? |
02:02 |
skyler_ |
moos3: thanks! |
02:02 |
moos3 |
more tricks at http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html |
02:02 |
moos3 |
now back to trying to figure how to manage network settings for minions |
02:17 |
|
aqua^mac joined #salt |
02:23 |
|
neogenix joined #salt |
02:26 |
|
foulou joined #salt |
02:31 |
|
jhauser_ joined #salt |
02:36 |
|
JlRd joined #salt |
02:38 |
|
bhosmer joined #salt |
02:47 |
|
xenoxaos joined #salt |
02:57 |
|
xenoxaos joined #salt |
02:57 |
|
mosen joined #salt |
03:14 |
|
aqua^mac_ joined #salt |
03:15 |
|
otter768 joined #salt |
03:17 |
|
holyzhou joined #salt |
03:18 |
|
yomilk_ joined #salt |
03:32 |
|
Mso150 joined #salt |
03:44 |
|
foulou joined #salt |
03:44 |
|
aquinas joined #salt |
03:49 |
|
thawes joined #salt |
03:52 |
|
Furao joined #salt |
03:54 |
|
aquinas joined #salt |
03:56 |
|
thawes joined #salt |
04:00 |
|
aquinas joined #salt |
04:06 |
|
thawes joined #salt |
04:08 |
|
vbabiy joined #salt |
04:12 |
|
capra_ibex joined #salt |
04:13 |
|
ajolo joined #salt |
04:14 |
|
_atbell_ joined #salt |
04:17 |
|
StDiluted joined #salt |
04:22 |
|
spookah joined #salt |
04:28 |
|
Leonw joined #salt |
04:31 |
|
pdayton joined #salt |
04:33 |
|
capra_ibex joined #salt |
04:40 |
|
viq joined #salt |
04:40 |
|
viq joined #salt |
04:42 |
|
capra_ibex joined #salt |
04:51 |
|
smcquay joined #salt |
05:02 |
|
Deevolution joined #salt |
05:07 |
|
Diaoul joined #salt |
05:16 |
|
otter768 joined #salt |
05:17 |
|
pdayton joined #salt |
05:21 |
|
jonbrefe joined #salt |
05:23 |
|
pdayton1 joined #salt |
05:53 |
|
malinoff joined #salt |
05:56 |
|
perfectsine joined #salt |
05:58 |
|
felskrone joined #salt |
05:59 |
|
perfectsine_ joined #salt |
05:59 |
|
StDiluted joined #salt |
06:19 |
|
yomilk joined #salt |
06:19 |
|
jalbretsen joined #salt |
06:23 |
|
Damon joined #salt |
06:28 |
|
schlueter joined #salt |
06:40 |
|
bhosmer joined #salt |
06:41 |
|
NightMonkey joined #salt |
06:45 |
|
repl1can1 joined #salt |
06:45 |
|
catpiggest joined #salt |
06:52 |
|
atbell joined #salt |
07:05 |
|
ttrumm joined #salt |
07:07 |
holyzhou |
why i thought , file.replace so hard to use |
07:10 |
Furao |
use file.managed |
07:11 |
Furao |
you’ll be sure of the results |
07:12 |
holyzhou |
hmm , i want to change line "#master: salt" to "master: {{ pillar['master_name']['ip'] }}" , how can i write |
07:13 |
|
felskrone joined #salt |
07:14 |
Furao |
holyzhou: https://github.com/bclermont/states/tree/master/states/salt/minion |
07:14 |
Furao |
https://github.com/bclermont/states/blob/master/states/salt/minion/init.sls#L18 and https://github.com/bclermont/states/blob/master/states/salt/minion/config.jinja2#L5 |
07:15 |
Furao |
this is 2 years old, we’re not doing it exactly like that today but it can help you understand |
07:16 |
|
ThomasJ joined #salt |
07:17 |
|
pdayton joined #salt |
07:17 |
|
otter768 joined #salt |
07:18 |
|
pdayton joined #salt |
07:27 |
|
techdragon joined #salt |
07:33 |
|
repl1can1 joined #salt |
07:40 |
|
maxd_ joined #salt |
07:46 |
|
pdayton joined #salt |
07:51 |
|
trikke joined #salt |
07:52 |
|
techdragon joined #salt |
08:05 |
|
ttrumm joined #salt |
08:12 |
|
Auroch joined #salt |
08:27 |
|
fredvd joined #salt |
08:30 |
|
techdragon joined #salt |
08:33 |
|
noway__ joined #salt |
08:42 |
|
Mso150 joined #salt |
08:44 |
|
kawa2014 joined #salt |
08:45 |
|
jimmy_ joined #salt |
08:48 |
|
yomilk joined #salt |
08:56 |
|
karimb joined #salt |
08:57 |
rbjorklin |
I'm getting 'Data failed to compile': State 'blah' in SLS 'name' is not formed as a list |
08:57 |
rbjorklin |
Is there a better way to debug than running salt-call -l debug locally? |
08:59 |
babilen |
rbjorklin: Take a look at stable blah in sls name and use a yaml parser to verify what kind of datastructure you have there. What would "debugging" entail? The bug is clear (hence the error message), but you might not know *what* you have instead (or *why* you have it) |
09:00 |
babilen |
http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#salt.modules.state.show_sls might come in handy for that |
09:01 |
|
techdragon joined #salt |
09:01 |
babilen |
Feel free to paste it to http://refheap.com if you want us to take a look |
09:07 |
rbjorklin |
babilen: Thanks! The show_sls made it clear to me that it couldn't find the state. Took a closer look at /etc/salt/master and found a spelling mistake in the file_roots section |
09:08 |
|
kawa2014 joined #salt |
09:11 |
|
yomilk joined #salt |
09:12 |
|
rtuin joined #salt |
09:12 |
babilen |
+1 |
09:12 |
|
CeBe joined #salt |
09:17 |
|
hebz0rl joined #salt |
09:18 |
|
otter768 joined #salt |
09:18 |
|
CeBe1 joined #salt |
09:35 |
|
pttc joined #salt |
09:36 |
|
N-Mi joined #salt |
09:39 |
|
maxd joined #salt |
10:03 |
|
jasonrm joined #salt |
10:07 |
|
yomilk joined #salt |
10:20 |
|
frvge joined #salt |
10:25 |
|
giantlock joined #salt |
10:26 |
|
badon_ joined #salt |
10:35 |
|
che-arne joined #salt |
10:43 |
|
zorrba joined #salt |
10:45 |
|
smoothify joined #salt |
10:50 |
|
workingcats joined #salt |
10:51 |
|
hotsnow joined #salt |
10:57 |
VSpike |
With PCRE Minion ID compound match, is it possible to make references to capture groups in the YAML? |
10:58 |
VSpike |
Something like https://bpaste.net/show/6d66e1fa636e (made-up syntax) |
10:59 |
VSpike |
I suppose you can achieve the same with Jinja |
11:00 |
babilen |
Or "just" write it in Python |
11:00 |
babilen |
(bit tricky in jinja though) |
11:00 |
|
slafs joined #salt |
11:01 |
|
slafs left #salt |
11:03 |
VSpike |
Slight red herring, but can someone define "high state" and "low state" for me? Or link to something which does? |
11:04 |
VSpike |
babilen: you mean using the python renderer? |
11:04 |
babilen |
yeah |
11:04 |
|
Mindfart joined #salt |
11:05 |
babilen |
"import re" + logic is one of the more frequent reasons why I don't use jinja |
11:05 |
|
CeBe joined #salt |
11:05 |
VSpike |
Hm, haven't dipped my toe into that pool yet but this might be a good use case. Is it much different for a top file compared to a normal state file? |
11:06 |
babilen |
Pity that you can't do that easily in jinja. The alternative would be to write an execution module that you call from jinja for the "parsing" code and then use the returned data in jinja states. |
11:06 |
VSpike |
I imagine it's still just a matter of buildign and returning a data structure |
11:06 |
babilen |
The problem is that you cannot easily call functions in the re module in jinja. |
11:07 |
babilen |
jinja simply isn't powerful enough and doesn't allow you to include Python blocks like mako does |
11:08 |
babilen |
(which is why it wasn't a good choice IMHO) |
11:08 |
pttc |
django has taught me that when you start needing advanced logic from your templating language, you've gone wrong somewhere |
11:09 |
babilen |
pttc: Yes, but that assumes that you have a backend in which you *can* perform the logic. |
11:10 |
babilen |
In salt you will always have to use a different renderer than jinja for that as there is no explicit backend (unless you start writing pillars in Python or your own State/Execution Modules) |
11:11 |
babilen |
As SLS files are the primary interface in which users express their logic (both for data and for actions) choosing jinja was a bad idea |
11:11 |
VSpike |
I'm still confused a bit by the compound matching syntax. Here's an example I've seen 'L foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com' ... |
11:12 |
pttc |
could be. I'm surprised that dropping down into python to do more complex things isn't widely adopted though? why |
11:12 |
VSpike |
Would this not be valid? 'L foo.domain.com,bar.domain.com,baz.domain.com,bl*.domain.com' |
11:12 |
VSpike |
What about 'foo.domain.com or bar.domain.com or baz.domain.com or bl*.domain.com' |
11:12 |
pttc |
i havn't gotten into that part of salt yet really so I'm not sure |
11:13 |
|
fredvd joined #salt |
11:16 |
|
kawa2014 joined #salt |
11:16 |
babilen |
pttc: I do a lot of things in Python, but it is a shame that you have to do that as soon as you need "a bit" more logic. |
11:17 |
babilen |
VSpike: The commas in there look weird, but let me verify |
11:17 |
pttc |
yeah, I guess using dictionaries in a template can be annoying |
11:18 |
babilen |
A little, but there are so many things that are trivial if you can just use a bit of Python. (e.g. itertools for combining data into pairs (for cycling through servers, ...)) |
11:18 |
VSpike |
Also, is there a list anywhere of the match types permitted as in http://docs.saltstack.com/en/latest/ref/states/top.html#other-ways-of-targeting-minions ? e.g. pcre, grain, grain_pcre, list, pillar, compound, ... ? |
11:18 |
|
CeBe joined #salt |
11:19 |
babilen |
http://docs.saltstack.com/en/latest/topics/targeting/ |
11:19 |
|
otter768 joined #salt |
11:19 |
VSpike |
babilen: I don't think that has a list |
11:20 |
babilen |
No, but it's the best you get. |
11:20 |
VSpike |
:) |
11:20 |
VSpike |
dammit |
11:20 |
babilen |
There might be something in the code |
11:20 |
VSpike |
yeah, that's usually my next step |
11:21 |
babilen |
http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.match.html |
11:22 |
|
xsteadfastx joined #salt |
11:22 |
babilen |
(and https://github.com/saltstack/salt/blob/develop/salt/modules/match.py ) |
11:23 |
VSpike |
Oh, good find! Ta |
11:24 |
VSpike |
Another question ... can you split a top.sls file up by including multiple files? |
11:26 |
VSpike |
Or if your top becomes that complex, would it be reasonable to do a very high-level slice (by data centre or something) in the top.sls file and hand off to a regular SLS that uses Jinja or Python to do more complex matching |
11:26 |
VSpike |
Hm. Perhaps I'm re-inventing the environment system |
11:34 |
|
blaffoy joined #salt |
11:35 |
rbjorklin |
Not sure if I'm getting the Requisites right. If I have a state B that has onchanges_in: service: A that should trigger A when I change B right? |
11:36 |
|
agend joined #salt |
11:37 |
|
bhosmer joined #salt |
11:38 |
|
jeffrubic joined #salt |
11:40 |
|
peters-tx joined #salt |
11:41 |
blaffoy |
Hey! I've more n00b questions if somebody could help me? I'm trying to install and run nginx on Ubuntu. I'd like for the nginx service to restart if the file /etc/nginx/nginx.conf changes, but I hit a problem "The following requisites were not found: watch: file: /etc/nginx/nginx.conf". This is my sls: https://gist.github.com/anonymous/53cb450a91733912b769 |
11:41 |
blaffoy |
This question (http://stackoverflow.com/questions/23716009/saltstack-in-a-watch-statement-how-do-i-specify-a-directory-where-all-files-sh) seems to be about exactly the same thing, but I've copied the sls from the answer to no avail. |
11:41 |
|
CeBe joined #salt |
11:42 |
blaffoy |
From reading around, I think that the file /etc/nginx/nginx.conf needs to be managed by salt before it can be used in a watch statement. |
11:42 |
|
lothiraldan joined #salt |
11:42 |
blaffoy |
But I'm not sure how to achieve that. |
11:45 |
|
yomilk joined #salt |
11:49 |
|
diegows joined #salt |
11:49 |
VSpike |
I don't really _get_ environments. The docs talk a lot about how to define the file roots, how the exact rules for top files and other files work between them and here http://docs.saltstack.com/en/latest/topics/tutorials/states_pt4.html it shows how you can select the env for a file.recurse call |
11:50 |
VSpike |
But since you can include states in an enviroment, when doing a salt 'web1' state.highstate how would you specify which environment you want the states to come from? |
11:55 |
rbjorklin |
salt 'web1' state.highstate saltenv=env2 |
11:55 |
rbjorklin |
VSpike: ^ |
11:56 |
|
rtuin joined #salt |
11:56 |
VSpike |
aha. Thanks! |
11:56 |
VSpike |
Is there any way to match machines to enviroments automatically? |
11:57 |
VSpike |
Hm, I suppose that's done by only having a match for that machine within that environment in the top file(s) |
11:57 |
rbjorklin |
VSpike: Not that I know of but I'm new to this as well. I use node groups |
11:57 |
rbjorklin |
salt -N 'machines_in_env2' state.highstate saltenv=env2 |
11:57 |
VSpike |
Yeah, I just spotted those a few minutes ago too... was trying to figure out the best way to join all this together |
11:58 |
Twiglet |
We have an environment grain then just match 'G role:blah and G environment:production': \n - match: compound \n - stuff |
11:59 |
|
ggoZ joined #salt |
11:59 |
VSpike |
That would make babilen sad |
12:01 |
Twiglet |
Why? Ease of targeting is one of Salt's best features |
12:01 |
malinoff |
Twiglet, because you should use pillars for roles and environments |
12:02 |
malinoff |
grain can be set by anyone accidentally |
12:03 |
|
N-Mi joined #salt |
12:03 |
Twiglet |
Our grains are set by salt-cloud, don't even have ssh on our machines |
12:04 |
Twiglet |
If soemone is changing grains via Salt we have bigger issues |
12:04 |
malinoff |
it is acceptable in your particular case, but using pillars is a general advice |
12:04 |
babilen |
The problem with using pillars is that you cannot use them to target pillars (as they can't reference themselves) |
12:04 |
Twiglet |
I can maybe agree with the role being defined by the pillar for sure but environment for us is as static as any other system data |
12:05 |
babilen |
There simply is no decent option as salt does, as of now, offer no way to define static data that is available *everywhere* and is under the control of the master. |
12:05 |
Twiglet |
Thats what we found |
12:05 |
VSpike |
I was wondering about using ipcidr matching for environments, since there's a mostly 1:1 (but not quite) mapping |
12:06 |
Twiglet |
Which is why we went with grains given our setup |
12:06 |
Twiglet |
Without writing an ENC it's the best option for us atm |
12:06 |
VSpike |
I'm trying to stick to only using minion id as the one true decider though |
12:06 |
babilen |
Twiglet: My argument against grains is essentially that you shouldn't rely on data provided by the entity for which you are deciding which data to make available to it. It is a bit like asking: "Hmm, do you want $SECRET?" .. "Uh, I guess!" |
12:07 |
Twiglet |
Very true |
12:07 |
VSpike |
If everyone in my org would just shut up and adopt my brilliant naming scheme, everything would be golden |
12:07 |
babilen |
VSpike: Indeed -- Same here and I even drew ASCII Art to document it! ;) |
12:08 |
VSpike |
heh :) I would *never* fight a proposal that included ASCII art. |
12:08 |
VSpike |
Perhaps you need to add some graphs from http://xkcdgraphs.com/ too |
12:14 |
|
jonatas_oliveira joined #salt |
12:27 |
|
bhosmer joined #salt |
12:33 |
ktosiek |
babilen: isn't it possible to target pillars with L@? |
12:33 |
ktosiek |
(or even better: node groups) |
12:35 |
ktosiek |
then you'd be able to say who can see which pillar without depending on grains, right? |
12:35 |
* ktosiek |
is new here, and not really sure if that makes sense :-) |
12:37 |
|
user joined #salt |
12:38 |
pttc |
anyone know why my failover may not be working? I've set `master_type: failover` and put a random string that I know won't resolve first, and "localhost" second. and I just get a message saying no minion response |
12:38 |
pttc |
I know localhost works on its own, but doesn't seem to work when the first one fails |
12:41 |
user |
Howdy. Is it possible to tell a salt-minor to reset his minor_id and minor-key remotly? |
12:45 |
|
clone1018_ joined #salt |
12:45 |
rbjorklin |
I'm having trouble's with onchanges_in http://pastebin.com/DW1fWjTs :w |
12:45 |
|
iggy joined #salt |
12:46 |
|
muebel joined #salt |
12:46 |
|
FRANK_T joined #salt |
12:46 |
|
tempspace joined #salt |
12:46 |
|
tedski joined #salt |
12:46 |
|
beardo joined #salt |
12:47 |
rbjorklin |
http://pastebin.com/DQBp1XsD |
12:47 |
mindfab |
user: You could delete the key folder and restart the minion |
12:47 |
|
dork joined #salt |
12:47 |
|
MTecknology joined #salt |
12:47 |
|
Guest89819 joined #salt |
12:48 |
|
robinsmidsrod joined #salt |
12:48 |
|
egalano joined #salt |
12:49 |
|
lothiraldan joined #salt |
12:50 |
mindfab |
I have problems in upgrading my salt-minions from different versions (e.g. 0.17.5 and 2014.0.10 all from launchpad) to the 2014.7.0 version... a find call fails "find: "/usr/lib/python2.7/dist-packages/salt/" is this just a launchpad version issue (backport issue to Ubuntu 12.04) ?? |
12:50 |
mindfab |
btw. can be easily workaround by creating the salt directory under dist-packages folder |
12:51 |
|
aqua^mac joined #salt |
12:52 |
user |
mindfab: thx for the answer. When I delete the minion_id and minion-key with salt <target> cmd.run 'del ..' the command hangs. I guess I cant do this remotely |
12:53 |
mindfab |
user: not sure what you want to do... i would do operations like that via ssh... it cannot work with salt itself (most probably) |
12:53 |
rbjorklin |
I'm starting to think onchanges_in is broken or not working according to what the documentation states. Could someone help me clear it up? |
12:59 |
rbjorklin |
these are my two state files where I'm having problems with onchanges_in http://pastebin.com/DQBp1XsD http://pastebin.com/DW1fWjTs |
12:59 |
user |
mindfab: ok I thought so. Short background: I try to distribut a windows image with salt-minoion installed to multiple PCs. I think its the best when I delete the minion_id and key every time before I distribute the image to the other PCs ^^ |
13:02 |
mindfab |
I was also struggling with minion_ids/keys and virtual machines with vagrant these days... have a look at my solution, maybe it helps https://github.com/RobertFach/vagrant-dev-vm-reactor |
13:04 |
mindfab |
user: anyway, i usually delete the keys and/or upgrade salt-minion in a bootstrap script or provisioner that comes with the vm... that means, this is the only step that is done outside of salt |
13:06 |
mindfab |
user: what provider and provisioner do you use for your vms? |
13:08 |
|
lothiraldan joined #salt |
13:09 |
user |
mindfab: wow very nice I will have a look. |
13:10 |
rbjorklin |
If I use onchanges for more that one other state does all have to change for it to trigger or is one enough? |
13:10 |
user |
mindfab: not sure what provisioner means.. maybe my english is to bad. But this arent vms. This are PCs for a pool room |
13:11 |
user |
I juse fog to distribute |
13:11 |
user |
-j |
13:11 |
|
sxar joined #salt |
13:12 |
mindfab |
user: maybe than pre-seeding is the right way to go |
13:12 |
|
lothiraldan joined #salt |
13:13 |
mindfab |
user: pre-seeding the keys on salt master http://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html and distributing the correct keys with fog, you also have to set the minion_id correctly via fog |
13:14 |
user |
mindfab: ok thanks I will read about pre-seeding |
13:15 |
mindfab |
user: preseeding can be used if you know the minion_ids a priori ... |
13:16 |
user |
mindfab: all right this should work then :-) |
13:16 |
user |
mindfab: thank you so much |
13:18 |
mindfab |
user: youre welcome |
13:18 |
|
CeBe joined #salt |
13:20 |
|
nbari joined #salt |
13:20 |
|
otter768 joined #salt |
13:20 |
nbari |
hi all, how to create a salt state using daemontools that can restart an service |
13:21 |
nbari |
on cli mode I can use something like salt '*' daemontools.start <service name> but how to do the same on an .sls ? |
13:27 |
mindfab |
hi, is there anybody here who manages the launchpad packages for salt for ubuntu ? |
13:30 |
|
evidence joined #salt |
13:31 |
|
rogst joined #salt |
13:31 |
|
aqua^mac joined #salt |
13:31 |
|
s51itxsyc joined #salt |
13:34 |
|
mikkn joined #salt |
13:44 |
|
monkey661 joined #salt |
13:48 |
|
lothiraldan joined #salt |
13:50 |
|
bmonty joined #salt |
13:51 |
rbjorklin |
Has anyone gotten onchanges_in to work? If not I'm on the verge of filing a bug |
13:53 |
rbjorklin |
watch_in seems to work just as intended while I haven't been able to get onchanges_in to work at all |
13:54 |
|
cpowell joined #salt |
13:56 |
mindfab |
rbjorklin: let me have a look at it ... |
13:57 |
|
gngsk joined #salt |
13:59 |
|
lothiraldan joined #salt |
14:00 |
|
yomilk joined #salt |
14:05 |
|
pdayton joined #salt |
14:06 |
|
cpowell joined #salt |
14:07 |
|
yano joined #salt |
14:08 |
|
teebes joined #salt |
14:08 |
VSpike |
mindfab: I think joehh1 does |
14:14 |
|
ajolo joined #salt |
14:15 |
|
nitti joined #salt |
14:16 |
|
thawes joined #salt |
14:17 |
|
goal joined #salt |
14:20 |
mindfab |
VSpike: i opened an issue in github ... this should also work |
14:22 |
|
pdayton joined #salt |
14:23 |
|
racooper joined #salt |
14:24 |
|
goal joined #salt |
14:26 |
SneakyPhil |
I'm confused about how to run a salt query. I am trying to get 2 grains from all machines that match a different grain |
14:27 |
Rory |
SneakyPhil: Let's say you want the grains "foo" and "bar" from all machines with a "os" grain value of "linux" |
14:27 |
SneakyPhil |
salt -G 'osarch:x86_64 or osarch:amd64' grains.item kernelrelease uptime |
14:27 |
SneakyPhil |
Rory: basically, yes |
14:28 |
SneakyPhil |
I don't think the -G can do compound statements |
14:28 |
Rory |
SneakyPhil: That looks correct, how does its output differ from your expectations |
14:28 |
Rory |
SneakyPhil: No, but the -C can |
14:28 |
Rory |
SneakyPhil: -C 'G osarch:... |
14:28 |
SneakyPhil |
ahhhhh the G goes there |
14:28 |
Rory |
SneakyPhil: Sorry I missed that |
14:28 |
SneakyPhil |
me too |
14:28 |
Rory |
SneakyPhil: Yep :) |
14:28 |
SneakyPhil |
1st actual morning at this |
14:28 |
SneakyPhil |
set it up yesterday to do some patching |
14:28 |
SneakyPhil |
thanks |
14:29 |
Rory |
np |
14:30 |
|
goal joined #salt |
14:32 |
|
lothiraldan joined #salt |
14:32 |
VSpike |
I'm still not getting this, I don't think. Can you assign a machine to an environment in the top file like this? https://bpaste.net/show/f550577c13c3 |
14:32 |
|
yomilk joined #salt |
14:33 |
VSpike |
Does that even have a meaning? Can does a machine belong to an environment, or is the env global to the current running function? |
14:33 |
mindfab |
VSpike: yes you can, i assign my machines based on minion_id |
14:35 |
VSpike |
mindfab: OK. So you could acually also do https://bpaste.net/show/13e9a7ce44f7 and have different FS roots for each env and allow the overlaying of states and pillars to do the work? |
14:36 |
VSpike |
mindfab: another question - is the env for the pillar related to the env for the states? |
14:36 |
mindfab |
at least overlays in fs works |
14:36 |
mindfab |
like that ... mom |
14:37 |
|
thawes joined #salt |
14:38 |
|
_JZ_ joined #salt |
14:39 |
moos3 |
anyone around using centos/rhel and using salt to control their networking ? |
14:40 |
mindfab |
VSpike: https://bpaste.net/show/03809a83595c |
14:41 |
mindfab |
VSpike: this is what I do in a production setup for managing different env for dev. projects |
14:41 |
mindfab |
i think this kind of overlay should also work with pillar data |
14:43 |
VSpike |
If you want to use the same environments on pillar and states, do you need to assign it in both? |
14:45 |
VSpike |
perhaps to save duplicating data, your pillar could assign a pillar value of "environment" as well as then "role", and then your state's top.sls could just select on env + role |
14:45 |
VSpike |
s/data/rules |
14:46 |
|
yano left #salt |
14:46 |
|
lothiraldan joined #salt |
14:49 |
mindfab |
VSpike: if you would assign pillars based on pillar top.sls, then you also have to define the mapping to your pillar data... however, both is independent of each other... you can have overlays in fs but not in pillar... |
14:51 |
|
schlueter joined #salt |
14:52 |
mindfab |
VSpike: as far as i know you cannot assign envs based on pillar data |
14:52 |
|
monkey661 left #salt |
14:52 |
|
schlueter1 joined #salt |
14:53 |
|
agend joined #salt |
14:53 |
|
agend_ joined #salt |
14:54 |
|
agend joined #salt |
14:55 |
VSpike |
mindfab: you can merge in pillar though, as long as you avoid key name clashes |
14:55 |
|
agend_ joined #salt |
14:55 |
|
agend joined #salt |
14:58 |
|
hasues joined #salt |
14:58 |
|
housl joined #salt |
14:59 |
|
CeBe joined #salt |
14:59 |
VSpike |
mindfab: couldn't you do someting like test: |
14:59 |
VSpike |
'environment:test': |
14:59 |
VSpike |
- match: pillar |
14:59 |
VSpike |
sorry... https://bpaste.net/show/7369a51f7a5f |
15:01 |
|
mapu joined #salt |
15:02 |
|
ggoZ joined #salt |
15:03 |
|
bmonty left #salt |
15:06 |
|
funzo_ joined #salt |
15:07 |
mindfab |
VSpike: i dont know ... have you tried that? i think it depends on if the pillar data gets assigned before the actual top.sls of fs root gets evaluated |
15:08 |
mindfab |
VSpike: let me know if this works :) |
15:17 |
|
alainv joined #salt |
15:17 |
|
msciciel joined #salt |
15:19 |
|
hasues joined #salt |
15:19 |
|
hasues left #salt |
15:21 |
|
otter768 joined #salt |
15:22 |
|
aqua^mac joined #salt |
15:27 |
|
ajolo joined #salt |
15:29 |
|
smoothify joined #salt |
15:32 |
|
victor- joined #salt |
15:32 |
iggy |
you can use pillar matches in state top files, but not in pillar top files |
15:35 |
|
aqua^mac joined #salt |
15:35 |
|
thawes joined #salt |
15:38 |
|
rojem joined #salt |
15:38 |
|
jaimed joined #salt |
15:42 |
|
lothiraldan joined #salt |
15:46 |
|
rtuin_ joined #salt |
15:48 |
|
nitti_ joined #salt |
15:53 |
|
jtanner_ joined #salt |
15:53 |
|
Auroch joined #salt |
15:54 |
|
lothiraldan joined #salt |
15:56 |
|
glyf joined #salt |
15:56 |
|
seanz joined #salt |
15:57 |
|
user left #salt |
15:59 |
|
pdayton joined #salt |
16:00 |
|
jtanner joined #salt |
16:01 |
|
Furao joined #salt |
16:01 |
|
KennethWilke joined #salt |
16:02 |
|
otter768 joined #salt |
16:02 |
|
blaffoy joined #salt |
16:02 |
|
mpanetta joined #salt |
16:03 |
|
mpanetta joined #salt |
16:04 |
|
rojem joined #salt |
16:06 |
|
Corey joined #salt |
16:08 |
|
rtuin joined #salt |
16:10 |
|
smoothify joined #salt |
16:11 |
|
kermit joined #salt |
16:12 |
|
elfixit joined #salt |
16:14 |
|
spiette joined #salt |
16:19 |
|
jonbrefe joined #salt |
16:20 |
|
smoothify joined #salt |
16:22 |
|
viq joined #salt |
16:27 |
|
prometheus joined #salt |
16:32 |
|
Ozack joined #salt |
16:33 |
|
jonbrefe1 joined #salt |
16:33 |
|
jonbrefe1 joined #salt |
16:34 |
|
kaptk2 joined #salt |
16:38 |
|
maxd joined #salt |
16:39 |
|
davesque joined #salt |
16:43 |
|
faust joined #salt |
16:43 |
|
thedodd joined #salt |
16:45 |
|
doriftoshoes joined #salt |
16:45 |
blaffoy |
Hey all! Could somebody explain to me how inter-sls dependencies are evaluated and applied? Say I have two states, foo.sls, and bar.sls. foo.sls contains a clause like "file.managed:\n - require:\n - sls: bar", so foo requires bar. Now, if foo is applied to my minion in my top file or by "salt-call state.sls foo", it will error with "the following requisites were not found: require: bar" |
16:45 |
blaffoy |
This makes sense to me |
16:46 |
blaffoy |
What I want to know, is if there is anyway to apply the state foo without manually specifying bar? To automatically apply all requisite states? |
16:47 |
mpanetta |
You would have to include bar in foo |
16:47 |
mpanetta |
To satisfy the req |
16:47 |
blaffoy |
Right. Include. |
16:49 |
blaffoy |
That's good to know. I wasn't finding anything in the docs when reading about requirements. |
16:53 |
|
pdayton joined #salt |
16:54 |
|
lothiraldan joined #salt |
17:00 |
|
zadock joined #salt |
17:00 |
|
Emantor joined #salt |
17:01 |
|
mitsuhiko joined #salt |
17:02 |
|
neogenix joined #salt |
17:03 |
|
monkey66 joined #salt |
17:04 |
|
glyf joined #salt |
17:10 |
SneakyPhil |
has anyone else seen this https://hveem.no/vm-monitoring-using-salt-and-cubism |
17:11 |
|
StDiluted joined #salt |
17:13 |
geekatcmu |
Nope, no one has see that before now. |
17:15 |
|
maxd joined #salt |
17:16 |
|
StDiluted joined #salt |
17:16 |
|
pdayton joined #salt |
17:17 |
|
mapu joined #salt |
17:17 |
|
RedundancyD joined #salt |
17:18 |
|
zlhgo joined #salt |
17:19 |
|
murrdoc joined #salt |
17:21 |
|
Emantor joined #salt |
17:23 |
|
andrew_v joined #salt |
17:24 |
|
andrew_v left #salt |
17:25 |
|
Corey joined #salt |
17:26 |
|
aqua^mac joined #salt |
17:27 |
|
pdayton joined #salt |
17:28 |
|
ggoZ joined #salt |
17:30 |
|
pdayton joined #salt |
17:31 |
|
Emantor joined #salt |
17:31 |
|
forrest joined #salt |
17:31 |
|
hal58th joined #salt |
17:33 |
|
viq joined #salt |
17:34 |
|
andrew_v joined #salt |
17:39 |
|
CheKoLyN joined #salt |
17:40 |
|
gngsk joined #salt |
17:40 |
|
andrew_v joined #salt |
17:48 |
|
spookah joined #salt |
17:49 |
|
schlueter joined #salt |
17:49 |
|
rap424 joined #salt |
17:56 |
|
overyander joined #salt |
17:58 |
|
ctrlrsf joined #salt |
18:02 |
|
wendall911 joined #salt |
18:07 |
|
theologian joined #salt |
18:07 |
|
forrest joined #salt |
18:08 |
|
wt joined #salt |
18:18 |
|
ndrei joined #salt |
18:19 |
|
desposo joined #salt |
18:20 |
|
s51itxsyc joined #salt |
18:30 |
|
racooper joined #salt |
18:30 |
|
aparsons joined #salt |
18:30 |
|
racooper joined #salt |
18:30 |
|
bhosmer joined #salt |
18:31 |
|
budman joined #salt |
18:35 |
|
otter768 joined #salt |
18:37 |
|
Mso150 joined #salt |
18:41 |
|
Ryan_Lane joined #salt |
18:48 |
|
jeremyb joined #salt |
18:58 |
|
jeremyb joined #salt |
19:02 |
|
aparsons joined #salt |
19:03 |
Gareth_ |
morning morning |
19:03 |
|
thehaven joined #salt |
19:05 |
|
maxd_ joined #salt |
19:05 |
|
huddy_ joined #salt |
19:06 |
|
schlueter joined #salt |
19:06 |
|
akoumjian_ joined #salt |
19:06 |
|
Hazelesque_ joined #salt |
19:06 |
|
jacksontj_ joined #salt |
19:07 |
|
racooper_ joined #salt |
19:07 |
|
racooper_ left #salt |
19:07 |
|
gamingrobot_ joined #salt |
19:07 |
|
chutz joined #salt |
19:07 |
|
wedgie_ joined #salt |
19:07 |
|
mick3y_ joined #salt |
19:07 |
|
aanriot_ joined #salt |
19:07 |
|
jchen_ joined #salt |
19:08 |
|
pmcg_ joined #salt |
19:08 |
|
eclectic joined #salt |
19:08 |
|
sk_0_ joined #salt |
19:08 |
|
beardo_ joined #salt |
19:08 |
|
FineTralfazz_ joined #salt |
19:08 |
|
Twiglet joined #salt |
19:08 |
|
sxar_ joined #salt |
19:08 |
|
thedodd joined #salt |
19:08 |
|
troyreadyy joined #salt |
19:08 |
|
cwyse joined #salt |
19:09 |
|
racooper joined #salt |
19:09 |
|
davet joined #salt |
19:09 |
|
seblu joined #salt |
19:09 |
|
mschiff joined #salt |
19:09 |
|
mschiff joined #salt |
19:10 |
|
druonysus joined #salt |
19:13 |
|
JPaul joined #salt |
19:14 |
|
aqua^mac joined #salt |
19:15 |
|
TrafficMan_ joined #salt |
19:15 |
|
smcquay joined #salt |
19:17 |
* whiteinge |
nods at Gareth_ |
19:17 |
whiteinge |
manfred: ping. i have a salt_token question and I _think_ you're the guy to ask... |
19:17 |
* Gareth_ |
waves at whiteinge |
19:18 |
|
murrdoc joined #salt |
19:23 |
|
spookah joined #salt |
19:24 |
|
ndrei joined #salt |
19:27 |
|
theo__ joined #salt |
19:31 |
|
FRANK_T joined #salt |
19:37 |
|
theologian joined #salt |
19:40 |
|
vectra joined #salt |
19:42 |
|
FRANK_T joined #salt |
19:42 |
|
jrluis joined #salt |
19:44 |
|
zadock joined #salt |
19:45 |
|
schlueter1 joined #salt |
19:56 |
overyander |
how can i make or get an msi of the windows salt-minion? |
20:08 |
eliasp |
overyander: you'd have to build your own MSI using WiX: http://wixtoolset.org/ |
20:09 |
eliasp |
overyander: would be a nice thing to have, but if you're using to Linux packaging… expect hell… MSI is an awful crap to deal with ;( |
20:09 |
eliasp |
overyander: besides that: why MSI instead of the existing package? would it make bootstrapping of your Win minions easier? |
20:11 |
overyander |
i'm not familiar with wix or nsis. i'm more familiar with windows development. i use salt to manage company workstations. it's really really nice for the systems that seldom see one of our offices or our vpn. trying to get the system admins to install it when they setup a new system is like pulling teeth. if i had an MSI then i could deploy it through group policy through our active directory. this would install the minion as soon as the system joins the |
20:11 |
overyander |
domain. |
20:12 |
eliasp |
overyander: ok, I understand… that's what I imagined your usecase would be like |
20:12 |
overyander |
i found the nsis script, but i don't know how i would go about converting that to use in wix. |
20:13 |
eliasp |
overyander: are you domain admin? |
20:14 |
overyander |
not a member of the domain admins group, but i have some domain admin privs. our company is pretty weird with that stuff. i'm responsible for all the users, computers, gpo's, etc. but my hands are almost completely tied. lol |
20:14 |
eliasp |
IIRC there was a mechanism to run a command on a computer when it joins the domain… |
20:14 |
eliasp |
so you could run the existing installer then… |
20:15 |
overyander |
you can set a script to run, but then there's no way to ensure that the install was successful. |
20:15 |
overyander |
with an msi i can use the native and proper application deploymnet tools |
20:15 |
eliasp |
yeah, sure… |
20:15 |
eliasp |
well, I think the only proper way to get this done then, is to invest some time in learning how to deal with WiX ;-( |
20:16 |
eliasp |
on the other hand: I think quite a few people would be happy about that! :) |
20:16 |
overyander |
time is something i'm really short on right now unfortunately. |
20:17 |
overyander |
we have a domain migration coming up and i was really hoping to have salt deployed to all systems and use it as much as possible to migrate all of our systems. using logmein to remote into someones computer to change their domain, migrate profiles, etc. is a pain |
20:18 |
overyander |
i posted a topic in the salt google group in hopes that whoever already builds the nsis packages for windows could just also make an msi (i thought that person/team would be best suited for the task with existing knowledge) but after about 5 minutes my topic was deleted. |
20:22 |
eliasp |
overyander: the 'salt-users' group? can't really imagine stuff being deleted there… |
20:22 |
overyander |
https://groups.google.com/forum/#!forum/salt-users |
20:23 |
overyander |
I'll make another and see what happens |
20:23 |
eliasp |
anyways… I think for most people the current NSIS (mostly) works, so the need for an MSI is not that urgent… and as MSI packaging is a completely different domain, it's actually quite a bit effort to also package an MSI and learn how to do it |
20:23 |
eliasp |
as the SaltStack devs are really busy recently and short on time, they devote their resources to the high-prio topics and I believe MSI packaging is nothing which will happen soon by themselves and needs to be contributed by the community instead |
20:23 |
|
theo__ joined #salt |
20:23 |
|
StDiluted_ joined #salt |
20:24 |
eliasp |
overyander: I see your usecase and think it's a completely legitimate usecase… |
20:25 |
eliasp |
overyander: you could also file an issue on https://github.com/saltstack/salt/issues |
20:26 |
overyander |
ok |
20:26 |
eliasp |
overyander: it might be tagged "low prio", but then there's at least an issue which could be tracked/referenced by interested people |
20:26 |
overyander |
good idea |
20:28 |
eliasp |
overyander: can't find your mail on salt-users (I have the mail archive here, so I should also see a deleted topic)… do you remember the subject? or what mail address did you use to post? |
20:28 |
|
theologian joined #salt |
20:29 |
overyander |
eliasp, the subject was something like 'windows msi installer 32bit and 64bit', posted through google logged in as jeff.clay infotech-enterprises.com |
20:29 |
eliasp |
overyander: hmm, nothing in the archive… so I think this looks more like your browser screwed something up or so |
20:30 |
dimeshake |
it may be that you can't post without subscribing to the group |
20:30 |
eliasp |
overyander: anyways… file an issue… I'll happily subscribe and add to the discussion should I see the need to |
20:30 |
eliasp |
dimeshake: probably |
20:36 |
|
otter768 joined #salt |
20:40 |
twiedenbein |
z/buffer 10 |
20:49 |
madduck |
Even with RAET, I won't put a salt-master on the public internet, but I need a solution that works outside of a LAN. VPN is obviously one answer, but that's quite complex. There's stunnel, but SSL hasn't exactly been impressive lately. One could use SSH tunnels, sure. Do you know any other tools that could be used to protect Salt traffic? |
20:49 |
madduck |
Also, once that's done, is it possible to just disable all crypto and auth in Salt? |
20:49 |
overyander |
eliasp, https://github.com/saltstack/salt/issues/19137 |
20:50 |
|
capra_ibex joined #salt |
20:56 |
|
monkey66 joined #salt |
20:57 |
|
budman joined #salt |
20:59 |
|
TheThing joined #salt |
21:01 |
|
thawes joined #salt |
21:02 |
|
loggyer joined #salt |
21:03 |
|
aqua^mac joined #salt |
21:06 |
|
monkey66 joined #salt |
21:09 |
|
Zarcos joined #salt |
21:09 |
|
ajolo joined #salt |
21:12 |
|
mgw joined #salt |
21:13 |
mgw |
I'm using gitfs for my fileserver backend, but last time I tried it, _pillars and _runners were not picked up from there (_modules, _states, etc were). Am I missing something? |
21:15 |
|
felskrone joined #salt |
21:22 |
moos3 |
mgw hey :) I think thats way its ment to be, because think _dirs are ment to be localized, but i could be wrong |
21:25 |
|
druonysus joined #salt |
21:25 |
|
druonysus joined #salt |
21:26 |
|
dtulig joined #salt |
21:27 |
|
maxd joined #salt |
21:32 |
|
ksk joined #salt |
21:38 |
|
glyf joined #salt |
21:39 |
|
schlueter joined #salt |
21:40 |
moos3 |
what does anyone know about http://docs.saltstack.com/en/latest/ref/states/all/salt.states.network.html#module-salt.states.network |
21:40 |
|
gngsk_ joined #salt |
21:41 |
|
giantlock joined #salt |
21:49 |
victor- |
how do i do multiple (replace, append, etc) operations on the same file? |
21:52 |
eliasp |
victor-: what keeps you from doing it? |
21:52 |
victor- |
the mechanics |
21:52 |
eliasp |
overyander: thanks for filing the issue… subscribed to it |
21:52 |
eliasp |
overyander: nice to see it was "approved" immediately ;) |
21:52 |
victor- |
in an ID, i have a file.copy and then a file.append, and it complains |
21:54 |
eliasp |
victor-: just use different IDs, like file-foo-replace:\n file.replace: … and file-foo-append:\n file.append … |
21:54 |
eliasp |
victor-: then use "name" to specify the file's path |
21:54 |
victor- |
yeah, i see that. so very clumsy. |
21:54 |
victor- |
how do i make sure the copy happens before the append? |
21:54 |
hal58th |
victor- you just can't a file.managed and a file.append/replace to the same file |
21:54 |
eliasp |
victor-: "require" will do that for you |
21:55 |
victor- |
i guess what i'm asking is how do i do a 'require' on an random ID? |
21:55 |
eliasp |
well, yeah… .managed + .append doesn't really work… only when the file isn't managed |
21:55 |
eliasp |
victor-: you can also do forward requirements using "require_in" |
21:55 |
hal58th |
victor- what makes it random? |
21:56 |
victor- |
hal58th, i mean arbitrary |
21:56 |
eliasp |
well, whatever arbitrary you define as name is what you use as name in the requirement |
21:57 |
victor- |
i have an ID called '/path/file-copy' and then '/path/file-append', and i'd like to make sure the '/path/file-copy' runs before |
21:57 |
victor- |
so in my '/path/file-copy' can i have a "require: /path/file-copy"? |
21:57 |
eliasp |
victor-: require:\n - file: /path/file-copy |
21:58 |
|
hasues joined #salt |
21:58 |
eliasp |
victor-: see also: http://docs.saltstack.com/en/latest/ref/states/requisites.html |
21:58 |
|
karimb joined #salt |
22:00 |
|
hasues left #salt |
22:02 |
|
stephas joined #salt |
22:04 |
|
kermit joined #salt |
22:05 |
|
jalbretsen joined #salt |
22:18 |
|
glyf joined #salt |
22:18 |
victor- |
i've got a file.managed with a source: salt://path/my/file but i'm trying to run masterless, but it's just copying "salt://path/my/file" instead of pulling the file from /srv/salt/path/my/file. how should i do this? |
22:22 |
hal58th |
victor-: I assume you have set the minion to "file_client: local"? Are you also doing "salt-call --local state.highstate" with the local option |
22:22 |
victor- |
i am |
22:23 |
victor- |
to both of those |
22:23 |
hal58th |
What's the error that you are getting? Is this happening for all file.managed? |
22:23 |
victor- |
look like content: can only be a ftp/http or path on a salt master? |
22:23 |
|
beneggett joined #salt |
22:23 |
victor- |
i mean source |
22:24 |
victor- |
so i'll have to use content_pillar to get this to work... :\ |
22:24 |
hal58th |
I believe so. Have only done a salt path |
22:31 |
|
bhosmer joined #salt |
22:34 |
|
NikolaiToryzin joined #salt |
22:35 |
dimeshake |
woohoo! passed SSCE :D |
22:37 |
hal58th |
Ohhh really? I was thinking about taking that during saltconf |
22:37 |
|
otter768 joined #salt |
22:44 |
|
beneggett joined #salt |
22:44 |
dimeshake |
hal58th: it's pretty tricky |
22:45 |
|
druonysus joined #salt |
22:48 |
|
mgw joined #salt |
22:49 |
|
Gareth joined #salt |
22:50 |
|
beneggett joined #salt |
22:52 |
victor- |
does anyone konw how to get the pip state to use a particular version of pip? i want pip2.7 instead of pip2.6 |
22:52 |
|
aqua^mac joined #salt |
22:53 |
eliasp |
victor-: "bin env : None" - "Absolute path to a virtual environment directory or absolute path to a pip executable. The example below assumes a virtual environment has been created at /foo/.virtualenvs/bar." |
22:54 |
eliasp |
victor-: see also: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.pip_state.html |
22:55 |
victor- |
eliasp, getting this: http://pastebin.com/fSyagATt |
22:56 |
eliasp |
victor-: is your pip systemwide installed or as part of a virtualenv? |
22:56 |
eliasp |
victor-: ah, sorry… |
22:56 |
eliasp |
victor-: didn't read your first states |
22:57 |
eliasp |
victor-: I believe I have read about this issue quite a few times during the last weeks… pip is installed by the 'pkg' state, but isn't recognized until the next state invocation |
22:59 |
|
aquinas joined #salt |
23:01 |
|
ckao joined #salt |
23:22 |
|
glyf joined #salt |
23:35 |
|
cedwards joined #salt |
23:35 |
|
cedwards1 joined #salt |
23:36 |
eightyeight |
did the "watch_in" behavior change? |
23:37 |
cedwards |
I've got a custom grains module I've written, but it seems to me the grains are being cached..? |
23:37 |
babilen |
eightyeight: Why do you think it did? |
23:37 |
cedwards |
I'm not using the cache_grains option, and I can't otherwise figure out why/where the data would be cached |
23:37 |
babilen |
cedwards: Grains are cached, yes |
23:38 |
babilen |
You can use saltutil.sync_grains to sync/update them |
23:38 |
babilen |
(that is being run (well, sync_all) on highstates) |
23:38 |
cedwards |
babilen: according to this grains aren't cached by default - http://salt.readthedocs.org/en/latest/topics/releases/2014.1.0.html#grains-caching |
23:38 |
eightyeight |
babilen: because i notide the PID of a service, removed the config, highstated, and the service did not restart. the PID is the same |
23:38 |
cedwards |
and I have been using thy sync_grains, but I'm getting the same list back |
23:39 |
eightyeight |
s/notide/noted/ |
23:39 |
dimeshake |
cedwards: that is a different cache layer. it prevents having to regenerate/read grains on minion startup |
23:39 |
dimeshake |
most of the grains in salt are system derived |
23:40 |
eightyeight |
babilen: when a service is defined, putting it under "watch_in" would normally restart the pid if the config that is being watched changes |
23:40 |
eightyeight |
that doesn't seem to be the case now |
23:40 |
dimeshake |
loading those at start time involves some overhead, so that cache setting exists. |
23:40 |
dimeshake |
as i understand it, anyway :) |
23:41 |
cedwards |
so it doesn't apply to, or is overridden by, saltutil.sync_grains? |
23:41 |
babilen |
eightyeight: I use plenty of watch_in with 2014.7 and they are working fine. Does the highstate run include a service restart? |
23:41 |
babilen |
cedwards: Why do you think that you should get a different list back? |
23:42 |
dimeshake |
calling sync_grains should get them set correctly from your custom module if it's being loaded right |
23:42 |
babilen |
indeed |
23:42 |
eightyeight |
babilen: we have too. we just upgraded to 2014.7, and noticed the oddity. regarding "Does the highstate run include a service restart?", i'm not sure what you mean |
23:42 |
babilen |
Is it executable? I guess we need more details. |
23:43 |
cedwards |
so the custom grains module I wrote reads a yaml list of properties to query from our internal CMDB. |
23:43 |
babilen |
eightyeight: I meant: Does the highstate run in which you change the configuration file in question say anything about that service? |
23:43 |
cedwards |
as I've made changes to that list and sync_grains it makes no difference in my output of grains.items. |
23:44 |
eightyeight |
babilen: pastebin of the highstate: http://ae7.st/p/3mh |
23:44 |
|
hal58th1 joined #salt |
23:44 |
babilen |
cedwards: Wouldn't an external pillar be more appropriate for that btw? |
23:44 |
babilen |
"is it executable?" |
23:44 |
babilen |
eightyeight: *heavily redacted that is ;) |
23:45 |
cedwards |
There was some internal discussion about pillar vs grains. I think grains are appropriate--there's nothing that's private or needs to be targeted/limited about the properties. |
23:45 |
eightyeight |
that's why i'm asking. i noticed that highstate output has included new stuffs since the upgrade |
23:45 |
babilen |
eightyeight: I see no indication in there that a service should have been restarted. But I believe you, just cannot confirm your observation from my experience (really, use it daily) and therefore think that more information is needed |
23:45 |
dimeshake |
cedwards: grains are meant to stay relatively static |
23:45 |
dimeshake |
how often do you need to change these values? |
23:46 |
|
ninkotech joined #salt |
23:46 |
babilen |
IMHO grains should be pretty host specific data such as IP addresses, hardware information and the like. |
23:46 |
eightyeight |
babilen: a more complete pastebin: http://ae7.st/p/757 |
23:47 |
cedwards |
yeah. this data is for the most part static, but it seems inexpensive to sync_grains and see if there had been any changes |
23:47 |
cedwards |
the cmdb information is stuff like rack, cage, rack_u, etc.. |
23:47 |
babilen |
eightyeight: Where do you have your watch_in ? |
23:47 |
cedwards |
doesn't change often, but also doesn't need to be private like pillar |
23:48 |
babilen |
pillar isn't only for private data, but I agree that grains are appropriate in this case |
23:48 |
eightyeight |
babilen: http://ae7.st/p/2at |
23:49 |
babilen |
hmm, does it restart it if you have actual changes? |
23:49 |
babilen |
(as opposed to "first time running") |
23:49 |
eightyeight |
nay |
23:50 |
dimeshake |
that should work.. for giggles, try separating service.running into service: - running ... |
23:50 |
eightyeight |
ok |
23:50 |
cedwards |
so my module reads in a file similar to this (http://pastebin.com/h3cgwUzu), gathers the properties list and sends that as an API query to our CMDB. |
23:51 |
eightyeight |
dimeshake: same result |
23:51 |
babilen |
eightyeight: I see nothing wrong with what you did. Another thing to try: Use a different ID and "- name: prosody" and refer to both in your watch_in block. |
23:51 |
babilen |
eightyeight: "same result" == "Always new file" ? |
23:51 |
cedwards |
as I'm testing this module I extend the properties list, but it doesn't seem to change the returned list in grains |
23:52 |
babilen |
+with |
23:52 |
eightyeight |
babilen: same result == not restarting the daemon after a config change |
23:52 |
babilen |
so actual diff in the file |
23:52 |
eightyeight |
yeah |
23:52 |
eightyeight |
in the prosody.cfg.lua |
23:53 |
eightyeight |
curious if 'prosody' is conflicting with the package name? |
23:53 |
* eightyeight |
tries renaming it |
23:53 |
cedwards |
so that's why I wonder about caching, because I'm getting back results from properties that were once in the file but are no longer. |
23:53 |
babilen |
cedwards: And the grain is executable? Did you restart the minion? |
23:55 |
cedwards |
i've tried restarting the minion and resyncing the grains |
23:55 |
cedwards |
the module wasn't executable, but it seems to work without.. |
23:56 |
babilen |
I seem to recall an issue with the grains not being executable quite a while back (hence my question) |
23:56 |
babilen |
(as in 7+ months ago) |
23:57 |
eightyeight |
babilen: renaming the service ID to 'prosodyd', with '- name: prosody', referencing the ID, canging the prosody.cfg.lua, and highstating still is not restarting the daemon |
23:57 |
eightyeight |
s/canging/changing/ |
23:58 |
|
ajolo joined #salt |
23:58 |
|
ggoZ joined #salt |
23:59 |
babilen |
Hmm, that starts to look like a bug. Anything special about your deployment? (weird operating systems like Windows, strange Versions, ...) ;) |