| Time |
Nick |
Message |
| 00:20 |
|
mosen joined #salt |
| 00:22 |
|
ipsecguy joined #salt |
| 00:36 |
|
q1x joined #salt |
| 00:59 |
|
Guest73 joined #salt |
| 01:07 |
|
tiwula joined #salt |
| 01:07 |
AstraLuma |
ok, i'm trying to get a very basic custom tops file going in _tops. I've added the file, sync'd my master, added the configuration, restarted it. but it doesn't seem to load it. |
| 01:09 |
|
ipsecguy joined #salt |
| 01:09 |
AstraLuma |
the logging isn't showing and the state i've added (`__marker__`) isn't appearing on any minions |
| 01:10 |
AstraLuma |
(i'm asking them with saltutil.show_top) |
| 01:17 |
hemebond |
What is "_tops"? |
| 01:19 |
|
zerocoolback joined #salt |
| 01:20 |
whytewolf |
_tops is a dynamic module directory for the master_tops system |
| 01:22 |
whytewolf |
https://docs.saltstack.com/en/latest/topics/master_tops/ |
| 01:22 |
whytewolf |
AstraLuma: add logging to your top python file so that it logs |
| 01:23 |
AstraLuma |
i did. it's not appearing. |
| 01:23 |
whytewolf |
what log are you looking at? |
| 01:24 |
whytewolf |
and can you post your code? |
| 01:24 |
whytewolf |
as well as your config |
| 01:24 |
AstraLuma |
it's pretty much just the snippet in https://docs.saltstack.com/en/latest/topics/master_tops/ |
| 01:25 |
whytewolf |
for the config did you restart the master after changing it? |
| 01:25 |
AstraLuma |
yup. I've done -l debug (i'm currently running with log_level:debug) |
| 01:26 |
AstraLuma |
i added /etc/salt/master.d/tops.conf, which is just master_tops: mytops: True |
| 01:26 |
AstraLuma |
the saltutil.sync_all runner lists it as being synced |
| 01:26 |
AstraLuma |
all i have left is to grab that ipython breakpoint snippet |
| 01:27 |
AstraLuma |
i'm looking at /var/log/salt/master |
| 01:28 |
whytewolf |
__virtualname__ matches mytops right? |
| 01:28 |
AstraLuma |
oops, no it doesn't |
| 01:29 |
AstraLuma |
synced, and that didn't fix it. |
| 01:29 |
AstraLuma |
unless i have to restart the master every time i change it? |
| 01:30 |
whytewolf |
you shouldn't have to. but with master side modules it can be hit or miss |
| 01:30 |
AstraLuma |
oh, yeah you do |
| 01:30 |
AstraLuma |
saltutil.sync_all runner didn't do it, but restarting the master did |
| 01:30 |
AstraLuma |
unless there's some cache i'm missing? |
| 01:31 |
whytewolf |
no, no cache. more of how and when things are loaded on if they can be skipped |
| 01:31 |
whytewolf |
s/br skipped/skip restart |
| 01:33 |
|
q1x joined #salt |
| 01:34 |
whytewolf |
basic rule of thumb. if it is something you don't call directly you most likely need to restart |
| 01:44 |
AstraLuma |
today i learned |
| 01:57 |
|
hoonetorg joined #salt |
| 02:25 |
|
magicman1223 joined #salt |
| 02:26 |
|
OliverUK joined #salt |
| 02:36 |
|
justanotheruser joined #salt |
| 02:56 |
|
ilbot3 joined #salt |
| 02:56 |
|
Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.9, 2017.7.4 <+> RC for 2018.3.0 is out, please test it! <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic, and https://saltstackcommunity.herokuapp.com (for slack) <+> We are volunteers and may not have immediate answers |
| 03:08 |
|
mrueg joined #salt |
| 03:19 |
|
exarkun joined #salt |
| 03:22 |
|
KFDM joined #salt |
| 03:38 |
|
ddg joined #salt |
| 03:56 |
|
mosen joined #salt |
| 04:11 |
|
StolenToast joined #salt |
| 04:16 |
|
justanotheruser joined #salt |
| 04:26 |
|
indistylo joined #salt |
| 04:36 |
|
mosen joined #salt |
| 04:59 |
|
exarkun joined #salt |
| 05:03 |
|
aruns joined #salt |
| 05:16 |
|
thelocehiliosan joined #salt |
| 05:25 |
|
shiranaihito joined #salt |
| 05:30 |
|
justan0theruser joined #salt |
| 05:45 |
|
sauvin_ joined #salt |
| 05:49 |
|
armyriad joined #salt |
| 05:59 |
|
aruns__ joined #salt |
| 06:00 |
|
Hybrid joined #salt |
| 06:18 |
|
Hybrid joined #salt |
| 06:19 |
|
chowmein__ joined #salt |
| 06:21 |
|
Guest73 joined #salt |
| 06:25 |
|
Guest73 joined #salt |
| 06:39 |
|
exarkun joined #salt |
| 06:46 |
|
eseyman joined #salt |
| 07:02 |
|
fernie joined #salt |
| 07:06 |
|
masber joined #salt |
| 07:12 |
|
justanotheruser joined #salt |
| 07:22 |
|
tyx joined #salt |
| 07:26 |
|
honestly joined #salt |
| 07:26 |
|
hillna_ joined #salt |
| 07:26 |
|
m0nky joined #salt |
| 07:26 |
|
petems joined #salt |
| 07:26 |
|
Hazelesque joined #salt |
| 07:26 |
|
czchen_ joined #salt |
| 07:26 |
|
matti__ joined #salt |
| 07:26 |
|
honestly joined #salt |
| 07:26 |
|
Hazelesque joined #salt |
| 07:26 |
|
wongster80 joined #salt |
| 07:27 |
|
saintpablo joined #salt |
| 07:27 |
|
marcinkuzminski joined #salt |
| 07:27 |
|
pf_moore joined #salt |
| 07:27 |
|
systeem[m] joined #salt |
| 07:27 |
|
hoverbear joined #salt |
| 07:27 |
|
tcolvin joined #salt |
| 07:27 |
|
hax404 joined #salt |
| 07:27 |
|
wych joined #salt |
| 07:28 |
|
KingJ joined #salt |
| 07:28 |
|
Deliant joined #salt |
| 07:29 |
|
sayyid9000 joined #salt |
| 07:29 |
|
mk-fg joined #salt |
| 07:29 |
|
mk-fg joined #salt |
| 07:29 |
|
ThomasJ joined #salt |
| 07:31 |
|
nledez joined #salt |
| 07:31 |
|
indistylo joined #salt |
| 07:32 |
|
hoverbear joined #salt |
| 07:32 |
|
hoverbear joined #salt |
| 07:38 |
|
frew joined #salt |
| 07:59 |
|
jor joined #salt |
| 08:05 |
|
Ouzo_12 joined #salt |
| 08:07 |
|
Hybrid joined #salt |
| 08:07 |
|
cewood joined #salt |
| 08:08 |
|
oida joined #salt |
| 08:11 |
|
masber joined #salt |
| 08:13 |
|
jas02 joined #salt |
| 08:19 |
|
exarkun joined #salt |
| 08:20 |
|
jas02 joined #salt |
| 08:27 |
|
Ricardo1000 joined #salt |
| 08:37 |
|
Tucky joined #salt |
| 08:42 |
|
jrenner joined #salt |
| 08:43 |
onslack |
<msmith> legreffier: if you're still here, taking the result of one state and feeding it into another is the purpose of the new 'slots' functionality, but that's brand new and awaiting release. in the meantime a custom state module could perform your first task using python calls, save and manipulate the results in the way you want, and then use them for another task |
| 08:48 |
|
Pjusur joined #salt |
| 08:54 |
|
Guest73 joined #salt |
| 08:55 |
|
masber joined #salt |
| 09:00 |
|
mikecmpbll joined #salt |
| 09:10 |
|
indistylo joined #salt |
| 09:20 |
|
mikecmpb_ joined #salt |
| 09:22 |
|
jas02 joined #salt |
| 09:22 |
|
dev_tea_ joined #salt |
| 09:25 |
|
inad922 joined #salt |
| 09:26 |
|
mbologna joined #salt |
| 09:28 |
|
masber joined #salt |
| 09:28 |
|
jesusaur joined #salt |
| 09:37 |
|
Mattch joined #salt |
| 09:42 |
|
jas02 joined #salt |
| 09:46 |
|
inad922 joined #salt |
| 09:49 |
|
jas02 joined #salt |
| 09:52 |
|
mikecmpbll joined #salt |
| 09:53 |
|
jas02 joined #salt |
| 09:58 |
|
jas02 joined #salt |
| 09:59 |
|
exarkun joined #salt |
| 10:08 |
|
justanotheruser joined #salt |
| 10:17 |
|
Mandorath joined #salt |
| 10:17 |
|
FL1SK joined #salt |
| 10:19 |
|
jas02 joined #salt |
| 10:21 |
|
jas02_ joined #salt |
| 10:24 |
sommerfest |
does someone here experimented with vault + pillar? |
| 10:24 |
sommerfest |
did* |
| 10:27 |
|
masuberu joined #salt |
| 10:27 |
|
jas02 joined #salt |
| 10:29 |
|
jas02_ joined #salt |
| 10:29 |
|
vb29 joined #salt |
| 10:30 |
|
Mandorath left #salt |
| 10:31 |
|
Mandorath joined #salt |
| 10:31 |
Mandorath |
Hi, we are trying to figure out a way to reconfigure the network while maintaining an active connection between a minion and master. Our experience is that he master gets a time-out after an ip address changed on the minion. Is there a way to achieve this? |
| 10:31 |
vb29 |
Hi....I am trying to use SaltStack with Jenkins and I have installed SaltStack plugin for the same. I have configured it properly and it works fine...I want to pass BUILD_ID environment variable as pillar during the build. Any idea how can I do that? |
| 10:31 |
|
Danny__ joined #salt |
| 10:32 |
hemebond |
Mandorath: The minion connects to the master and it should just reconnect. |
| 10:32 |
vb29 |
I have something like this configured in my Jenkins Job |
| 10:32 |
vb29 |
test_env "pillar={"build_id": "${env.BUILD_ID}" }" |
| 10:32 |
vb29 |
but this prints the complete string as it is |
| 10:34 |
vb29 |
can't find much on the site as well https://wiki.jenkins.io/display/JENKINS/saltstack-plugin |
| 10:35 |
|
mosen joined #salt |
| 10:35 |
onslack |
<msmith> that sounds like a question for jenkins support rather than salt :) |
| 10:37 |
|
Naresh joined #salt |
| 10:37 |
onslack |
<msmith> my knowledge of jenkins is slim at best, but i suspect that the textbox config doesn't expand variables, you may need to look at one of the other options, perhaps even jenkins code like groovy |
| 10:37 |
|
jas02 joined #salt |
| 10:38 |
onslack |
<msmith> comments at the bottom imply it'll be "supported in the next release", as of 28th feb, so you may want to check to see if it's there yet |
| 10:39 |
|
jas02 joined #salt |
| 10:42 |
vb29 |
@onslack: Thanks for the reply! :) I will dig more, just wanted to check if someone here has already used it or bumped into same kind of problem |
| 10:51 |
|
jas02 joined #salt |
| 10:55 |
|
inad922 joined #salt |
| 10:56 |
|
jas02 joined #salt |
| 11:11 |
|
jas02_ joined #salt |
| 11:12 |
|
jesusaur joined #salt |
| 11:16 |
legreffier |
onslack: that's a definite chicken and egg... i wanna install a newer aws cli to fetch info about my vpc setup from a state... but it can't be done in a single pass. |
| 11:17 |
legreffier |
i feel i will just get a newer awscli out of salt context. |
| 11:18 |
legreffier |
thanks for your help |
| 11:25 |
|
xet7 joined #salt |
| 11:31 |
|
Hybrid joined #salt |
| 11:32 |
onslack |
<msmith> (fyi onslack is the bot's name :) |
| 11:33 |
onslack |
<msmith> legreffier: you may be able to get something richer by using orchestration states rather than minion states, it's not easy to know what you're doing from that :) |
| 11:38 |
|
jas02 joined #salt |
| 11:39 |
legreffier |
onslack: i wanted , from a state , 1. ensure you have an up-to-date awscli (as jessie ships 2 years ago's one), 2. use this to fetch the id of the relevant efs , 3. generate a reliable /etc/fstab with (2). |
| 11:41 |
onslack |
<msmith> 1 you can do with a state, sure. 2 and 3 would need to be a custom state until slots are available |
| 11:41 |
onslack |
<msmith> but that way does let you do it in one pass |
| 11:42 |
legreffier |
custom state = python ? |
| 11:42 |
onslack |
<msmith> usually, yes |
| 11:42 |
onslack |
<msmith> you can call the existing state/execution modules to do the work, just use this custom state module to glue them together |
| 11:43 |
legreffier |
can i ship this within my state tree ? |
| 11:43 |
onslack |
<msmith> afaik, yep |
| 11:43 |
onslack |
<msmith> i think it needs to be in <salt://_states> |
| 11:43 |
legreffier |
onslack: can you share a doc or a simple exemple ... I already made several script relying on boto stuffs , it shouldn't be too hard. |
| 11:44 |
onslack |
<msmith> <https://docs.saltstack.com/en/latest/ref/states/writing.html> |
| 11:46 |
Mandorath |
@hemebond: We are changing the ip-address during a salt highstate run. The run continues on the salt-minion but the master gets a timeout. |
| 11:47 |
onslack |
<msmith> Mandorath: that's normal, the minion drops the connection so the master can't issue the request for progress |
| 11:47 |
onslack |
<msmith> it'll reconnect, as mentioned, but probably not before the master has issued such a request |
| 11:49 |
|
sjorge joined #salt |
| 11:49 |
onslack |
<msmith> more specifically, the request will be put on the event bus as usual, but the minion won't see it until it reconnects |
| 11:52 |
|
masuberu joined #salt |
| 11:52 |
|
Ricardo1000 joined #salt |
| 11:55 |
legreffier |
onslack: one more question : can i keep the (2) a custom one , and rely on state.mount to do it's magic (in 3) ? how can i use result from 2 in 3 in that scenario ? |
| 11:55 |
|
Ricardo1000 joined #salt |
| 11:56 |
onslack |
<msmith> it's the result passing from 2 to 3 that requires the custom state. you can still call state.mount in your custom state module, passing in the appropriate arguments |
| 11:56 |
onslack |
<msmith> and your custom state can have arguments of its own that you then use for the appropriate calls |
| 11:56 |
sommerfest |
can you use vault secrets in pillar while Vault is sealed? |
| 11:56 |
legreffier |
ok |
| 11:56 |
sommerfest |
i've got 503 error, and unsealing vault manually seems to be not right |
| 11:58 |
onslack |
<msmith> sorry sommerfest, i haven't used vault yet. i'd imagine that the config should contain settings for vault to allow it to be used tho, right? |
| 12:00 |
|
jas02 joined #salt |
| 12:02 |
onslack |
<msmith> i see pillar.vault and sdb.vault, are you using one of these? |
| 12:06 |
|
gmoro joined #salt |
| 12:08 |
|
gmoro joined #salt |
| 12:17 |
|
thelocehiliosan joined #salt |
| 12:19 |
|
jas02 joined #salt |
| 12:22 |
|
Nahual joined #salt |
| 12:26 |
|
Kelsar joined #salt |
| 12:35 |
|
alvinstarr joined #salt |
| 12:37 |
|
aruns__ joined #salt |
| 12:58 |
|
do3meli joined #salt |
| 12:59 |
|
jhauser joined #salt |
| 13:04 |
|
s0undt3ch_ joined #salt |
| 13:04 |
|
s0undt3ch_ left #salt |
| 13:05 |
|
s0undt3ch joined #salt |
| 13:06 |
|
DammitJim joined #salt |
| 13:07 |
do3meli |
anyone else experiencing problems with the new version 2017.7.4 and git.latest state in combination with the identity parameter? |
| 13:08 |
do3meli |
i get the following error on the new version "KeyError: 'ssh.key_is_encrypted'" |
| 13:13 |
zer0def |
do3meli: do you happen to have a traceback handy? |
| 13:14 |
do3meli |
zer0def: here we go: https://paste.ubuntu.com/p/Kg3cnw8xJy/ |
| 13:15 |
|
ecdhe joined #salt |
| 13:15 |
|
edrocks joined #salt |
| 13:16 |
zer0def |
did you happen to upgrade salt recently have didn't reload the service yet? |
| 13:16 |
do3meli |
i checked that. i have updated the minion - and obviously did restart it. still - same error. |
| 13:17 |
zer0def |
issue here is that /usr/lib/python2.7/site-packages/salt/utils/ssh.py seems to be omitted while loading helper functions |
| 13:17 |
|
gh34 joined #salt |
| 13:19 |
zer0def |
would imply a broken python or salt install, but that's not really helpful on it's own |
| 13:20 |
do3meli |
we do use the corresponding freshport for FreeBSD: https://www.freshports.org/sysutils/py-salt/ |
| 13:20 |
do3meli |
version 2017.7.4_1 |
| 13:21 |
zer0def |
what OS is the minion running? |
| 13:21 |
do3meli |
freebsd 10.3 |
| 13:21 |
|
pewpew joined #salt |
| 13:21 |
zer0def |
hum… you might want to try to import the module itself in a python interpreter to see whether it raises any exceptions |
| 13:22 |
do3meli |
you mean importing salt.util.ssh ? |
| 13:22 |
zer0def |
yes, `import salt.utils.ssh` |
| 13:22 |
do3meli |
that works without error |
| 13:24 |
zer0def |
sounds like a bug, so unless someone comes up with why that might be the case on fbsd, i'd file an issue, if they isn't one already |
| 13:24 |
do3meli |
there is one. |
| 13:24 |
do3meli |
from 2016 or so. let me grab the url |
| 13:26 |
do3meli |
but i believe it got broken with this one here: https://github.com/saltstack/salt/pull/46036 ( see the release notes here: https://github.com/saltstack/salt/blob/d1d966abc7fb484ea6b4082df7ff4d6488272467/doc/topics/releases/2017.7.4.rst for a quick summary) |
| 13:26 |
|
Hybrid joined #salt |
| 13:27 |
zer0def |
so `git.latest` worked pre-2017.7.4? |
| 13:27 |
do3meli |
and this bug here is the one i think matchs exactly: https://github.com/saltstack/salt/issues/34269 but due to the age of the bug i think it may is different |
| 13:28 |
|
rlefort joined #salt |
| 13:28 |
|
om2 joined #salt |
| 13:29 |
do3meli |
yes - i have a minion on FreeBSD with the same state on salt-minion 2017.7.2 (Nitrogen) that works. |
| 13:30 |
do3meli |
whats your impression. does it belong to the bug from 2016. or is it something else? i can open an issue on github if i know if it is related or something new... |
| 13:33 |
|
racooper joined #salt |
| 13:33 |
|
stewgoin joined #salt |
| 13:34 |
zer0def |
i'm unsure, this code block move to an utils module *should* be working… unless the minion in question wasn't reloaded or relies on precached .pyc/.pyo files |
| 13:36 |
zer0def |
that said, you are on the right track |
| 13:40 |
|
thelocehiliosan joined #salt |
| 13:43 |
do3meli |
actually. when running salt-call locally on the machine it works. so it seems to be related to the bug from 2016. |
| 13:43 |
do3meli |
it's not working if salt running from master against the minion in question. |
| 13:51 |
onslack |
<msmith> there's a couple of differences possible there then. the running minion is out of date, but restarting it would fix that, or the user context is different |
| 13:55 |
onslack |
<msmith> either the user id itself, or the environment you're running as, is different to that used to start the background minion |
| 13:56 |
do3meli |
hmm. i can hardly believe that. |
| 13:56 |
do3meli |
we did not change our environment and it did work on 2017.7.2 |
| 13:57 |
do3meli |
the running minion is verified to be the right version. restarted several times. |
| 13:57 |
do3meli |
the user context cant really be a problem either. i do run salt as root |
| 13:57 |
onslack |
<msmith> the shell, it's environment variables, including path - and i'm sure many other factors - all contribute to a potential difference |
| 13:58 |
onslack |
<msmith> how do you start the background minion? |
| 13:58 |
do3meli |
service salt_minion start |
| 13:59 |
onslack |
<msmith> so the shell and environment variables are strictly controlled by the system. compared to the temporary minion started up by running salt-cat |
| 13:59 |
do3meli |
env variables, shell, ect everything can't be an issue. we have states for all of those. and we didnt change them ;-) |
| 13:59 |
onslack |
<msmith> * salt-call |
| 13:59 |
onslack |
<msmith> on the contrary, i _guarantee_ that the service runner controls them |
| 13:59 |
do3meli |
ahh now i got your point. you comparing salt-call to salt run from master. |
| 14:00 |
do3meli |
got you. |
| 14:00 |
do3meli |
i agree. possible that the env is different |
| 14:00 |
onslack |
<msmith> no, i'm comparing running a minion process from a shell vs the system starting it in a carefully controlled environment |
| 14:00 |
onslack |
<msmith> even on the same host these are certainly going to be different |
| 14:01 |
do3meli |
i understand. interactive vs non interactive. |
| 14:01 |
onslack |
<msmith> both processes start up, connect to- and fetch data from- the master, but that doesn't mean they're going to behave the same if their startup environment is different |
| 14:02 |
|
syd_salt2 joined #salt |
| 14:03 |
do3meli |
whats the best way to debug this further? any way to easily get salt environment via module or something like that? |
| 14:03 |
onslack |
<msmith> long story short, see if you can spot the differences. maybe there's actually more than one copy of python and/or salt installed. maybe salt isn't seeing the same path so when it looks for processes to execute it picks differently |
| 14:03 |
|
beardedeagle joined #salt |
| 14:04 |
onslack |
<msmith> given that the minion you're running is the one that works, not really. if it was the other way around then you could trace the failure, but if it's the background minion that's failing then it's much much harder |
| 14:06 |
do3meli |
allright. thank you msmith. btw is your github acc @martynsmith ? |
| 14:06 |
onslack |
<msmith> nope, that's not me :) |
| 14:06 |
do3meli |
allright ;) thx |
| 14:08 |
|
m0nky joined #salt |
| 14:09 |
zer0def |
i'd probably give it a shot to wipe all .pyc and .pyo from /usr/local/lib/python2.7/site-packages/salt, restart the minion, see if it worked, if it broke salt, reinstall, probably to the previous version and write up an issue |
| 14:11 |
|
aruns joined #salt |
| 14:15 |
do3meli |
hmm wouldn't it be that if i stop the salt minion daemon process and start one on the shell in foreground and then trigger a highstate remotely from salt master that it should work in this case? |
| 14:15 |
do3meli |
( i tested and it does not work) |
| 14:15 |
|
aruns joined #salt |
| 14:16 |
onslack |
<msmith> running the minion interactively _should_ work. does it respond to basics like test.ping ? |
| 14:16 |
do3meli |
yup |
| 14:16 |
do3meli |
well it does execute with state.highstate test=true 627 states but not the git.latest one |
| 14:16 |
onslack |
<msmith> the issue you've referenced suggests they moved that function to __utils__ but your backtrace clearly shows __salt__ |
| 14:17 |
zer0def |
are we looking at the same traceback, msmith?: https://paste.ubuntu.com/p/Kg3cnw8xJy/ |
| 14:18 |
onslack |
<msmith> ah no, that'll help :D |
| 14:19 |
|
hillna_ left #salt |
| 14:20 |
zer0def |
it's as if the loader did pick up on this change |
| 14:20 |
zer0def |
s/did/didn't/ |
| 14:24 |
onslack |
<msmith> first note: your traceback doesn't match the develop branch. line 283 is a comment. now checking the tagged version |
| 14:24 |
do3meli |
i never said it matches develop branch ;-) |
| 14:25 |
zer0def |
the traceback matches up with 2017.7.4 |
| 14:31 |
onslack |
<msmith> my point was simply that it's changed since that version, it's possible it's been fixed in the upcoming release |
| 14:32 |
|
jas02 joined #salt |
| 14:33 |
|
hojgaard joined #salt |
| 14:43 |
|
Hybrid joined #salt |
| 14:47 |
|
jas02 joined #salt |
| 14:54 |
|
shpoont joined #salt |
| 14:58 |
|
gmoro joined #salt |
| 14:58 |
|
jas02 joined #salt |
| 14:59 |
|
cgiroua joined #salt |
| 15:08 |
mage_ |
is there a way to return an exist status other than "0" when a state failed in a state.apply (highstate) ? |
| 15:10 |
mage_ |
I'm asking this because I'm issuing a salt-call in a CI/CD context in Gitlab, but the "Job succeeded" event with 1 failed state |
| 15:10 |
|
xet7 joined #salt |
| 15:18 |
onslack |
<msmith> i'm not sure if it'll do what you want, but there is --retcode-passthrough that might |
| 15:18 |
|
tiwula joined #salt |
| 15:23 |
mage_ |
looks like :) thanks |
| 15:24 |
major |
anyone have an example of passing json w/ arrays to bootstrap-salt.sh -J? |
| 15:32 |
whytewolf |
do3meli: I know I'm late to the party. but https://github.com/saltstack/salt/issues/46512 |
| 15:33 |
|
mikecmpbll joined #salt |
| 15:34 |
do3meli |
whythewolf thx for the headsup. thats an interesting one. will try this one tomorrow |
| 15:46 |
|
kojiro joined #salt |
| 15:51 |
|
dezertol joined #salt |
| 15:52 |
mage_ |
is it possible to launch an orchestratation job on my master from a minion using salt-call ? |
| 15:52 |
mage_ |
s/orchestratation/orchestration |
| 15:53 |
mage_ |
on my MASTER I'm launching with $> salt-run state.orchestrate orch.certificates |
| 15:53 |
onslack |
<msmith> yep. fire an event and react to it :) |
| 15:53 |
mage_ |
I tried: salt-call --local state.orchestrate orch.certificates on the minion but it doesn"t work |
| 15:54 |
whytewolf |
try state.apply |
| 15:54 |
mage_ |
the problem with events is that I need the output on the minion |
| 15:54 |
onslack |
<msmith> --local means masterless, and you'd need the orch configured locally for that to work |
| 15:54 |
whytewolf |
is the minion on the master? |
| 15:54 |
mage_ |
whytewolf: nop |
| 15:54 |
whytewolf |
then no |
| 15:54 |
onslack |
<msmith> i'm not aware of a way |
| 15:55 |
mage_ |
ok so fire an event + reaction is the only way ? |
| 15:55 |
onslack |
<msmith> well you might be able to post the trigger using the api, but it's still going to be async |
| 15:55 |
mage_ |
ok (: |
| 15:56 |
onslack |
<msmith> nothing stopping you writing a client using the api that monitors the job while its running, if you really needed to |
| 15:56 |
whytewolf |
posting a trigger to the api is still event + reaction :P |
| 15:57 |
onslack |
<msmith> i thought the api could trigger the orch directly |
| 15:57 |
whytewolf |
oh yeah i sometimes forget about the rest of the api. |
| 15:57 |
whytewolf |
webhook is used so often :P |
| 15:57 |
mage_ |
I've never used the salt-api atm |
| 15:58 |
mage_ |
I have already orchestration script to create (FreeBSD) jails on the fly, setup things, etc .. and I wanted to reuse that in my ci/cd Gitlab pipeline |
| 15:59 |
onslack |
<msmith> i wonder if there's a plugin for saltstack in gitlab |
| 16:00 |
mage_ |
not yet unfortunately :( |
| 16:00 |
mage_ |
ATM I've installed a gitlab-runner on the minion and I'm issuing salt-call, which works well |
| 16:02 |
|
theloceh1liosan joined #salt |
| 16:02 |
|
tyx joined #salt |
| 16:13 |
mage_ |
if I understand correctly from the docs it should be possible in a Python script launched on a minion to get the "output" of a reaction triggered by some/event/launched/on/the/minion with salt.utils.event.get_event(...) ? |
| 16:24 |
|
evle joined #salt |
| 16:36 |
|
inad922 joined #salt |
| 16:44 |
|
xet7 joined #salt |
| 16:46 |
|
edrocks joined #salt |
| 16:52 |
|
KolK left #salt |
| 17:05 |
|
vb29 joined #salt |
| 17:27 |
MTecknology |
mage_: if you want to use the output of a reactor, you might want to look at thorium |
| 17:33 |
|
jpsharp left #salt |
| 17:36 |
|
vb29 joined #salt |
| 17:37 |
|
wongster80 joined #salt |
| 17:40 |
lordcirth_work |
So I'm trying to get a debian-installer preseed to run bootstrap-salt.sh, but it can't verify SSL certs |
| 17:45 |
lordcirth_work |
in-target might be what I need |
| 17:52 |
MTecknology |
lordcirth_work: if you weren't using in-target, then definitely, you need that. |
| 17:54 |
lordcirth_work |
MTecknology, yep it works! Except the apt-cacher breaks the salt repo, so I need to fix that, but whatever |
| 17:55 |
MTecknology |
as long as bootstrap-salt.sh isn't that default messy pile of mess... |
| 17:55 |
|
vb29 left #salt |
| 17:57 |
|
gmoro joined #salt |
| 18:06 |
|
thelocehiliosan joined #salt |
| 18:09 |
|
edrocks joined #salt |
| 18:17 |
lordcirth_work |
"Installation type d-i is not known" |
| 18:20 |
|
Guest73 joined #salt |
| 18:25 |
|
xet7 joined #salt |
| 18:26 |
MTecknology |
lordcirth_work: you're not writing a preseed file from scratch, are ya? |
| 18:26 |
|
schemanic joined #salt |
| 18:26 |
* MTecknology |
is curious what it looks like to produce that error |
| 18:27 |
lordcirth_work |
MTecknology, nope, just trying to add salt. Before I was just adding the package, but Ubuntu 16.04's salt is out of date enough that upgrading it requires some workarounds |
| 18:27 |
lordcirth_work |
Pretty sure the salt-bootstrap is trying to guess my distro and getting "d-i" |
| 18:27 |
MTecknology |
you're using the default messy mess, aren't you? |
| 18:28 |
lordcirth_work |
Um, I guess? |
| 18:29 |
|
ymasson joined #salt |
| 18:33 |
MTecknology |
I know I've said not to use that enough times so I won't beat a dead horse... further. |
| 18:34 |
|
kojiro joined #salt |
| 18:36 |
MTecknology |
I still need to build a patch for the debian installer for installing to a fully encrypted disk. There be many dragons in them th'r installer scripts. |
| 18:39 |
lordcirth_work |
MTecknology, so what do you do in your preseed? |
| 18:51 |
|
RF_ joined #salt |
| 18:51 |
MTecknology |
lordcirth_work: mine? it installs salt and nothing else |
| 18:51 |
MTecknology |
It's just included in the extra package d-i command |
| 18:52 |
lordcirth_work |
MTecknology, that's what I was doing, but getting salt-minion 2015.8.8 to upgrade itself requires using atd to workaround |
| 18:52 |
RF_ |
has anyone run into issues with salt.states.augeas.change? I am having a difficult time to get the python-augeas module installed for python2.7 on CentOS 6.9. |
| 18:52 |
MTecknology |
I also have an extra repo included higher up |
| 18:52 |
MTecknology |
s/had/have/ ... this was for $previous_employer |
| 18:52 |
lordcirth_work |
MTecknology, is there a d-i feature for adding repos and keys? |
| 18:53 |
MTecknology |
https://www.debian.org/releases/wheezy/amd64/apbs04.html.en |
| 18:54 |
MTecknology |
lordcirth_work: Think about what it takes to install salt... you add a repo, and install a package, ya? Why do you need a quarter trillion lines to make that happen in an unpredictable way? |
| 18:55 |
MTecknology |
even if you used a "bootstrap" script for that, wouldn't it make more sense to write the three lines that you need instead? |
| 18:56 |
lordcirth_work |
Ok, so now I need something to host the key. I can probably use the tftp for that |
| 18:56 |
MTecknology |
tftp seems a bit silly, doesn't it? |
| 18:57 |
MTecknology |
especially since ipxe > * |
| 18:57 |
lordcirth_work |
How so? It's already there |
| 18:58 |
MTecknology |
The tftp service on my boot server provides undionly-mtnet.kpxe and absolutely nothing else. Everything else is hosted behind nginx. |
| 18:59 |
MTecknology |
The nginx config: server { server_name _; root /srv/webapps/pxeboot; } |
| 19:00 |
MTecknology |
ipxe gives you more options, the ability to build boot configs dynamically (per node), a prettier and usable menu, and an easy way to build menus, and lots 'n lots of other goodies. |
| 19:00 |
lordcirth_work |
ipxe is on my very long todo list, yes |
| 19:02 |
MTecknology |
then don't further stick yourself on tftp! :P |
| 19:04 |
MTecknology |
"just because you can, doesn't mean you should" |
| 19:04 |
|
dezertol joined #salt |
| 19:07 |
|
RF_ left #salt |
| 19:08 |
lordcirth_work |
MTecknology, I didn't. I added -X to salt-bootstrap and it works. Revamping with iPXE and http and so on will go on the list for now. |
| 19:08 |
|
_beardedeagle joined #salt |
| 19:22 |
MTecknology |
heh.. do formulas typically expect you to have either a whole stack of config in pillar /or/ use defaults? |
| 19:22 |
coredumb |
MTecknology: depends what the formula dev decided |
| 19:22 |
coredumb |
^^ |
| 19:23 |
babilen |
You should have sensible defaults and bits that the user wants to set |
| 19:23 |
MTecknology |
do you know of one where it merges pillar into defaults in a clean/sane way? |
| 19:23 |
babilen |
There is definitely no need to copy the entirety of pillar.example, if that's what you are asking |
| 19:24 |
babilen |
MTecknology: I am happy to show you an example of code we use |
| 19:24 |
coredumb |
at least there _should_ not |
| 19:24 |
* MTecknology |
is definitely curious |
| 19:24 |
babilen |
Give me a second |
| 19:25 |
coredumb |
usually for mine, I don't care about having defaults in the formulas as I control what the default pillars should be for any server |
| 19:25 |
MTecknology |
this one seems straight forward.. https://github.com/saltstack-formulas/nfs-formula/blob/master/nfs/map.jinja |
| 19:26 |
MTecknology |
coredumb: I was trying to avoid sticking defaults into pillar, but that does make it much easier. |
| 19:26 |
coredumb |
MTecknology: well it's all a matter of global defaults or not |
| 19:27 |
coredumb |
When I stick my defaults to my node definitions, I know what needs/I want there |
| 19:27 |
coredumb |
and usually I build the formula around |
| 19:27 |
coredumb |
If I really don't want to an error, which is not often, I'll make a statement to ignore the state completely if the pillar doesn't exist |
| 19:28 |
coredumb |
think that's what's actually cool with salt |
| 19:28 |
coredumb |
do it however you want ^^ |
| 19:28 |
|
Hybrid joined #salt |
| 19:31 |
MTecknology |
My reasoning was that all minions would see all defaults for all things if I did it the way I was planning, which seemed like a large amount of data that all pillars are playing with in pillar that doesn't need to be there. |
| 19:31 |
MTecknology |
(because then everything else was just merging in top.sls) |
| 19:32 |
babilen |
MTecknology: http://paste.debian.net/1016108/ |
| 19:32 |
babilen |
Parts of the Xen states |
| 19:34 |
MTecknology |
ooooh... nice |
| 19:34 |
MTecknology |
I also had no clue we had a defaults module. |
| 19:34 |
babilen |
The things I particularly like about these are: 1. Proper (deep) merging of values with defaults.merge (L 56/57) 2. Easy to move data in YAML files if one of the *_map gets too large 3. Easy package installation option setting by passing pkg_options to the sls_block macro |
| 19:36 |
MTecknology |
The whole thing is way overkill for what I need, but this I like |
| 19:37 |
babilen |
I'm happy with it as it makes it pretty clear where certain data should live and allows users to easily tailor the defaults to their liking |
| 19:38 |
babilen |
So if you want to tailor settings based on, say, osmajorrelease, you know where .. |
| 19:40 |
|
jhauser joined #salt |
| 19:46 |
|
Hybrid joined #salt |
| 19:53 |
|
cewood joined #salt |
| 19:55 |
|
xet7 joined #salt |
| 20:05 |
|
shpoont joined #salt |
| 20:07 |
|
dezertol joined #salt |
| 20:12 |
|
shpoont joined #salt |
| 20:25 |
|
Hybrid1 joined #salt |
| 20:32 |
|
keldwud joined #salt |
| 20:33 |
keldwud |
what is the proper syntax from the command line to run "salt '<target>' cmd.run '<command>' cwd=<working directory>? |
| 20:33 |
keldwud |
I can't figure out how to set the cwd from the cli |
| 20:34 |
keldwud |
and I can't find any examples with a google search because they are all state files |
| 20:36 |
|
tyx joined #salt |
| 20:40 |
hemebond |
keldwud: Do you _need_ to set a CWD? |
| 20:40 |
keldwud |
hemebond: |
| 20:40 |
keldwud |
whoops, pressed enter too soon |
| 20:41 |
keldwud |
"ERROR: Specified cwd either not absolute or does not exist" |
| 20:41 |
keldwud |
when I'm running a cmd.run command that curls then pipes to bash |
| 20:41 |
hemebond |
Can you paste the full command you're trying to do? |
| 20:42 |
keldwud |
curl --silent --show-error --header 'x-connect-key: <key>' https://<url> | sudo bash |
| 20:42 |
keldwud |
the goal is to pull a script and then run it through bash |
| 20:42 |
hemebond |
So you have single quotes in your command. |
| 20:42 |
hemebond |
That's likely your problem. |
| 20:42 |
keldwud |
derp, yup that's it :) |
| 20:42 |
keldwud |
thank you |
| 20:42 |
keldwud |
I was double nesting single quotes |
| 20:42 |
keldwud |
that gets me every time! |
| 20:44 |
keldwud |
seems to be chugging away now, thanks hemebond ! |
| 20:44 |
hemebond |
👍 |
| 20:46 |
|
tyx joined #salt |
| 20:47 |
|
Hybrid joined #salt |
| 20:49 |
major |
okay, so, if I have a custom proxy, am I going to drop it in _modules/proxy/<name>.py ? |
| 20:49 |
MTecknology |
no |
| 20:52 |
major |
sooo .. it goes where then? |
| 20:52 |
MTecknology |
proxy.py |
| 20:53 |
major |
.. weird |
| 20:53 |
major |
and .. if I have 2 proxies? |
| 20:53 |
|
ecdhe joined #salt |
| 20:54 |
MTecknology |
why would you need multiple proxy modules instead of one module that does what they both need? |
| 20:57 |
major |
multiple device types |
| 20:57 |
major |
you know .. network switch here, router there, container over there.. |
| 20:57 |
MTecknology |
then look into using __virtual__ |
| 20:57 |
major |
thought that was required... |
| 20:57 |
MTecknology |
or don't re-use the name for different things |
| 20:57 |
MTecknology |
or make the same module handle them all |
| 20:57 |
major |
erm .. might be a misunderstanding? |
| 20:58 |
MTecknology |
you haven't really done any explaining so... probably |
| 20:58 |
major |
was trying to figure out the path to place the code into, was trying to understand if it went into _modules/ directory, or if each proxy needed to be inside the _modules/proxy/ subdirectory |
| 20:59 |
MTecknology |
you say "each proxy" like it's supposed to mean something to us.. |
| 20:59 |
major |
fair enough |
| 20:59 |
major |
each proxy module |
| 21:00 |
|
mikecmpbll joined #salt |
| 21:00 |
major |
for implementing salt.proxy.lxd, salt.proxy.netgear, etc.. |
| 21:00 |
MTecknology |
have you looked at existing modules? |
| 21:01 |
major |
yah, that is why I was sort of asking |
| 21:03 |
MTecknology |
What line of code is called when you call file.managed? |
| 21:04 |
major |
That isn't handled by this proxy minion |
| 21:05 |
MTecknology |
huh? |
| 21:05 |
MTecknology |
Is that just random or was it an attempt to answer my question? |
| 21:06 |
major |
I thought you where asking in relation to the code I was working on. |
| 21:07 |
MTecknology |
am I supposed to have a clue what code you're working on?.. |
| 21:08 |
major |
other than the prior conversation about the LXD proxy module? |
| 21:15 |
|
oida joined #salt |
| 21:33 |
|
thelocehiliosan joined #salt |
| 21:35 |
|
stack joined #salt |
| 21:36 |
|
aviau joined #salt |
| 21:36 |
stack |
hello, is that possible to have a file.recurse state in a pillar? I would like to put an entire dir targeted only to a specific minion |
| 21:39 |
|
Hybrid joined #salt |
| 21:40 |
stack |
or maybe this could be a solution https://stackoverflow.com/questions/39764078/saltstack-file-recurse-per-minion |
| 21:40 |
stack |
I'm not really sure of the security implications of the first solution, if someone can clarify if other minions can see the available dir anyway... |
| 21:41 |
whytewolf |
if it exists in the state tree. it can be seen by any minion. |
| 21:42 |
stack |
even with that if to group the state based on pillar data? |
| 21:43 |
whytewolf |
doesn't matter. if it exists in the state tree [which any salt:// source is] it can be accessed by any minion |
| 21:44 |
stack |
ok thanks for the clarification, is there any solution to the original problem? |
| 21:46 |
whytewolf |
https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.file_tree.html with a state that uses a loop with file.managed and contents_pillar? |
| 21:46 |
whytewolf |
so that the source isn't in the salt:// tree |
| 21:47 |
stack |
I'll look into it, thanks |
| 21:47 |
whytewolf |
basicly get creative |
| 21:48 |
stack |
:) |
| 21:48 |
whytewolf |
https://www.youtube.com/watch?v=9C_HReR_McQ |
| 21:49 |
|
Pomidora joined #salt |
| 21:53 |
|
KFDM left #salt |
| 21:53 |
|
xet7 joined #salt |
| 21:55 |
|
xet7 joined #salt |
| 21:56 |
|
jhauser joined #salt |
| 22:01 |
MTecknology |
is there such thing as {% from foo import conf as myconf with context %}? |
| 22:02 |
MTecknology |
heh.. soon as I asked I found it. Thanks!! |
| 22:07 |
whytewolf |
major: not sure where you got _module/proxy from |
| 22:07 |
whytewolf |
did you mean _proxy? |
| 22:09 |
whytewolf |
https://docs.saltstack.com/en/latest/ref/file_server/dynamic-modules.html <- list of dynamic module directories |
| 22:10 |
major |
whytewolf, didn't get it from anywhere, was attempting to figure out where to put stuff based on the proxy docs, but nothing really covers where to put custom proxies. |
| 22:11 |
whytewolf |
major: it is covered https://docs.saltstack.com/en/latest/ref/file_server/dynamic-modules.html and https://docs.saltstack.com/en/latest/topics/proxyminion/index.html#new-in-2016-3 |
| 22:12 |
whytewolf |
sorry that second link should be the next anchor down |
| 22:12 |
whytewolf |
"Support has been added to Salt's loader allowing custom proxymodules to be placed in salt://_proxy" |
| 22:12 |
major |
heh, yah, I found it squirreled away in there.. |
| 22:12 |
|
aldevar left #salt |
| 22:12 |
|
jhauser left #salt |
| 22:12 |
major |
had to go looking for "_proxy" to find it .. but yah, it is there |
| 22:14 |
major |
Though honestly, the more I work on this the more inclined I am to split out the salt/client/ssh/ code into salt/client/shell and salt/client/ssh and aim for something close to a 'salt-shell' to replace 'salt-ssh' and just support a variety of shell connection methods (ssh, lxc, ksh, etc) |
| 22:16 |
major |
whytewolf, thanks btw |
| 22:17 |
whytewolf |
np |
| 22:20 |
|
keldwud joined #salt |
| 22:30 |
|
edrocks joined #salt |
| 22:33 |
|
mavhq joined #salt |
| 22:41 |
|
mavhq joined #salt |
| 22:56 |
|
masber joined #salt |
| 22:57 |
|
shpoont joined #salt |
| 23:01 |
|
justanotheruser joined #salt |
| 23:06 |
|
thelocehiliosan joined #salt |
| 23:13 |
|
masuberu joined #salt |
| 23:18 |
|
masber joined #salt |
| 23:23 |
|
swa_work joined #salt |
| 23:29 |
|
masber joined #salt |
