Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-05-24

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

All times shown according to UTC.

Time Nick Message
00:06 dxiri joined #salt
00:10 MTecknology I decided I don't like keeping *ALL* file states in a separate directory, so... off to merge land!
00:11 * MTecknology vim $(for f in *; do if [[ -f "../files/$f" ]]; then printf '%s ' "$f"; cat "../files/$f" >> "$f"; rm "../files/$f"; fi; done)
00:11 * MTecknology grabs a beer and starts vimming
00:17 thinkt4nk joined #salt
00:28 woodtablet left #salt
00:40 sh123124213 joined #salt
00:40 zerocoolback joined #salt
00:45 onlyanegg joined #salt
00:48 sh123124213 joined #salt
00:49 walker joined #salt
00:50 c_g joined #salt
00:54 MTecknology Success!!
01:05 zerocool_ joined #salt
01:07 zerocoolback joined #salt
01:08 akunin joined #salt
01:09 mage__ joined #salt
01:12 akunin quick jinja question... trying to check if a file exists with the filename being a jinja var i get syntax error:  {% if salt['file.file_exists' ]( {{ filename }} ) %}
01:15 onlyanegg joined #salt
01:17 akunin joined #salt
01:20 akunin joined #salt
01:22 MTecknology akunin: no {{ }}
01:22 akunin MTecknology: oh duh! thanks... happened to me before :(
01:23 c_g joined #salt
01:25 feld_ left #salt
01:30 onlyanegg joined #salt
01:46 akunin joined #salt
01:48 ilbot3 joined #salt
01:48 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.3.6, 2016.11.5 <+> Support: https://www.saltstack.com/support/ <+> SaltStack Webinar on Carbon, Nitrogen, and Enterprise 5.1 on May 18, 2017 https://goo.gl/PvsOvQ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic <+> Due to spam, please register with NickServ
01:55 dxiri_ joined #salt
02:02 mpanetta joined #salt
02:05 akunin joined #salt
02:10 akunin joined #salt
02:13 zerocoolback joined #salt
02:36 onlyanegg joined #salt
02:37 cro joined #salt
02:43 akunin joined #salt
02:44 cro joined #salt
02:44 masber joined #salt
02:48 akunin joined #salt
02:49 walker joined #salt
02:53 akunin joined #salt
02:55 walker joined #salt
02:56 _JZ_ joined #salt
02:58 cyborg-one joined #salt
03:00 akunin joined #salt
03:03 evle joined #salt
03:04 SaucyElf joined #salt
03:04 om2 joined #salt
03:05 walker joined #salt
03:06 taylorbyte1 joined #salt
03:21 preludedrew joined #salt
03:32 miruoy joined #salt
03:35 Praematura joined #salt
03:41 onlyanegg joined #salt
03:43 dxiri joined #salt
03:47 dxiri joined #salt
03:49 sh123124213 joined #salt
04:16 mavhq joined #salt
04:54 fracklen joined #salt
04:56 Guest73 joined #salt
05:11 SaucyElf joined #salt
05:12 pheonix991 joined #salt
05:13 pheonix991 joined #salt
05:14 icebal joined #salt
05:15 jas02 joined #salt
05:18 Terminus joined #salt
05:29 Bock joined #salt
05:30 felskrone joined #salt
05:32 sh123124213 joined #salt
05:34 zerocoolback joined #salt
05:38 rgrundstrom joined #salt
05:38 rgrundstrom Good morning.
05:44 onlyanegg joined #salt
05:55 Lionel_Debroux joined #salt
06:06 aldevar joined #salt
06:06 sh123124213 joined #salt
06:06 swa_work joined #salt
06:07 capnhex joined #salt
06:10 Hydrosine joined #salt
06:12 capnhex1 joined #salt
06:26 yuhl joined #salt
06:28 SaucyElf joined #salt
06:31 dxiri joined #salt
06:37 hoonetorg joined #salt
06:46 gnomethrower joined #salt
06:46 whytewolf it will be soon
06:49 fracklen joined #salt
06:55 candyman88 joined #salt
06:56 muxdaemon joined #salt
07:00 hemebond 11:330pm again?
07:02 whytewolf nope, 23:46 when i posted that
07:03 Ricardo1000 joined #salt
07:06 pbandark joined #salt
07:09 pbandark joined #salt
07:10 ronnix joined #salt
07:12 ronnix_ joined #salt
07:20 jas02 joined #salt
07:27 fredvd joined #salt
07:31 Ricardo1000 joined #salt
07:33 fracklen joined #salt
07:35 capnhex joined #salt
07:35 Ricardo1000 joined #salt
07:44 garethhowell joined #salt
07:44 fxhp joined #salt
07:47 onlyanegg joined #salt
07:47 jas02_ joined #salt
07:48 jas02 joined #salt
07:48 LondonAppDev joined #salt
07:58 jas02 joined #salt
08:03 mikecmpbll joined #salt
08:03 capnhex joined #salt
08:06 oida joined #salt
08:07 hrumph joined #salt
08:08 fracklen joined #salt
08:08 fracklen joined #salt
08:10 teclator joined #salt
08:11 ronnix joined #salt
08:16 jas02_ joined #salt
08:19 tobiasBora joined #salt
08:23 rgrundstrom joined #salt
08:29 N-Mi joined #salt
08:29 N-Mi joined #salt
08:29 Mattch joined #salt
08:30 jas02 joined #salt
08:37 kedare joined #salt
08:37 kedare Hi all :)
08:38 kedare I have an issue with SaltStack and I don't know what do to... I'm getting a "Data failed to compile" but everything looks fine in my sls file
08:38 Reverend can i see it?
08:38 kedare I'm pasting it with the error :)
08:39 Reverend hastebin me son
08:39 Reverend :D
08:40 kedare https://gist.github.com/kedare/7564a9a02ead86701a888b313fb997c4
08:41 Reverend Rendering SLS 'base:windows.services.iis.sites' failed: while parsing a block mapping <-- that's usually because you're missing a colon somewhere
08:41 Reverend IIRC
08:42 kedare In the SLS or in the pillar ?
08:42 Reverend it looks like it's in the sls.
08:42 Reverend expected clock end but found ,..... hmm
08:42 kedare Because I don't see where I would need one in the SLS
08:43 babilen kedare: Where does your pillar data come from?
08:43 kedare And the colon thing it's complaining about it's like in the JSON version of the pillar
08:43 Reverend json pillar?
08:43 kedare From defined pillars, on another file
08:43 Reverend is that thing...
08:43 kedare Yaml too
08:43 Reverend :o
08:43 kedare The thing is that they are all correctly defined when I use pillar.items
08:43 babilen So you use standard pillars?
08:43 kedare And I don't have any error anywhere else
08:44 kedare I define pillars in .sls
08:44 kedare (Separated from the state)
08:44 babilen One thing you might want to try is to not rely on the yaml parser library to get things right, but to mark and format all strings explicitly
08:45 xet7 joined #salt
08:45 babilen Either by using string concatenation ('foo' ~ 'bar') or by using |format(arg1, arg2, ...)
08:46 kedare For the template variables you mean ?
08:46 babilen Oh, and the pillar["iis"]["sites"] could be salt['pillar.get']('iis:sites', [])
08:47 babilen kedare: I am referring to the string literals in the SLS
08:48 babilen C:\inetpub\wwwroot\staging\ is the most obvious example
08:49 babilen You also use {{ site["name"] }} on line 22 and {{ site }} on line 30
08:49 babilen Isn't 'site' a dictionary?
08:50 kedare Yes, I need to fix the line 30 :)
08:50 babilen So that would result in multiple colons (i.e. the dictionary) being present in the state ID
08:51 kedare I think that was the issue :)
08:53 babilen I'm quite sure it was :)
08:54 kedare Weird that it complained on the line of the one that was correct
08:56 babilen There was probably an issue determining block boundaries
09:01 teclator joined #salt
09:16 dubg joined #salt
09:17 kedare It's weird that the win_iis module doesn't feel very DSC
09:17 kedare As it's more thing like create_xxx remove_xxx so if you just need to change something it's more complicated
09:20 losh joined #salt
09:24 mage__ left #salt
09:27 ronnix joined #salt
09:34 capnhex joined #salt
09:39 LondonAppDev joined #salt
09:47 kedare Also there is something, I don't know if this is a bug
09:47 kedare Related to win_iis
09:47 Diaoul joined #salt
09:47 chowmein__ joined #salt
09:47 kedare Basically you have websites and on websites you can create "applications" in subdirectories, if you define for example "/api" as application name, it will work fine but SaltStack will shown it as failed because it will retrieve the name as "api" and not "/api"
09:47 mbologna joined #salt
09:48 kedare Or if it's expected, maybe this should be added to the documentation as this is not very clear (That the name is the path, and that it should not contain the prefix "/")
09:48 onlyanegg joined #salt
09:57 LondonAppDev_ joined #salt
09:59 babilen kedare: So essentially the state works as expected and succeeds, but its being flagged as "failed" ?
10:02 kedare Yes
10:03 babilen I'd say that's a bug in the module/state
10:03 babilen Or would you normally name an application "/api" and it is a mere coincidence that "api" also works?
10:03 kedare It's quite confusing because the "name" is actually the "path" attribute
10:04 kedare It work in both case but when using it as a path like /api, it's shown as failed
10:05 kedare Because I suppose when SaltStack try to get the state after the operation it gets "api" and not "/api"
10:05 cyborg-one joined #salt
10:06 kedare Because even in IIS it's not consistent
10:06 kedare Sometime you will see api, sometime /api
10:07 kedare And at powershell level, you can use any of both, they'll do the same (That's what SaltStack is doing)
10:08 babilen Sounds as if you want to consistently use it with /
10:09 om2 joined #salt
10:10 StucKman joined #salt
10:12 lasseknudsen joined #salt
10:12 StucKman hi, I'm using a salt setup done by the IT guy here, who is not present. I'm trying to run this: https://paste.debian.net/937806/ I don't understand where the orchestration_jid param comes from or how to work around it, any ideas/
10:12 StucKman ?
10:14 StucKman more info here: https://paste.debian.net/937816/
10:15 StucKman and without the alias the error persists
10:15 babilen StucKman: Is "orchestration_jid" mentioned anywhere in your file roots?
10:16 StucKman good point
10:16 StucKman nop-e
10:17 StucKman couold be somehting in the local config?
10:18 StucKman nothing
10:19 babilen What about orchestration or orch? You could also cut down on states and figure it out that way.
10:19 StucKman I'm quite new to salt, I'll try to do that
10:21 babilen Something I'd check first though is if the minion version is the same as the master version. You can run "salt-call --versions-report" on the minion and compare that to "salt --versions-report" on the master
10:21 babilen They might just be out of sync and not compatible anymore
10:21 StucKman babilen: it should be, we run the same debian version everywhere
10:22 babilen Should be easy to check
10:22 StucKman ok, 2016.11.2 vs 2016.11.4 not much
10:23 StucKman and the minion is usually configured this way
10:23 StucKman but then I don't know when it was upated the last time
10:23 babilen Could you update it?
10:23 babilen (the salt-minion package that is)
10:24 StucKman i better not, this is the mail server, no mail, I'm dead
10:24 babilen And as always: What changed in between "It worked" and "It hisses and screams and refuses to lift a finger" ? :)
10:26 babilen Updating the salt client should™ have no effect on any other running services, fwiw
10:26 StucKman I know
10:27 StucKman but I'm leaving for vacations now, I have some tasks to finish, and any problem now would be fatal
10:27 StucKman I'm just erring on the safe side
10:27 babilen Downgrade the master?
10:27 babilen Run this in a test setup?
10:28 StucKman no test setup, sorry
10:28 babilen Fire up two vagrant boxes and check the behaviour there ..
10:28 StucKman i wish I had one
10:28 babilen Shouldn't be too tricky
10:28 StucKman I really don't have the time, I appreciate the soulition ou propose
10:28 StucKman I wish I had
10:29 dendazen joined #salt
10:30 babilen When did you run the last successful highstate on that minion?
10:32 ProT-0-TypE joined #salt
10:32 babilen Checked the diff between .2 and .4 and no changes that involve orchestration_jid arguments are obvious
10:38 babilen StucKman: Does the same happen if you run "salt-call state.apply test=True" on the minion?
10:40 teclator joined #salt
10:44 babilen My gut feeling is that this would be resolved by upgrading the minion
10:47 Praematura joined #salt
10:57 Trauma joined #salt
11:09 inad922 joined #salt
11:12 lorengordon joined #salt
11:42 Joy hmm, so if state.show_sls says that a (prereq'd) state has order 10000 and everything else comes later
11:42 Joy and then state.apply does NOT do that but instead runs 4 other states before the prereq'd state
11:42 Joy what do i do?
11:43 Joy use case: i need to service postfix stop, move /var/lib/postfix around, service postfix start
11:43 Joy yet it happens #2, #1, #3
11:44 Neighbour Joy: See if this patch fixes your issue: https://pastebin.com/twBNA2wL
11:44 Neighbour I've had problems with prereqs not working properly, and this fixed it in my case
11:45 swills joined #salt
11:46 om2_ joined #salt
11:46 babilen Neighbour: Why do you test for length there?
11:47 babilen (empty lists are false)
11:47 Neighbour babilen: that's still on my todo :)
11:48 Neighbour this was the closest match to what I needed to check (to be rewritten later)
11:48 Neighbour also, it needs to check for ['changes'] as well as ['pchanges'], but I'm not sure pchanges is used everywhere else in salt
11:48 onlyanegg joined #salt
11:49 teclator joined #salt
11:50 babilen Fair enough :)
11:50 Udkkna joined #salt
11:50 majuscule joined #salt
11:51 stotch joined #salt
11:51 Neighbour babilen: I remember reading somewhere that 'pchanges' (predicted changes) was to be used when running in test-mode, which is what happens with prereq's...but I can't find it anymore..Do you know if this is (still) true?
11:52 gnomethrower joined #salt
11:52 babilen Not entirely .. where did you read it?
11:52 Neighbour If I remembered that, I could verify it myself :)
11:53 Neighbour ah, here: https://docs.saltstack.com/en/latest/ref/states/writing.html
11:53 Neighbour right above the 'Test state' paragraph
11:54 Neighbour Though I'm not sure all salt states use this (including the prereq-mechanism)
11:56 zerocoolback joined #salt
11:56 zerocoolback joined #salt
11:56 zerocoolback joined #salt
11:57 zerocool_ joined #salt
11:58 muxdaemon joined #salt
12:00 thinkt4nk joined #salt
12:03 ronnix joined #salt
12:04 numkem joined #salt
12:05 Thana_ joined #salt
12:06 ravenx joined #salt
12:07 ravenx for file.managed, if i have a template that needs to be filled with defaults.yaml's values
12:07 ravenx is it possible to have those two files in the minion?
12:07 ravenx file.managed manages "app.config"  and inside app.conf is just a template waiting for {{ data.value }}
12:07 dxiri joined #salt
12:08 ravenx can the defaults.yaml be located minion side?
12:13 babilen Nope
12:14 ravenx gaaaah
12:14 ravenx so all these key values no matter what must be from master side
12:14 ravenx like /srv/
12:14 Neighbour (yes, they can, but it's not pleasant)
12:14 ravenx Neighbour: just how unpleasant?
12:14 StucKman left #salt
12:14 Neighbour you'd better load the yaml in your statefile and apply it there
12:15 ravenx loading the yaml in the statefile, that's kinda how it's being done by default right?
12:15 Neighbour with {% import_text 'filename' as variable %}
12:15 ravenx ah okay
12:15 ravenx yeah so i'm sorta doing that with default
12:15 ravenx defaulys.yaml
12:17 Neighbour getting a file to a minion can be done using https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cp.html#salt.modules.cp.cache_file
12:17 ravenx true
12:17 ravenx but how can i then, get file..managed to read it?
12:18 Neighbour the doc says that cp.cache_file returns the location of the new cached file
12:18 Neighbour but as you can see, this is getting uglier and uglier :)
12:19 ravenx ah true....
12:19 ravenx yikes :/
12:19 Neighbour better load the defaults file (and if it's a yaml-file, don't use import_text, but import_yaml) like demonstrated here: https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html
12:21 babilen ravenx: You can obviously access files on the minion, but the "normal" defaults.yaml can't just be placed on the minion
12:21 babilen You need different code for that
12:21 babilen What are you trying to achieve ?
12:22 ravenx what i'm trying to achieve is this:
12:22 ravenx through my saltmaster, i do a git pull of my repository's code and build it
12:22 evle joined #salt
12:22 ravenx this is all done via a state.sls call and it gets our code and builds it successfully...
12:22 ravenx now the last step i'm missing is managing our config files for this app that just got cloned
12:23 babilen Obviously you'd define that in the minion's pillar?
12:23 zulutango joined #salt
12:23 ravenx right now, i have a /srv/salt/ repo, where the default.yaml is stored whcih contains the values for my app's config.  if a developer wants to change a config, they will also need to git clone/push my /srv/pilar repo
12:23 ravenx i would like it so that every change, including configs is done in the app's repo.
12:24 ravenx so that: i git pull to the  minions via the state.sls and have the file.managed look into that repo after it's cloned and generate that config
12:24 babilen You could include a subdirectory in the "app"'s git repo as external pillar
12:24 ravenx ooh la la
12:24 ravenx you might be onto something here
12:24 Joy Neighbour: woah, that was quick! is this from some bug/pullreq?
12:24 Joy i want to do a modicum of justice to it if it works
12:25 ravenx babilen: if i do do that, can i set it for multiple projects?
12:25 Joy (by upvoting)
12:25 babilen ravenx: Set what exactly?
12:26 ravenx set external pillars for each repository i have?
12:26 ravenx cuz i got like 5 apps or so
12:26 c_g joined #salt
12:26 c_g joined #salt
12:27 babilen ravenx: In the end SaltStack doesn't care where the data is coming from. It would just expect data (in some format) to be present at the given location and it would merge that data together. How you distribute it is entirely up to you.
12:27 jas02 joined #salt
12:28 dendazen joined #salt
12:28 ravenx i see
12:28 nicksloan joined #salt
12:28 ravenx thanks, imma take a look at git pillar, to see if that fits the bill
12:29 babilen My impression was that you want to bundle those "settings" with the code in the same repository, rather than requiring developers to maintain them in a special "pillar" repo.
12:30 babilen See https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.git_pillar.html#configuring-git-pillar-for-salt-releases-2015-8-0-and-later and, in particular, the "root" setting in the branch/env setting block
12:30 Joy Neighbour: unfortunately, there was no effect, the order still didn't work
12:30 Joy Neighbour: i'll have to write up a bug report. is there one already?
12:30 ravenx babilen: exactly.  you impression is correct
12:30 Neighbour Joy: there are a number of bugreports on prereq not working properly, you'd have to check if your specific issue is not yet present
12:31 ravenx babilen: after readign that though, my question remains unanswered and that is, can i have different git repos:   app1, app2, app3
12:31 ravenx cuz in this example, it seems like it is only the same repostiory, but differnet branches
12:32 babilen ravenx: You can do that same for GitFS .. that would allow you to have, for example, a "salt/states" and "salt/pillar" directory in your app repo that could both be served as file/pillar root to clients
12:32 babilen You can include as many git repositories as you want
12:33 ravenx i suppose what i'm confused about is
12:33 ravenx how it looks in the /etc/salt/master config
12:34 ravenx what i imagine is, something like this:https://paste.debian.net/938044/
12:34 ravenx but how would salt know to match app1's pillar data to the app1 state.sls i just called
12:36 babilen Obviously by accessing "ravenxsuperapps:app1:foosetting" and "ravenxsuperapps:app2:foosetting" respectively (essentially a unique namespace per application)
12:36 ravenx ahh
12:36 ravenx that's what i'm wondering, yes
12:36 babilen If they won't ever be present at the same minion you could just handle this entirely with targeting so that "ravenxsuperapps:foosetting" would just be "right" for that minion/app
12:36 ravenx the namespace
12:37 ravenx it seems that there isn't a place to specify it though...
12:37 ravenx on the config i just showed you
12:37 babilen You would do that in the pillar definition
12:37 ravenx i'm at a loss at understanding how does it differentiate?  cuz i'm just practically pasting 3 different git urls in there
12:37 ravenx you mean in /srv/pillar?
12:38 babilen Well, in this example the pillars are coming from some-repo/salt/pillar and the data in there would simply be namespaced
12:39 ravenx so in the repo of app1:     app1/salt/pillar/values.sls    and in there, it would be:     server: www.asdf.com    port: 1234
12:39 ravenx then i will use it like app1:server
12:40 LondonAppDev joined #salt
12:42 ravenx that means that if i pass it a list it will simply just use the namespace of the repository's name
12:43 ronnix joined #salt
12:43 thinkt4n_ joined #salt
12:48 babilen In app1/salt/pillar/values.sls you'd have "app1: server: .... port: ..." if you want it namespaced
12:49 ravenx aaaah
12:49 ravenx i see
12:49 ravenx the namespacing happens in the values.sls
12:49 ravenx second question, and i hope it's the last
12:49 ravenx how do i pass in multiple git pillars in /etc/salt/master?
12:49 ravenx was my fi rst way correct?
12:50 babilen That is if you need the namespace .. If you only ever have a single app on the minion you wouldn't have namespace collisions
12:50 ravenx nahi have a buncha apps on one.
12:51 babilen You just have to make sure that they use a unique key to access their data
12:51 ravenx gotcha
12:55 ssplatt joined #salt
12:55 Joy Neighbour: i've tried to find it and i'm afraid i'll have to file a new one, nothing matches precisely
12:58 Neighbour Joy: Ok, please do then, and thanks for digging into the other issues to verify it :)
13:01 nicksloan joined #salt
13:01 poseur joined #salt
13:04 palsveningso joined #salt
13:09 Joy Neighbour: i've been reading over https://docs.saltstack.com/en/latest/ref/states/requisites.html#prereq and have come to the conclusion that prereq is completely broken by design?!
13:09 Joy If the "changes" key contains a populated dictionary, it means that the pre-required state expects changes to occur when the state is actually executed, as opposed to the test-run. The pre-requiring state will now actually run. If the pre-requiring state executes successfully, the pre-required state will then execute.
13:10 racooper joined #salt
13:10 Joy so in my scheme, service.dead is the pre-required state, and shuffle-directories is the pre-requiring state
13:12 m4rk0 joined #salt
13:14 Neighbour Joy: that particular paragraph is a real pain to read properly
13:14 Neighbour but shuffle-directories should be the prerequired state, and service.dead the prerequiring state
13:15 Neighbour as service.dead is pre-requiring shuffle-directories to expect to make changes
13:16 debian112 joined #salt
13:16 Neighbour so service.dead checks its prereqs, runs shuffle-directories in test-mode, notes that it expects changes. Then service.dead actually executes, and if succesful, shuffle-directories is executed
13:17 Joy so you mean just invert my relationships and everything will be fine?
13:17 Neighbour it's easy enough to try :)
13:17 Joy certainly, but that's so painfully wrong
13:18 Joy but then how do i hook up the later restart?
13:18 Joy watch on the service.dead?
13:18 Joy maybe i'm overthinking it, i'll just test until my brain explodes
13:18 Neighbour use listen_in: [ service.start ] in shuffle-directories
13:19 megamaced joined #salt
13:19 Neighbour (well, not literally service.start, but service: <ID of your service-starting code>)
13:19 KennethWilke joined #salt
13:24 edrocks joined #salt
13:24 Joy ok, so in my final rule just replace watch with listen to make sure it doesn't try to reorder
13:24 Cottser joined #salt
13:28 manji joined #salt
13:29 inconspicuous_ci joined #salt
13:31 inconspicuous_ci joined #salt
13:31 brousch__ joined #salt
13:32 Neighbour Joy: And, is it working?
13:48 m4rk0 Hello
13:48 Brew joined #salt
13:49 m4rk0 Please tell me what's best practice to set global variable inside pillars? So I can use them in other pillars?
13:49 onlyanegg joined #salt
13:51 amcorreia joined #salt
13:52 Neighbour I'm not quite sure I follow...all (minion- and environment-applicable) pillars are mashed together and form one pillar...there are no 'global' or 'local' pillar variables
13:52 Neighbour form one pillar for the specific minion and environment you targeted
13:53 m4rk0 I mean Jinja variables inside pillar {% set VAR = 'var' %}
13:54 zerocoolback joined #salt
13:58 Neighbour Hmm, you might want to check out jinja's "extends"...but I have no experience with it myself
13:59 Joy Neighbour: nope, still broken, i was just typing out the bug report
14:00 Joy Neighbour: i'm also proofreading my state file to see if i did something else to confuse it
14:01 rjarry joined #salt
14:01 vlebo joined #salt
14:01 nicksloan joined #salt
14:02 Joy Neighbour: https://github.com/saltstack/salt/issues/41406
14:04 nicksloan joined #salt
14:04 johnkeates joined #salt
14:06 jas02 joined #salt
14:06 Neighbour Joy: Nice, looks like a clear and concise issue-report. Thanks :)
14:06 Neighbour Now let's hope someone will find out why things go awry
14:08 Neighbour Hm, the pastebin link was only valid for one hour, so you don't have to include that in the issue-report (it wasn't working anwyay)
14:09 Joy oh well
14:11 nicksloan joined #salt
14:12 pbandark hi.. i want to exeuce `/bin/bash /tmp/ibm-java-sdk-8-archive.bin -i silent -f /tmp/ibm-java-sdk-8.txt 1> /var/log/j9.log` command on minion. I tried with cmd.run but its failing.
14:12 pbandark "TypeError: execve() arg 3 contains a non-string value" <==
14:16 nicksloan joined #salt
14:18 m4rk0 Okay, thanx
14:18 babilen m4rk0: Pillarstack comes in handy for that (if you render external pillars first)
14:20 dfinn joined #salt
14:20 thinkt4nk joined #salt
14:22 m4rk0 babilen, okay thanx for tip
14:25 nicksloan joined #salt
14:31 pbandark anyone ?
14:31 GnuLxUsr joined #salt
14:35 Rumbles joined #salt
14:36 sarcasticadmin joined #salt
14:37 babilen pbandark: Could you show us your state and the relevant output from calling it on the minion with "salt-call -ldebug state.sls your.state.foo" ?
14:41 pbandark babilen: ok. let me check
14:43 jas02 joined #salt
14:44 ronnix joined #salt
14:45 crnkyadmin joined #salt
14:49 dxtr joined #salt
14:50 fxhp joined #salt
14:50 dxtr Can I somehow specify multiple states to state.apply?
14:51 m4rk0 One more question... I have pillar defined like https://pastebin.com/Nc4eX1N6 ... and when I highstate n02 server it collects definition from n01 ... how to fix this?
14:52 numkem joined #salt
14:53 lorengordon dtxr: just comma separate the states: state.apply foo,bar,baz
14:54 lorengordon dxtr: oops. ^
14:57 pbandark babilen: it seems to be identation issue which I fixed in the sls file. but, I observed that, env variable which I set using "env" is not effective. https://paste.fedoraproject.org/paste/OB8lYWY7omluOwzjIr5XZ15M1UNdIGYhyRLivL9gydE=
14:57 pbandark can you check if the syntax is correct ?
14:59 dxtr lorengordon: I love how that was the only thing I didn't try
14:59 dxtr Thanks
14:59 m4rk0 Can someone answer my question?
15:03 Reverend m4rk0 patience young one.
15:04 Reverend also, use hastebin instead -_-
15:04 nicksloan joined #salt
15:05 Reverend I don't see anything wrong with your jinja. Have you tried running `salt \* grains.get id` to see what you get back m4rk0 ?
15:05 Neighbour pbandark: You might want to specify the shell you want to run this in
15:05 Neighbour (depends on what the 'shell' grain is though, and if that can handle redirects)
15:06 numkem joined #salt
15:06 pbandark i dint get you Neighbour. where I need to specify the shell ?
15:07 Neighbour pbandark: in the cmd.run function call, as is described on https://docs.saltstack.com/en/latest/ref/states/all/salt.states.cmd.html#salt.states.cmd.run
15:07 pbandark shell:      /bin/bash <== from grains
15:07 Neighbour ah, that should be able to handle it just fine
15:08 Neighbour no need to specify it then
15:08 m4rk0 Reverend, omg ... I'll say only that :) My brain stuck in loop and reading wrong id all the time :D
15:08 Neighbour pbandark: You could try and put quotes (') around the command itself
15:08 pbandark ok let me check
15:09 chrysanthemum joined #salt
15:09 raspado joined #salt
15:10 cyborg-one joined #salt
15:10 Neighbour pbandark: The state seems to work fine on my 2016.11.5 salt-minion (though with an empty executable file)
15:11 Neighbour pbandark: also, the prefixed '/bin/bash' in the command is not neccesary, as the command is executed in a bash shell anyway
15:11 cyteen joined #salt
15:12 pbandark Neighbour: command is successful but the output is not getting redicted to file. I am suspecting something wrong with the env variable i have defined
15:12 Reverend m4rk0 - lol fail xD
15:13 m4rk0 BIG one :D
15:13 pbandark Neighbour: if I run everything manually(setting variable and executing command) then I can see output is getting redirected
15:14 Neighbour pbandark: Odd, if I make /tmp/ibm... a simple shellscript that echo's something, I find that back in the logfile it gets redirected to
15:14 Neighbour which version of salt are you using?
15:14 pbandark salt 2016.11.3 (Carbon)
15:15 pbandark salt-minion 2016.11.5 (Carbon)  <== on minion
15:15 Neighbour it gets executed on the minion, so that should be fine
15:15 lorengordon joined #salt
15:15 Neighbour maybe you also want to redirect stderr?
15:17 pbandark you mean "1>/var/log/j9.log 2>&1"
15:18 Neighbour yes, or use "&> /var/log/j9.log"
15:18 Neighbour which is semantically the same
15:18 dfinn i'm running into an issue where when we restart puppet via salt, the locale is getting set to C which causes problems for puppet.  i'm trying to write a simple salt module to restart puppet and set the LC_ALL env variable and I can't for the life of me figure out the right way to do that.
15:18 dfinn here's my module : https://pastebin.com/BfWZMnEM
15:19 dfinn and you can see in the comments the different ways I've attempted to set the env variable, none of which have worked
15:22 vlebo joined #salt
15:23 numkem joined #salt
15:23 coval3nce joined #salt
15:23 impi joined #salt
15:24 dyasny left #salt
15:26 raspado i have a custom grain, once I put it in /etc/salt/grains, anyway how to enable it?
15:26 raspado or does it just get picked up automatically
15:29 SaltNPeppa joined #salt
15:31 lovelyday joined #salt
15:37 onlyanegg joined #salt
15:38 whytewolf raspado: restart the minion. [and next time use a module to change the grain and it will be picked up automaticly in the next highstate. there is a state module and a exacution module for changing grains]
15:38 whytewolf dfinn: couple of things. a. try adding python_shell=true to the cmd.run or alternativly look at adding the enviroment to the init script. which would be the more consistent way of doing it.
15:39 whytewolf dfinn: also, instead of editing your module over and over again try using the cmd.run module directly to ge tthe right settings
15:39 whytewolf then use those
15:43 dfinn ok, let me give that a try
15:43 dfinn I'd really prefer not to modify the startup script, that means having to manage it on a whole bunch of servers when it "normally" works just fine, aside from when run from salt
15:44 MTecknology dfinn: Can't you just modify the init script to set the variables you need?
15:45 dfinn python_shell=true didn't change anyhting, I still end up with LANG emtyp
15:45 MTecknology a bit hacky, but it'd be trivial
15:45 SaucyElf joined #salt
15:45 raspado thanks whytewolf, quick q... lookin at the metadata grain, it states to set metadata_server_grains: True in https://docs.saltstack.com/en/develop/ref/grains/all/salt.grains.metadata.html, do I need to set that as a grain on all the minions?
15:45 dfinn I could MTecknology but it's not that trivial when you're talking about 100s of hosts on multiple flavors of linux
15:45 MTecknology uhm....
15:45 pbandark Neighbour: working now.   me-- "-" were missing for env variables.
15:45 MTecknology that doesn't compute in this channel
15:45 dfinn this salt module should have been a simple thing but for some reason it's quite difficult to get the env variable set
15:47 whytewolf dfinn: it is a trivial thing when you are a real user on a box. but you are trying this from daemon space.
15:47 MTecknology Another cheap easy hacky solution would probably to use sudo to execute the command and tell it to load the user's env before running the command, instead of current env.
15:47 dfinn if I run this with cmd.run : "export LC_ALL="en_US.UTF-8" && service puppet restart' runas=root"  then it does work but I can't figure out how to do that inside my module because it doesn't know the export command
15:47 dfinn i did try running /bin/bash first which I hoped would load up all the env variables but that didn't work
15:48 dfinn i tried /bin/bash service puppet restart
15:48 * MTecknology said sudo.. not bash
15:48 dfinn yeah, saw that.  hoping to not have to use sudo
15:48 dfinn let me try it though
15:50 whytewolf so, salt.cmd.run('export LC_ALL="en_US.UTF-8" && service puppet restart',runas=root,python_shell=true,shell=/bin/bash) in thoery
15:51 dfinn going through sudo does not work either
15:51 dfinn ok, i'll give that a try whytewolf
15:51 whytewolf if that doesn't work, then you have something else going on. because that would be how the cmd.run you exacuted would run in the salt cmd.run
15:52 dfinn that syntax you gave, is that for inside the module or on the CLI?
15:52 dfinn the CLI didn't like that
15:52 whytewolf that was inside the module
15:52 dfinn ok
15:52 whytewolf basicly breaking down the cmd.run you gave
15:53 dfinn that doesn't work in the module
15:53 whytewolf i might have missed some '
15:53 dfinn let me check the minion log to see why
15:53 whytewolf it is still morning
15:53 whytewolf and i havn't had coffee
15:54 MTecknology TEA!! I need tea!
15:54 * MTecknology hugs whytewolf
15:54 dfinn https://pastebin.com/ZtNNNu91
15:54 dfinn i think you got all the required '
15:55 whytewolf yeap i forgot some quotes
15:55 whytewolf shell='/bin/bash'
15:55 whytewolf runas='root'
15:55 aldevar left #salt
15:56 dfinn NameError: global name 'salt' is not defined
15:56 dfinn I think I ran into that yesterday and it's when I switched to __salt__
15:56 whytewolf ... I am awake did i say that
15:56 whytewolf __salt__['cmd.run']
15:56 dfinn so maybe it needs to be __salt__['cmd.run']
15:56 nicksloan joined #salt
15:58 dfinn looks like true may need to be in quotes too
15:58 whytewolf it shouldn't be
15:58 whytewolf iirc it is a bool
15:58 dfinn it did need that to stop complaining
15:58 dfinn it's working now
15:59 dfinn and FFS, it's still not setting the LANG correctly
15:59 dfinn gah!
16:00 SaltNPeppa left #salt
16:01 whytewolf so, yeah. at this point. i would look into the init scripts at this point. because i have no idea why it is stripping your env setting. the env setting yesterday should also have worked. as that sets it in the shell before running the command with out needed to set it in the command.
16:02 whytewolf there is something strange afoot at the circle k
16:02 whytewolf selinux?
16:02 SaltNPeppa joined #salt
16:02 SalanderLives joined #salt
16:02 dfinn nope
16:02 dfinn nothing weird about the init script in regards to env variables, we are using the out of the box puppet init script
16:02 dfinn restarting manually on the server using the service puppet restart gets us what we need
16:02 dfinn it's only when restarting via salt
16:02 whytewolf and also. this is a setting that should be in the init script already. if it messes up the way puppet works.
16:03 dfinn I think I've probably spent way more time on this than I should have, probably just gonna move along
16:03 impi joined #salt
16:03 wonko21 joined #salt
16:03 dfinn well, we have /etc/default/locale set to how we need.  that makes everything work and be happy except salt
16:04 lovelyday Trying to run the following code (https://gist.github.com/wimurphy/bada34f170adc97d7e1de06840912802) through salt. When I run it through Windows, it properly applies the binaries but when I run it through Salt it does nothing. It doesn't fail as there is no error log, it just doesn't do anything. Any guesses?
16:06 whytewolf dfinn: thing is dfinn when you tried sudo. you were two steps removed from salt enviroment
16:07 whytewolf something else stripped your LC_ALL
16:07 feld_ joined #salt
16:07 dfinn i'm following what you're saying but I can't figure out in my head why it would only happen when run via salt
16:09 whytewolf also it is strange you said it worked in a cmd.run on the command line
16:09 whytewolf that is through salt also
16:10 dfinn yes, it does work if we export the variable first then run the command
16:10 dfinn but doing that same thing via the module does not work
16:10 dfinn i even just tried it again with sudo -i -u root to fully load the root users environment, still end up with a blank LANG
16:11 whytewolf umm, -i is interactive. you want -H
16:11 dfinn people always think -i is interactive.  it's not really
16:12 dfinn https://linux.die.net/man/8/sudo
16:12 Trauma joined #salt
16:13 dfinn -i should have got me everything that is normally setup for a user login
16:14 muxdaemon joined #salt
16:15 MTecknology lovelyday: What's your state?
16:15 whytewolf so, about -i [which actually is i for interactive.] i wasn't saying it shouldn't gt what you want. I'm saying it shouldn't be used because it recreates a full login shell including dropping a prompt which is not good for internal programs
16:16 whytewolf -H should get you the full enviroment with out the full prompt
16:16 MTecknology I thought -H was /just/ $HOME
16:17 raspado I added the custom metadata grain into /etc/salt/grains but im not seeing aws grains in my minion. I did add grain to the minion "metadata_server_grains: true" any thing I can do to troubleshoot why Im not seeing the metadata grains?
16:17 whytewolf did they change that? it didn't use to be home
16:18 MTecknology raspado: Did you restart salt?
16:18 whytewolf [although it is called HOME] but it normally loaded the full home enviroment.
16:18 raspado MTecknology: the salt server? no the salt minion, yes
16:18 raspado bounce salt server for new grains?
16:19 MTecknology I thought, in pretty much all cases, that was the one thing that was typically missing for commands to be nice and happy run as a different user
16:19 edrocks joined #salt
16:19 MTecknology since there are other environment variables that sudo always alters
16:20 timfi joined #salt
16:20 dfinn -i does most definitely not drop you to a prompt whytewolf
16:21 MTecknology s/drop you to a prompt/executes the login shell/
16:21 dfinn ok, that may be more accurate but that's a huge difference
16:22 MTecknology true, and none of this really matters since you tried with -i, it didn't work, and that's the whale of a band-aid option when it comes to using sudo to solve the problem
16:22 dfinn yup
16:22 dxiri joined #salt
16:23 whytewolf dfinn: it launches a new shell. as the new user. if that doesn't work. [and it doesn't block you] then something else outside of salt is causing it
16:23 MTecknology If you're really that opposed to managing the init script with either salt or puppet (which I'm surprised you don't do already), then you can just write a wrapper script that exports the variable and runs whatever you told it to run instead..
16:23 dfinn probably true, i just have no clue what and why it doesn't come up any other time
16:23 woodtablet joined #salt
16:24 dfinn thanks MTecknology, I do realize there are other options.  I was hoping to do it in the simplest way possible, which in my mind would be with a short custom module but maybe I'll have to look at other options
16:26 lovelyday MTecknology: the state does a simple cmd.run; however, I tried directly targetting the machine (e.g. salt 'machinename' cmd.run ..) and it fails. No error message, nothing I can find in the logs. If I run the command on the windows cmd, it works perfectly. If I run it through salt, the settings are not applied :|
16:26 jab416171 joined #salt
16:26 raspado mmm i bounced both salt-server and minion but still not seeing the metadata grains
16:26 raspado is it possible to execute a minion call to a grain manually to test?
16:27 PatrolDoom joined #salt
16:27 whytewolf ?
16:27 whytewolf a minion call to a grain? what does that even mean
16:27 MTecknology dfinn: http://paste.debian.net/938464/
16:28 MTecknology I forget a section about Usage:, but you can probably figure it out. :D
16:28 major raspado, how are you trying to see them?
16:28 dfinn no, that's way over my head, i have no clue what it's doing ;)
16:29 raspado major: by running salt-call grains.items on the minion
16:29 major where did you set the grain?
16:29 whytewolf raspado: try grains.get <your grain>
16:30 major I see that you are setting the grain in /etc/salt/grains .. but .. was that on the minion or the server?
16:30 raspado major: that was on the server
16:30 whytewolf ...
16:30 whytewolf welp thats your problem
16:30 major thought so
16:30 raspado ahhh crap
16:30 raspado hmmmm
16:30 major grains are always set on the minion
16:31 armyriad joined #salt
16:31 major at least .. so far as I am aware they are ;)
16:31 whytewolf yeap they are. even when you use grains.set you are running that on the minion
16:32 raspado im not running nitrogen, im still on boron, does salt master have a method to pushing out grains to minions?
16:32 MTecknology dfinn: I'm not too excited about work at the moment, so.... http://paste.debian.net/938465/
16:32 raspado custom grains...
16:33 whytewolf raspado: nitrogen isn't even released yet
16:33 raspado ah ok, then this metadata grain is part of that release it looks like
16:34 whytewolf where is the documentation you are reading on this metadata grain
16:34 major is there a page which links to .. "sexy" state files .. you know .. just examples of top-notch written states?
16:34 Lionel_Debroux joined #salt
16:35 MTecknology major: sorry, I haven't put my states on github yet, but I have some stuff on gist ;)
16:35 major lol
16:35 raspado whytewolf: this is the metadata.py i added to the salt master https://github.com/saltstack/salt/blob/nitrogen/salt/grains/metadata.py and this is the grain I need to set https://docs.saltstack.com/en/develop/ref/grains/all/salt.grains.metadata.html
16:36 whytewolf salt master??? grains are minion side
16:37 major raspado, are you trying to do something akin to Puppet's facts sync, where you write a tool that adds to the agents facts?
16:37 major and distribute that from the server?
16:37 MTecknology raspado: It sounds like what you really want to use is pillar
16:38 SaucyElf_ joined #salt
16:38 _JZ_ joined #salt
16:38 major you know .. a lot of the salt terms are a bit too punny..
16:38 dfinn nice looking state file MTecknology, it's been a couple of years since I've written or even looked at one of those.  i wish i could get my current place to switch off of puppet
16:39 raspado major: im trying to get the instance flavor of the minion dyanamically, we need to configure minions differently by flavor so I was hoping I can use this custom metadata grain to unlock additional minion info
16:39 numkem joined #salt
16:39 PatrolDoom so give them a 'flavor' pillar
16:39 brd dfinn: I just did that, and life is sooo much better
16:39 major raspado, what is the instance flavor based on?
16:39 MTecknology To be honest, I personally do whatever I can to avoid custom grains that don't come from salt-states:_grains/$name.py and always default to do nothing if they don't exist.. grains.get('ntp_available', False)
16:40 inad922 joined #salt
16:40 Inveracity joined #salt
16:41 whytewolf I'm going to brb, make a coffee run
16:41 MTecknology When you start mucking with custom grains on different hosts, I (very subjective) think it gets absurdly difficult to have reproducible builds.
16:41 major yah .. but some things just aren't accessible any other way
16:42 major like maybe you are adding a grain for physical location of some bare metal hardware that is read from some random hardware registry
16:42 MTecknology I usually see it used so you can push things like server-role or other silly attributes down to minions
16:43 major or you are a weird hardware vendor that can only tell the difference between two platforms based on the type of PHY you used between 2 revs of a board
16:43 raspado major: not sure what you are asking, but it would be a grain generated from calling the aws metadata service
16:43 major MTecknology, and yah .. I have totally had to deal with the later :(
16:44 MTecknology major: in that case, "salt-states:_grains/$name.py"
16:44 major raspado, so your minion is executing an aws query?
16:44 major MTecknology, yah
16:44 raspado major: not yet, this is where i was hoping i can utilize the metadata.py
16:44 raspado as it calls the metadata server
16:45 major raspado, I think you can do what you want w/out using metadata.py
16:45 major oh ..
16:45 MTecknology major: write a custom grain module that uses the script, then you get the flexibility of python to parse that however you need and always get the exact data structure you expect
16:45 major snap
16:45 major I see what you are doing
16:46 MTecknology err. raspado*
16:46 raspado MTecknology: understood but isnt that what metadata.py is for? or am I misunderstanding this concept
16:46 MTecknology I imagine that already exists somewhere on the internet..
16:47 MTecknology raspado: I don't know what the crap metadata.py is. I avoid AWS as much as possible.
16:48 major so in Nitrogen the metadata.py was added which, if "metadata_server_grains" is True .. will automagically collect grains from a grains server..
16:48 raspado ^ exactly
16:48 major and you are setting up a grains server?
16:48 raspado i think thats what im missing... hence for my reason of adding /etc/salt/grains/metadata.py on the salt master :)
16:48 MTecknology So the grain I mentioned exists and you just want to enable the option to make use of it?
16:49 major I don't think you should be using the metadata server stuff ..
16:49 raspado but that was a failed atttempt to trying to enable this grain
16:49 major just a guess ..
16:49 major but I think it isn't the solution you are looking for
16:49 MTecknology raspado: metadata_server_grains: True <-- this is a configuration setting..
16:49 raspado MTecknology: understood
16:49 MTecknology /etc/salt/minion
16:50 major yah .. he has that, but he isn't using Nitrogen or something
16:50 major isn't there an aws module for querying this sort of stuff?
16:50 major https://docs.saltstack.com/en/latest/topics/cloud/aws.html
16:50 MTecknology I've only seen him mention /etc/salt/grains
16:51 MTecknology him/her/them*
16:51 major yah .. I get what they are trying to do
16:51 raspado i guess i just need to know how to push and/or utilize metadata.py, should this be on the master or deployed to all the minions to make use of it
16:51 major I think..
16:51 MTecknology You get what they are trying to do, but I'm trying to clearly define what settings they've changed and where\
16:51 major raspado, metadata.py is not for querying AWS
16:51 raspado its for querying the metadata server
16:51 major right
16:52 raspado so in theory, I should have a grain like instance_flavor: r3.8xlarge
16:52 major if you simply want to "set" data on a minion, you don't use a metadata server
16:52 MTecknology raspado: Where did you set metadata_server_grains: True?
16:52 Praematura joined #salt
16:52 raspado MTecknology: I added it as a grain during provisioning an instance with salt-cloud
16:52 MTecknology right...
16:53 raspado its set as a grain on the minion
16:53 MTecknology so go back and re-read what I said
16:53 major heh .. I admit .. I had to reread what you typed
16:53 MTecknology "I'm trying to clearly define what settings they've changed and where" ...
16:54 MTecknology 11:49 < MTecknology> raspado: metadata_server_grains: True <-- this is a configuration setting..
16:54 major yah .. config setting .. not a grain
16:54 nixjdm joined #salt
16:54 nicksloan joined #salt
16:55 raspado ahhh
16:55 schemanic joined #salt
16:55 major salt is too punny...
16:55 raspado so a configuration setting on /etc/salt/master ?
16:55 schemanic Heyo. Can anyone explain what 'pki' means regarding saltstack?
16:56 MTecknology raspado: .... really?
16:56 schemanic I'm using salt-formula and I keep seeing references to things being dropped into /etc/salt/pki but I don't understand if these are supposed to be the ssh keys I'm using for gitfs or salt-cloud or what
16:57 MTecknology raspado: 11:49 < raspado> MTecknology: understood  ;  11:49 < MTecknology> /etc/salt/minion
16:57 stomith joined #salt
16:57 raspado MTecknology: ill figure it out... I think I need to make more sense of what does where, thanks for the assist
16:57 raspado thx major
16:57 cyborg-one joined #salt
16:59 MTecknology raspado: next time.. actually read the things people say, ya? It's a bit frustrating to be blatantly ignored three times.
17:00 major raspado, well .. MTecknology is really the one who pegged the problem.
17:00 whytewolf MTecknology: question is if it is a config setting that is read by config.get
17:00 major whytewolf ?
17:00 major I am curious about that statement
17:00 MTecknology whytewolf: if __opts__.get('metadata_server_grains', False) is False:
17:01 whytewolf major: a setting that is read by config.get can be a gran [or pillar] and still be read by the minion
17:02 whytewolf s/gran/grain/
17:02 major soo .. this metadata.py file's copy exists .. where during all of this?
17:02 MTecknology whytewolf: I wasn't aware config.get merged grains and settings, that's neat to know.
17:03 MTecknology I'll stick to never ever using it, but good to know I might encounter it. :P
17:03 major heh
17:03 major thats useful
17:03 major so you can coordinate configs as pillar's w/out needing to tweak minion configs
17:04 whytewolf it's good for things like mysql settings and what not. so you can set that up in pillar. with out resorting to the connection settings directly in a state. or restarting the minion
17:05 MTecknology hm.. neat, I guess maybe not "never ever", but I don't have sql servers at home and I'd like to keep that True. :)
17:05 major still .. where does metadata.py exist during all of this? both ends? is it copied to the minion in agentless mode?
17:06 MTecknology it's probably wrapped up in the source
17:06 MTecknology wait, that's the file we've been reading
17:06 MTecknology https://github.com/saltstack/salt/blob/nitrogen/salt/grains/metadata.py
17:06 major yah
17:06 MTecknology that's salt's source code
17:06 major yup
17:07 MTecknology what's your question?
17:07 whytewolf yeah that is a built in grain in an upcoming release
17:07 whytewolf just drop it in _grains if you want it
17:07 whytewolf what is the question??
17:07 major I was mostly just using the metadata.py as a stepping stone (since we were already discussing it) to try to leverage a better understanding of how grains are moved around in agent and agentless models
17:08 major or .. scripts which collect information and set grains..
17:08 whytewolf agentless would be salt-ssh. ... I  actually do not know if _grains is supported there
17:08 SaucyElf joined #salt
17:09 MTecknology major: https://gist.github.com/MTecknology/7ecdae1440b06b60e7cec5c6723a04d8#file-salt_structure-L6
17:10 major https://docs.saltstack.com/en/latest/ref/file_server/dynamic-modules.html
17:11 MTecknology *_roots works, btw - not just file_roots
17:11 whytewolf really? I have been looking for the page for the last month. thought they just got rid of it
17:11 major heheh
17:12 major I just found it
17:15 schemanic Hello everyone, can anyone point me to the documentation where it describes assigning volumes to salt-cloud profiles?
17:16 MTecknology I've never worked with lvm from salt-cloud
17:17 _JZ_ joined #salt
17:17 schemanic hmm. There's supposed to be a place where you can say you want a drive to be x gb and what kind etc
17:17 whytewolf iirc it is dependint on each driver
17:17 whytewolf which cloud are you interested in?
17:19 _JZ_ joined #salt
17:21 schemanic whytewolf, AWS ec2. I just found it actually: https://docs.saltstack.com/en/latest/topics/cloud/aws.html
17:21 schemanic it wasn't immediately clear how to get there
17:21 stewgoin joined #salt
17:21 ChubYann joined #salt
17:21 MTecknology salt-cloud docs need improvement, but they've also come a long way in the past couple years
17:22 walker joined #salt
17:22 MTecknology schemanic: patches are always welcome!
17:23 schemanic MTecknology, I'm sorry, I didn't mean to me critical. I just got fixated on the string 'Amazon' and didn't realize that the docs drilled down to the info I needed under 'EC2'
17:23 MTecknology I meant that with sincerity, the salt cloud docs could use some help to make finding things easier and add some completeness, patches would be welcome by many.
17:24 SneakyPhil I'm having some trouble doing tasks with files if a specific item in a pillar exists. Specifically I want to get a file path from a pillar and check if that exists on the filesystem prior to writing a file. https://gist.github.com/anonymous/5be4db93bc44e522e71cc4da3b00a9c3
17:25 SneakyPhil Has anyone done something similar?
17:26 SneakyPhil In a more appropriate use case, I'm attempting to have salt clean up a directory of files it doesn't manage but I want to expand the amount of files to keep.
17:26 MTecknology SneakyPhil: pillar.get
17:27 schemanic Does anyone know where I can find all of the parameters I can pass to objects in a 'volumes' object when configuring ec2 cloud profiles?
17:27 SneakyPhil MTecknology: where do I stuff that? I've been trying all morning :(
17:28 schemanic the example says { size: 10, device: /dev/sdg, type: io1, iops: 1000 } for example but that's not comprehensive
17:28 MTecknology SneakyPhil: you used file.exists... you also need to user pillar.get
17:28 whytewolf to be more exact, if {% salt.file.exists(salt.pillar.get('pillar:path')) %}
17:28 whytewolf wow. maybe i have dementia
17:29 whytewolf {% if salt.file.exists(salt.pillar.get('pillar:path')) %}
17:29 MTecknology schemanic: for salt-cloud, cross-reference docs with source
17:29 schemanic you mean I have to go through the code for salt itself?
17:29 schemanic Where can I get that code exactly?
17:29 MTecknology gimme a second
17:30 schemanic I'm willing to do so if need be I just don't know where to get that
17:30 MTecknology https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds
17:30 iggy I bet google does
17:31 cwoodson joined #salt
17:32 MTecknology I suppose it kinda makes sense for salt-cloud docs to be less maintained than the rest. By the time you get it going, you're excited, and never look at it again.
17:32 SneakyPhil MTecknology and whytewolf ty, that works
17:32 SneakyPhil seems that my value isn't coming in from defaults.yaml though
17:32 SneakyPhil even though elsewhere in my config I can use that same variable
17:32 SneakyPhil it's a start.
17:33 MTecknology whytewolf: I didn't realized you can do salt.foo.bar, always done salt['foo.bar']. Are they functionally different?
17:33 iggy they are the same
17:33 whytewolf just a shortcut that i find easier to read
17:33 iggy as long as you have the salt at the beginning
17:34 MTecknology neat, I might have to adopt that
17:34 whytewolf https://docs.saltstack.com/en/latest/topics/jinja/index.html#calling-salt-functions
17:35 SneakyPhil for defaults.yml I had to use salt.defaults.get('some:path:to:some:file')
17:35 SneakyPhil cool, tyvm
17:35 SneakyPhil even though defaults.yml was included in my map.jinja
17:35 schemanic MTecknology, thanks
17:36 schemanic I think I know what my issue is as well
17:36 schemanic cloud profiles create 'device' volumes, whereas something else will have to create the partition on them.
17:39 PatrolDoom i swear i read something on this before, either in here or on interwebz
17:41 matt____ joined #salt
17:41 matt____ left #salt
17:41 MTecknology At some point I need to figure out how to correctly deploy a VM to proxmox using salt-cloud. I'm finding it incredibly difficult to make happen.
17:41 matt_k joined #salt
17:44 mavhq joined #salt
17:45 MTecknology once I have that done, I'm going to move DNS from my pfsene device to a dedicated unbound server that salt manages
17:46 rayanimesh joined #salt
17:50 mikecmpbll joined #salt
17:51 cwoodson joined #salt
17:58 hashwagon joined #salt
18:00 candyman89 joined #salt
18:02 MTecknology :'( https://dpaste.de/Nfrc
18:02 MTecknology I don't have "local" storage enabled, I have images on different storage.
18:09 nixjdm joined #salt
18:09 major I have this strange urge to symlink the pillars/top.sls to states/top.sls ...
18:10 major I suspect I am failing to grok the fun ways in which I can organize my setting of data ;)
18:12 MTecknology major: did you look at my example?
18:12 major yah
18:12 major I blame me
18:12 KyleG joined #salt
18:12 KyleG joined #salt
18:12 major and my environment .. I suspect when I have a lot more stuff to organize then my pillars will change
18:13 major its all fairly basic right now ..
18:13 Kanoxbox_ joined #salt
18:13 major manually converting a puppet tree to salt .. and not a very good puppet tree at that
18:14 MTecknology just try to plan for growth, avoid formulas, write re-usable states, driven by pillar, keep as much selection logic out of the states as possible, especially node-specific things, use pillar or grains for that.
18:17 major yupyup
18:22 nicksloan joined #salt
18:22 Antiarc joined #salt
18:22 raspado finally got that metadata.py module to work, although I did have to modify the metadata.py to include meta-data in the url
18:23 raspado I get a grain now with instance-type: m3.large and a whole bunch of other usefule grains
18:24 major raspado, congrats
18:30 felskrone joined #salt
18:31 raspado gtmanfred: yt?
18:33 raspado gtmanfred: i had to include latest/meta-data/ to the prefix, not sure if this is handled correctly in nitrogen but in boron, I got a response error that body was not avail
18:35 lorengordon joined #salt
18:40 walker joined #salt
18:43 mpanetta_ joined #salt
18:43 walker joined #salt
18:44 c_g joined #salt
18:51 SaucyElf joined #salt
18:55 _KaszpiR_ joined #salt
18:58 candyman88 joined #salt
18:59 thinkt4n_ joined #salt
19:00 gtmanfred it should default to latest/meta-data?
19:01 gtmanfred or just with /latest
19:01 gtmanfred https://github.com/saltstack/salt/blob/nitrogen/salt/grains/metadata.py#L45
19:01 gtmanfred ¯\(°_o)/¯
19:02 gtmanfred it works for me
19:02 gtmanfred it should be able to query /latest, and then just do a lookup all the way down
19:02 gtmanfred and the top level key should be meta-data
19:05 walker joined #salt
19:06 SaucyElf_ joined #salt
19:07 gtmanfred it works for me on openstack and amazon where i tested them
19:10 nixjdm joined #salt
19:11 prg3_ joined #salt
19:12 lorengordon joined #salt
19:14 schemanic Hello, so I'm having a bit of a problem
19:14 schemanic Salt-cloud is giving me this error:
19:15 schemanic [ERROR   ] There was a profile error: list index out of range
19:15 schemanic anyone have any idea what's going on here?
19:15 gtmanfred not without the rest of the stacktrace
19:15 gtmanfred run it with -l debug and put the output in a gist please
19:16 schemanic thanks
19:17 major is there a cmd.run.args or something I can assign instead of including the command and args as the name?
19:18 gtmanfred i do not believe so, that command to be run is the name
19:19 major sooo .. guess the solution is to make the command a variable and include it in a string which as the args..
19:19 major s/as the/has the/
19:20 lorengordon joined #salt
19:20 schemanic gtmanfred, thanks for reminding me about -l debug. I think I found the problem - I forgot to specify a block device type in my device mapping
19:20 major something like... name: "{{ command }} arg1 arg2 arg3" ?
19:21 gtmanfred that would work
19:24 schemanic no there's something else wrong
19:25 dxiri joined #salt
19:28 schemanic hey gtmanfred, here's the stacktrace along with my provider/profile
19:28 schemanic https://gist.github.com/devinnasar/5ce84967251d5c08465d52cc56e486ca
19:29 gtmanfred can you indent the list out of block_device_mappings 2 more spaces to make sure that they are getting into the list?
19:30 schemanic I can. These are being auto-generated by salt-formula. hang tight
19:31 schemanic I have a feeling it might be because the root device name is wrong
19:31 schemanic someone over in ##aws told me that the ec2 instance would figure it out that it was the root device if I specified /dev/sda1, as in there's some kind of mapping going on
19:32 gtmanfred that i don't know but it looks like the salt code for checking the block device mapping isn't working
19:33 gtmanfred if that doesn't fix it, i don't know
19:33 schemanic same message, even with indents
19:33 notCalle joined #salt
19:35 schemanic hmm. Changed the device name to /dev/xvda and now it isn't crashing yet...
19:36 coval3nce joined #salt
19:36 schemanic okay now it's working
19:39 darvon joined #salt
19:46 raspado gtmanfred: ah okay thx for checking, possibly http library updated too?
19:51 cyteen joined #salt
20:00 capnhex joined #salt
20:02 walker joined #salt
20:03 walker joined #salt
20:04 DammitJim joined #salt
20:04 walker joined #salt
20:05 walker joined #salt
20:05 walker joined #salt
20:09 nixjdm joined #salt
20:10 taylorbyte1 left #salt
20:12 pcn joined #salt
20:13 pcn is there a way to pass pillar data from a file via the CLI?  I can't find the documentation on the pillar="{...}" option at the moment
20:13 pcn Oh, that's an option via state.sls, isn't it...
20:13 xet7 joined #salt
20:14 Neighbour I'm using it for salt-run and again in salt.state calls from within orchestration
20:16 capnhex joined #salt
20:17 Kanoxbox_1 joined #salt
20:19 capnhex left #salt
20:19 Kanoxbox_1 joined #salt
20:20 Kanoxbox_1 joined #salt
20:22 Kanoxbox_ joined #salt
20:22 major soo .. about pkgrepo states ..
20:23 major these don't seem like something you would use pillars for
20:24 Kanoxbox_ joined #salt
20:24 whytewolf but, what if you a. don't want to use the default repo but instead have an local repo
20:25 Kanoxbox_ joined #salt
20:25 whytewolf b.) have a distro not covered by formula
20:25 major hmm .. I think I was more thinking in the context of specifying our custom local repos
20:26 whytewolf in that case make it as hard coded as you like
20:26 Edgan major: apt, yum, or ?
20:26 major Edgan, yes
20:26 edrocks joined #salt
20:26 Edgan major: which or both?
20:26 major both and more
20:27 whytewolf this is starting to sounds like at least a map.jinja
20:27 Edgan major: I have a fairly elegant method for apt. You could probably adapt it to yum.
20:30 major I am open to pretty much all suggestions .. atm was trying to wrap my head around various ways to implement these
20:30 Edgan major: https://pastebin.com/RKHhaQhM
20:32 major hmmm
20:37 dxiri_ joined #salt
20:38 schemanic Is anyone familiar with a good formula for setting up the partitions on your machine? I want to have my mount points for /var and others be on a separate block device
20:38 thinkt4nk can I specify a version to install when using bootstrap?
20:38 edrocks joined #salt
20:40 schemanic thinkt4nk, yes https://docs.saltstack.com/en/latest/topics/tutorials/salt_bootstrap.html#install-using-curl
20:40 schemanic thinkt4nk, the options for the bootstrap script are there.
20:40 thinkt4nk thanks schemanic, I couldn't find any reference on https://repo.saltstack.com/
20:40 Edgan thinkt4nk: I prefer salt code and salt-ssh to bootstrap.
20:41 SaucyElf joined #salt
20:42 mpanetta joined #salt
20:43 thinkt4nk thanks again folks
20:50 schemanic np
20:57 nicksloan joined #salt
20:59 lorengordon joined #salt
21:06 hashwagon joined #salt
21:07 major Edgan, can't you match the apt.repos.releases against grains['oscodename'] and carve out all these extra checks?
21:09 nixjdm joined #salt
21:09 major like .. move the {% if grains['oscodename'] == name %} inside the for-loop?
21:10 johnkeates joined #salt
21:11 Edgan major: yeah, there is some optimization that could be had
21:13 Edgan major: I was more trying to show how you could combine pkgrepo.managed with yaml in a map.jinja to formulize it
21:14 major aye, and it is very much appreciated :)
21:22 dxiri joined #salt
21:25 Kanoxbox_ joined #salt
21:32 rojem joined #salt
21:48 XenophonF joined #salt
21:52 wangofett joined #salt
21:58 major hmm .. can I create anonymous lists in jinja? E.g. {% if needle in [haystack['key'], 'foo'] %} ??
21:58 gtmanfred yeah
21:58 major disco
21:59 wangofett joined #salt
22:02 hashwagon What's the max file size salt can comfortably transfer from master to minion?
22:02 hashwagon file or directory ^
22:02 gtmanfred uhh i knew this
22:02 gtmanfred it is a setting that you can change
22:02 gtmanfred one second
22:02 gtmanfred I don't think there is a limit on file size
22:02 gtmanfred but it transfers it in chunks of file_buffer_size https://docs.saltstack.com/en/latest/ref/configuration/master.html#file-buffer-size
22:03 hashwagon gtmanfred: thanks I'll check that out.
22:03 gtmanfred the max size of files to push back to the master using cp.push is https://docs.saltstack.com/en/latest/ref/configuration/master.html#file-recv-max-size
22:06 puzzlingWeirdo joined #salt
22:08 wangofett joined #salt
22:20 raspado joined #salt
22:21 raspado joined #salt
22:32 dendazen joined #salt
22:32 PatrolDoom joined #salt
22:34 dxiri joined #salt
22:46 mavhq joined #salt
22:48 dxiri joined #salt
22:52 dxiri_ joined #salt
22:57 Praematura_ joined #salt
23:05 rojem joined #salt
23:07 jas02 joined #salt
23:17 MTecknology whytewolf: I don't suppose you happen to know why this doesn't work, do you?  http://paste.debian.net/939097/  (SaltCloudSystemExit: There are no cloud providers configured, but pillar[cloud:providers] exists)
23:18 MTecknology err, meant to ping gtmanfred since he was talking about from pillar stuff
23:24 MTecknology Ah! salt-call cloud.*
23:24 MTecknology not salt-run
23:24 gtmanfred yes
23:25 gtmanfred i am also out for the evening o/
23:25 MTecknology and more bugs
23:27 MTecknology Failed to get the output of 'digital_ocean.avail_locations()': Invalid header value 'Bearer 1404c43fa6ca300dc836989377e91cfad434281919eb13edd3101c2945dfd627\n'
23:28 coredumb how come pillar['x']['y'] returns correct value while pillar.get('x:y') returns nothing?
23:28 MTecknology salt['pillar.get']
23:28 coredumb yeah this works as well
23:29 whytewolf pillar.get != salt['pillar.get']
23:29 MTecknology pillar is a dictionary and dicts have .get(), salt[pillar.get] is a module that has delim lolgic
23:29 coredumb pillar.get('x') works fine but not x:y O_o
23:29 coredumb mmmmmmh
23:30 whytewolf coredumb: .get in python doesn't understand x:y notation
23:30 coredumb ohhhhhhhh
23:30 coredumb even with delimiter=: ?
23:31 whytewolf delimiter isn't a thing in python get
23:31 MTecknology coredumb: "is a module that has delimiter logic"
23:32 coredumb ok ok ok
23:32 coredumb thx
23:32 MTecknology coredumb: https://github.com/saltstack/salt/blob/develop/salt/modules/pillar.py#L30
23:34 whytewolf ^ salt['pillar.get']  vs https://docs.python.org/2/library/stdtypes.html#dict.get < pillar.get
23:34 coredumb cool thx a lot
23:54 hrumph joined #salt
23:55 zerocoolback joined #salt
23:56 nicksloan joined #salt
23:58 Edgan How do I change the 4505 port that the minion wants to connect to on the master? I know I can say master: 'ip:45060' to change 4506.

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