Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2016-08-11

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

All times shown according to UTC.

Time Nick Message
00:00 whytewolf ... great. so it wasn't in keystone.exception or openstackclient.common.exceptions ... it was in keystoneclient.exceptions
00:00 whytewolf somedays i wonder how these guys get out of bed in the morning
00:00 amcorreia joined #salt
00:03 spuder_ joined #salt
00:10 invalidexception joined #salt
00:14 invalidexception joined #salt
00:20 ZachLanich joined #salt
00:20 sp0097 I am creating vm's against vsphere using salt-cloud.  I hooked up the event reactor to the created event.  I am running like 9 or so tasks, some of the tasks take a long time to complete.  Is there a way to make each task complete before continuing to the next?
00:27 ZachLanich Anybody have a second to help me with a suggestion on pillar modules?
00:29 Edgan ZachLanich: Give me detail of what you mean by pillar modules
00:30 ZachLanich Edgan These: https://docs.saltstack.com/en/2015.8/ref/pillar/all/index.html - Namely interested in the pyhon/json/mysql/mongo possibilities.
00:31 ZachLanich If you'd like to give it a go, I'll give you the rundown.
00:32 Edgan ZachLanich: I have used foreman with puppet before, and you could use foreman with salt. It is in your list. Foreman uses postgresql(or mysql) as a backend database, but itself has an api to update the data.
00:32 Edgan I mean the list
00:33 ZachLanich Edgan I guess I'd have to learn more about what Foreman is to know if it's appropriate.
00:33 dendazen joined #salt
00:33 Edgan ZachLanich: It also gives you a salt dashboard to see the success/failure of your salt runs in master mode.
00:33 invalidexception joined #salt
00:33 Edgan ZachLanich: The general term for using an external source of data is called an ENC, external node classifer.
00:34 ZachLanich Edgan Thanks for that term clarification. That's helpful.
00:34 Edgan ZachLanich: It is more flexible and less git centric than git in pillars, but you lose history in most ENCs.
00:35 ZachLanich So yes, I need an ENC, and I don't think history will be a huge deal.
00:35 ZachLanich Would you like a synopsis of what I'm trying to do?
00:35 Edgan ZachLanich: I like to be able to revert a setting/password change if it doesn't work.
00:35 Edgan ZachLanich: sure
00:38 ZachLanich Edgan: I'm building a mini platform like WP Engine where customers can create any number of "Infrastructures" and any number of "Sites" in each of those infrastructures. I’ll be using a Git backend for some of my common Pillars, but I need “site specific” pillars and I need them stored in a database so I can easily update them using a REST API from another system.
00:38 ZachLanich The issue is (especially with MongoDB Pillar Module) is that you evidently can’t use globs to match minion names, so I’m not able to store say data like this (http://dp.wecreate.com/17L8A) and send it to 2 web nodes without duplicating the data in the db like so: http://dp.wecreate.com/puek
00:39 ZachLanich I could be missing something, but you'll see in those Gists what I'm trying to do. I'd like to be able to target specific minions AND "all" minions within an infrastructure without duplicating data, which is obviously taboo.
00:40 aphor Has anyone else got a way to add formulas to a salt-master without needing to change the (filr|gitfs)_roots and restart?
00:41 Edgan ZachLanich: That seems like a MongoDB problem. MongoDB is document based, and that means there is no scheme, and all documents are effectively standalone from the database perspective. It is up to the app to translate them.
00:41 Edgan aphor: Why would I need to restart just to add formula either way?
00:42 Edgan ZachLanich: An SQL based fits the glob use case much easier
00:42 aphor Edgan: the normal way is to add the formula root to file_roots, which is in the master config, which only gets read by the master at start.
00:42 ZachLanich Edgan The real issue isn't Mongo, but rather the fact that I can't store glob syntax as the "primary key" in Mongo and use the Mongo Pillar Module out of the box (unless I'm misunderstanding) to compare against those globs.
00:42 Edgan aphor: you mean stacking git repos, or adding a new env's git repo?
00:43 aphor Edgan: yes, or even stacking file roots, since formulas by convention only have one state module in their roots there is little chance of collision/confusion.
00:43 flowstate joined #salt
00:44 aphor Edgan: as described here https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
00:44 Edgan aphor: are you doing the one formula per git repo module?
00:44 ZachLanich Edgan, here's my source of confusion: This article (http://www.tmartin.io/articles/2014/salt-pillar-mongodb/) tells me "One drawback of external pillars : you cannot use globbing to export the same set of data to several minions, like you can do using the Pillar topfile (/srv/pillar/top.sls).", but I see this in the docs (Docs: http://dp.wecreate.com/1j7tQ - SS: http://dp.wecreate.com/w4fz) that leads me to believe I could...
00:44 aphor Edgan: that's the convention, yes.
00:45 mavhq joined #salt
00:45 Edgan aphor: That model is completely against the way I write formulas. I would also have like 50+ git repos for my formulas. It just seems like a bad model.
00:45 aphor Edgan: decoupling formulas' history in different repos is a great model.
00:45 aphor IMHO...
00:46 aphor formulas are supposed to be reusable components.
00:46 Edgan aphor: But I do things like pull configuration settings for say nginx from the nginx map.jinja in other formulas. I don't like to repeat myself. So my formulas are interdependent.
00:47 aphor Edgan: that's a thing, but you need to treat your map.jinjas like APIs then.
00:47 Edgan aphor: but tracking APIs across 50 git repos, ugh
00:48 Edgan aphor: If you wanted to have your cake and eat it too, you could use submodules to make it a little more sane.
00:48 aphor Here's my case: let's say you wrote a formula for fat-service but it has a lot of stuff you just whipped up in sls files in that formula.
00:49 Edgan aphor: also tracking branches for different environments across 50+ repos, UGH!
00:50 aphor Edgan: true, but I'm wondering if something in the state.apply process could be hooked to rescan a folder (like /srv/formulas) for formulas?
00:51 aphor Edgan: the whole of many small interdependent parts isn't the fault of salt. That's general to all modular software architectures.
00:51 Edgan aphor: https://github.com/saltstack/salt/issues/570
00:51 saltstackbot [#570][OPEN] master/minion should accept a SIGHUP and reload config |
00:51 Edgan aphor: that is basically your topic
00:52 Edgan aphor: old bug
00:52 aphor 2012.. that's like 1944 in Salt years...
00:52 Edgan aphor: ubuntu trusty(2014) shipped with 0.17.5
00:52 aphor Actually I think Salt already knows good times to re-check config.
00:54 Edgan aphor: As of January they basically say would require a major rewrite.
00:56 aphor Edgan: I'm more optomistic than that. A lot of stuff has _virtual_ and lazy_loading and that stuff makes it easier to shuffle things around at runtime.
00:56 Edgan aphor: yeah, something tells me it would just require someone serious to take the time
00:57 chingadero joined #salt
00:57 Edgan aphor: having dug deep into the salt code mapping out all the layers accurately took some time
00:57 aphor Edgan: I'm here to socialize the idea, and solicit opinions. Nobody will commit the time unless there is consensus that it is a good investment.
00:57 Edgan aphor: I agree it is a feature that should have existed long ago
00:58 Edgan aphor: especially for master
00:58 aphor pillar data gets reloaded every time we highstate
00:59 aphor minions refresh their state tree caches too
00:59 Edgan yes, but that is just for the compiling of the highstate for a job
00:59 Edgan config data != state data
00:59 aphor So maybe file_roots and gitfs_roots needs to get factored out of the config?
01:00 Edgan You have to take into account things like the reactor. You have to finish all existing work, hopefully gracefully, prevent new work, reload, reinitialize, and start accepting new work
01:00 chingadero left #salt
01:00 Edgan Which sounds like thinking about work as a queue, if it isn't already
01:01 aphor Edgan: it would take some code review, but my guess is that _virtual_ wlll eventually provide a stable context for running jobs.
01:01 Edgan aphor: you have state jobs, reactor, mine, and another layer syndic
01:01 aphor I'm not sure, but it seems like a lot could probably be done with a clever decorator.
01:03 aphor jobs would just have to copy all of the context data to a job-local reference at run time
01:03 Edgan aphor: Ideally you would have zero downtime. You would only reload configuration on a per connection basis.
01:04 Edgan aphor: you would probably have to interally version the configuration, and track which version each connection is using
01:05 Edgan version number
01:05 aphor Edgan: some platforms provide event based systems to signal config file changes so that pollig the files all the time isn't necessary.
01:05 Edgan aphor: yes, linux definitely has that
01:05 aphor FreeBSD kqueue and Linux epoll.
01:05 Edgan aphor: think there is also fsevents
01:06 Edgan aphor: there have been like half a dozen different Linux styles over time
01:06 Edgan aphor: you also have a meta problem
01:06 aphor meta?
01:07 Edgan aphor: What if I have three web servers that are part of the same cluster, but the first one gets the old configuration and the second and third get the new configuration
01:07 aphor Edgan: that can already happen with orchestrate runners that straddle chenges to the states.
01:07 Edgan aphor: if the old config and new config have different database passwords, problem
01:08 aphor no net change in my use case
01:08 Edgan aphor: yes, I am not saying it isn't an existing problem, but faster reloads makes it bigger
01:09 aphor orchestrate states are jobs that would, under my suggestion, pick up a consistent copy of config context at runtime.
01:09 aphor So if you want to be consistent across a pool of servers, have a reactor kick off an orchestrate job that enforces the state on all of them.
01:10 aphor That's already the convention.
01:10 squishypebble joined #salt
01:13 aphor So my dream is that maybe /srv/formulas is a hot folder, and salt-api exposes a REST call that git commit-hooks can use to trigger inserting or refresing a new/changed formula.
01:14 aphor OK. Going for a walk to meditate on it some more.
01:14 Edgan aphor: you are assuming file not gitfs. and it is really a different form of file_root were you have some external process git cloning things into /srv/formulas
01:19 ZachLanich Edgan: I've created a mental walkthrough of how the Infrastrcuture data would be stored and how Mongo "might" treat it. Can you (or anyone in here) take a look at this and tell me if you think it would work, please!: https://gist.github.com/zlanich/a6204d4ff7b61e8e0880396795fec541
01:19 ZachLanich @anyone else too ^
01:28 berto- joined #salt
01:46 flowstate joined #salt
01:47 ilbot3 joined #salt
01:47 Topic for #salt is now Welcome to #salt! | Latest Versions: 2015.5.11, 2015.8.11, 2016.3.2 | Support: https://www.saltstack.com/support/ | Logs: http://irclog.perlgeek.de/salt/ | Paste: https://gist.github.com/ (please don't multiline paste into channel) | See also: #salt-devel, #salt-offtopic | Ask with patience as we are volunteers and may not have immediate answers
01:54 fannet joined #salt
01:56 al joined #salt
02:00 mohae joined #salt
02:01 Edgan joined #salt
02:03 om joined #salt
02:16 cyborg-one joined #salt
02:25 jaybocc2 joined #salt
02:31 bastiandg joined #salt
02:41 flowstate joined #salt
03:13 spuder joined #salt
03:24 subsignal joined #salt
03:31 spuder_ joined #salt
03:38 ZachLanich joined #salt
03:40 evle joined #salt
03:41 aphor Edgan: I think gitfs will be easier than file_roots because there is more logic in there to manage inconsistencies between the salt master's rev and the remote repo rev
03:43 flowstate joined #salt
03:46 eseyman joined #salt
03:47 filippos joined #salt
03:47 egil joined #salt
03:47 badon joined #salt
03:48 tuxx joined #salt
03:49 alinuxninja joined #salt
03:50 invalidexception joined #salt
03:51 flebel joined #salt
03:51 renoirb joined #salt
03:52 smcquay joined #salt
03:53 bdrung_work joined #salt
03:54 TOoSmOotH joined #salt
03:54 ajolo joined #salt
03:54 spuder joined #salt
03:59 DerCed joined #salt
04:01 jaybocc2 joined #salt
04:17 ZachLanich iggy or hemebond You around?
04:30 k_sze[work] joined #salt
04:34 ZachLanich joined #salt
04:39 onlyanegg joined #salt
04:42 sp0097 joined #salt
04:43 flowstate joined #salt
04:44 ThisIsZenified joined #salt
04:50 sp0097 Hi there, I had a question about event reactors if anyone has a moment.
04:50 lorengordon joined #salt
04:52 sagerdearia joined #salt
05:01 KingJ joined #salt
05:01 bdrung_work joined #salt
05:04 alinuxninja joined #salt
05:04 sp0097 I have setup an event to react to the salt-cloud created event. I see in the docs it says that, "This interface more specifically maps to the cmd_async method inside of the LocalClient class."
05:06 sp0097 I have about 9 states defined in the sls, I am calling local.state.apply.  Some of the tasks can take like 20 mins.  Curious if I can make the local.state.apply call synchronous.
05:11 ageorgop joined #salt
05:12 onlyanegg joined #salt
05:13 iggy sp0097: synchronous to what? The state itself will run in order synchronously... at the same time, other things could also run though if that's what you mean
05:15 bocaneri joined #salt
05:15 sp0097 iggy:  I mean synchronously to each other, so of the 9 tasks I have defined, I want task 1 to complete, then task 2 to execute, and so on...what I am seeing now, is the sls from the reactor seems to execute each one of my tasks asynchronously.
05:16 iggy paste code, because that doesn't sound right
05:17 sp0097 part 1: https://gist.github.com/anonymous/37e9b5e9a34718fcc825f691322f18d5
05:18 sp0097 argh, need to connect to vpn, be a min.
05:19 iggy protip: gist supports multiple files per paste
05:19 sp0097 LOL, my bad.  thank you
05:20 scsinutz joined #salt
05:20 iggy cscf: if you didn't get your problem sorted, `salt-call cp.list_master` and see if anything looks off, also `salt-run -l debug fileserver.update` is helpful
05:22 sp0097 https://gist.github.com/anonymous/89a858c0e047ac1f251c40e74c39f152
05:22 sp0097 here we go, those are both files
05:22 whytewolf so... what is happening?
05:22 antpa joined #salt
05:23 sp0097 so what I want to happen is to have b-batch_oracle_prereqs execute completely before c-batch_oracle_software executes
05:23 iggy can you make just a single state that does all of those things instead of doing each step in the reactor file? I think that's the problem
05:24 whytewolf if you can't do that. you might resort to using require: - salt: b-batch_oracle_prereqs
05:24 iggy local.state.apply, tells the minion to run that and it's probably timing out waiting for the return after the normal timeout period (15 seconds or whatever) and hten moves on to the next
05:25 ageorgop joined #salt
05:25 iggy you could also use a reactor to kick off an orchestrate job
05:26 sp0097 I only wanted to target the vm I am creating, my impression with an orchestrate is that it would use the tgt pattern in the orchestrate script
05:27 jenastar joined #salt
05:27 sp0097 whytewolf: Reactor SLS files, by design, do not support Requisites, ordering, onlyif/unless conditionals and most other powerful constructs from Salt's State system.
05:27 sp0097 I wasn't sure if that was still true?
05:28 whytewolf sorry was more refering to the way iggy was talking about.
05:28 whytewolf using an orch
05:29 whytewolf https://docs.saltstack.com/en/latest/topics/reactor/#advanced-state-system-capabilities
05:29 whytewolf it is even documented
05:31 iggy that's how I've done it in the past... and now I'm starting to wonder if I came to that path by figuring out the same thing you are ;)
05:31 rdas joined #salt
05:32 sp0097 can I apply a target to the orchestrate in the reactor sls,  # /srv/reactor/some_event.sls invoke_orchestrate_file:   runner.state.orchestrate:     - tgt: {{ data['name'] }} and G@servertype:db     - mods: orch.do_complex_thing
05:32 whytewolf sp0097: look at the code that is in their example. they pass the data in through pillar.
05:33 sp0097 ok, will do.  I was having a hard time understand it. let me look again.  Thank you for the tips.  appreciate it.
05:35 spuder_ joined #salt
05:35 whytewolf orch is run on the master. there is no tgt with it. but you pass the data into a pillar object. then in the orchestrat put that pillar object into a data object. then just need to call data.name
05:36 stooj joined #salt
05:40 sp0097 ah, ok.  in my orchestrate file, I can setup all of the states like I do now.
05:41 sp0097 and it seems like I can setup the target compound matching the same as well.
05:41 whytewolf yes
05:41 felskrone joined #salt
05:42 sp0097 instead of local.state.apply, I would call salt.state
05:42 sp0097 ok, that makes a lot of sense now.
05:42 whytewolf right. you can look at all the salt based functions here https://docs.saltstack.com/en/latest/ref/states/all/salt.states.saltmod.html
05:43 mikepea_ joined #salt
05:43 czchen_ joined #salt
05:44 flowstate joined #salt
05:44 Freek_ joined #salt
05:45 ze-_ joined #salt
05:46 Garo__ joined #salt
05:46 sp0097 cool, thanks
05:48 TOoSmOotH_ joined #salt
05:48 onlyanegg joined #salt
05:48 paant joined #salt
05:49 vodik joined #salt
05:49 jaybocc2 joined #salt
05:51 sp0097 Does the first function have to be a call to the salt runner? Or can I simply call the salt.state and put the requires as needed.
05:52 whytewolf no if you don't want to call a runner don't call a runner
05:52 sp0097 k, cool.  perfect.
05:53 flebel joined #salt
05:54 CeBe joined #salt
05:55 fannet joined #salt
05:56 sp0097 We actually have a oracle db-only.sls which handles oracle db installation.  What is the value of {% set tag = salt.pillar.get('event_tag') %} when not coming through the reactor?
05:56 whytewolf nothing if you are not using it
05:56 whytewolf it is an example.
05:56 pipps joined #salt
05:58 sp0097 k, cool.  I was thinking we have one way to install using orchestrate via command line and then other using it through the reactor where we would use to event_tag / data
05:58 sp0097 but reuse the same script.  maybe overthinking it.  but wanted to reuse the one script for both purposes.
05:59 whytewolf you could if you want. you just need to pass in your data as pillar data.
06:02 alexhayes joined #salt
06:05 impi joined #salt
06:14 Miouge joined #salt
06:14 cyborg-one joined #salt
06:17 kshlm joined #salt
06:21 impi joined #salt
06:29 saintpablo joined #salt
06:32 alexhayes joined #salt
06:43 flowstate joined #salt
06:43 fracklen joined #salt
06:46 fracklen joined #salt
06:50 fracklen joined #salt
06:51 ivanjaros joined #salt
06:52 debian112 joined #salt
06:55 om joined #salt
06:59 sp0097 thank you whytewolf, I adjusted my setup accordingly.  I will try it out tomorrow.  :)
07:19 alexhayes joined #salt
07:24 zer0def joined #salt
07:24 xist joined #salt
07:26 Sylvain31 joined #salt
07:35 stooj joined #salt
07:35 POJO joined #salt
07:39 catpig joined #salt
07:40 synapse joined #salt
07:43 flowstate joined #salt
07:44 mavhq joined #salt
07:44 amy_ joined #salt
07:49 impi joined #salt
07:56 fannet joined #salt
08:00 saltuser joined #salt
08:01 mavhq joined #salt
08:05 krymzon joined #salt
08:06 TomJepp joined #salt
08:09 mavhq joined #salt
08:11 stooj joined #salt
08:18 ivanjaros3916 joined #salt
08:18 Rumbles joined #salt
08:19 jaybocc2 joined #salt
08:20 mavhq joined #salt
08:21 traph joined #salt
08:21 traph joined #salt
08:22 fredvd joined #salt
08:22 toanju joined #salt
08:26 mavhq joined #salt
08:29 saltuser Hi! How can I use salt API to see if requested stuff actually happened? Right now it's async, it responds "success" immediately
08:30 mavhq joined #salt
08:31 s_kunk joined #salt
08:33 s_kunk_ joined #salt
08:33 mikecmpbll joined #salt
08:38 impi joined #salt
08:39 kbaikov joined #salt
08:40 GreatSnoopy joined #salt
08:40 mavhq joined #salt
08:43 flowstate joined #salt
08:44 mavhq joined #salt
08:52 s_kunk joined #salt
08:52 yuhlw_ joined #salt
08:59 ronnix joined #salt
09:09 irctc608 joined #salt
09:11 irctc608 hi there
09:11 irctc608 can i override a state which i got from a formula, without touching the formula?
09:12 irctc608 the state is not templated with pillar data
09:14 fannet joined #salt
09:14 whatevsz joined #salt
09:18 lero joined #salt
09:18 Rumbles joined #salt
09:19 babilen You can extend states .. but you might want to change the formula in a way that allows you to achieve what you want without having to "fork" it. Maybe other people find it useful too.
09:19 babilen Depends on what you want to do though
09:28 saltuser I'll rephrase my question - is there a way to use Salt's REST API in synchronous way?
09:29 Hetman joined #salt
09:29 Hetman Hello can somebody tell me whats wrong here: http://pastie.org/10934472
09:31 Electron^- joined #salt
09:32 saltuser Hetman: If that is one SLS, then the block alignment seems off
09:32 Hetman saltuser: yeah it's one SLS
09:33 saltuser Try aligning them uniformly throughout the file
09:33 Hetman This is full file http://nopaste.linux-dev.org/?1119693
09:33 saltuser I would start by correctong the alignment
09:33 Hetman Is after if , elif etc I'm not doing indent ?
09:34 saltuser python and therefore salt is quite picky sometimes about that :)
09:35 saltuser Hetman: yes, those in if/elif statements should realigned
09:35 KingOfFools jinja code shouldnt affect your state statements
09:36 Hetman Thanks fixed it by moving 4 spaces back everything under if/elif now getting No function declared in state
09:37 KingOfFools and shouldn't it be 2 spaces intendents in YAML? Until you specifying dicts or lists?
09:37 saltuser The indent length does not matter afaik, as long as indents are used uniformly
09:37 auzty joined #salt
09:37 Hetman KingOfFools: I'm using 4 spaces and working fine
09:39 mc-fi0n__ joined #salt
09:40 saltuser I once included two SLS files into one. Separately they worked fine, but when included together, it failed. I debugged for hours before the peculiarities of python starged to dawn :)
09:40 saltuser Turned out one file had two spaces too much
09:41 lompik joined #salt
09:42 flowstate joined #salt
09:42 atmosx Hello, when I add: {% salt['cmd.run']('openssl rand -hex 32') %} into a state sls (e.g. zabbix.sls) is this command execute on salt slave?
09:44 irctc608 @babilen looking at extend. I don't mind changing the formula, but i think the problem i am facing i specific to my system and not worth doing it in the main formula
09:45 irctc608 @babilen and thanks again. you were helpful yesterday too :)
09:45 mpanetta joined #salt
09:45 saltuser atmosx: it should, yes
09:45 atmosx thanks
09:46 atmosx does this state make sense: https://gist.github.com/atmosx/0a8b6ed8e21ee88ec6edbee806cb3950 ? I'm passing options to a script from pillar.
09:49 jaybocc2 joined #salt
09:49 saltuser atmosx: I'm not sure that works as you want. Perhaps assigning the cmd.run output to jinja variable first but that's pretty random guess ...
09:56 keimlink joined #salt
09:56 Inver joined #salt
09:59 jaybocc2 joined #salt
09:59 cyborg-one joined #salt
10:11 saltuser Salt API is nice, it keeps reporting "success" whatever i do, but no idea if stuff got actually done. This feedback is as helpful as windows error messages ...
10:16 atmosx lol
10:29 KingOfFools saltuser: well, its reporting success cause event was succesfully accepted
10:29 babilen Which is why most APIs let you check the *result* of a job you submitted with a different call
10:30 babilen (so that you can differentiate between "api call succeeded" and "thing I asked the API to do succeeded")
10:30 saltuser How do i check then if the latter succeeded?
10:31 AndreasLutro you'll have to find a way to get a JID back then poll the status for that JID
10:31 AndreasLutro don't know how though, I haven't worked with the api
10:31 saltuser I thought about that too
10:35 babilen saltuser: I can't tell you for salt, but you might want to look at the returned data. Some properly designed APIs would include a "reference" or "key" in the returned data that allows you to query the result
10:43 flowstate joined #salt
10:47 dendazen joined #salt
10:53 babilen (the JID in this case)
10:54 Rumbles joined #salt
10:56 saltuser I'll look into it
11:04 amcorreia joined #salt
11:07 dunz0r So I've got a state that has some jinja-templating in it, this fetches info from the pillar, I'd like to run this separately, but I can't, since the state name depends on pillar-data...
11:07 dunz0r Anyway I can loop through it, or something?
11:08 dunz0r like salt somehost state.sls_id sshusers common.sshusers
11:08 flowstate joined #salt
11:27 babilen Loop where?
11:29 babilen You can call individual states regardless of their creation .. you can't easily run individual groups of people
11:29 babilen (subsets of the pillar)
11:30 babilen But then .. you either want those users on that box or you don't. Only target those that you want and create them all.
11:31 dunz0r Hang on. I think I might need to show you how it works...
11:32 dunz0r This is what the state looks like: http://sprunge.us/XYPE
11:32 dunz0r As you can see, it really doesn't have any name.
11:32 babilen Sure, that's quite normal
11:32 dunz0r Since it's created when the jinja is processed, I can't tell state.sls_id the name of the state to run
11:33 babilen Can't you?
11:33 babilen And why do you want to run it independently to begin with? Just apply the SLS and you have all users you want!
11:33 dunz0r Oh wait a second...
11:33 dunz0r Nope.
11:33 babilen "Nope" ?
11:34 dunz0r babilen: I'm doing something like salt somehost state.sls_id ssh common.sshusers
11:34 dunz0r And sshusers is of course in the folder common
11:34 babilen common.sshusers is unlikely the correct name
11:34 dunz0r Uhm, no?
11:34 babilen You want something like "user_foousername"
11:34 dunz0r Exactly.
11:34 dunz0r That's my issue. :)
11:34 babilen You refer to state IDs in the SLS you pasted
11:34 babilen You can't do what you wnat
11:35 dunz0r :(
11:35 dunz0r I CAN get the info from the pillar though... and loop through it, I think
11:35 babilen Just target common.sshusers to that box and run the entire SLS. Problem solved, all users created.
11:35 dunz0r babilen: Yeah, I already do that.
11:35 babilen So, what is the problem with that approach?
11:35 dunz0r But I want to run this particular state, on all machines on a schedule.
11:36 babilen So, run all of it?
11:36 dunz0r Don't see why not really... It's the point of salt.
11:36 babilen Sorry, I don't quite follow. What is the point of salt?
11:37 dunz0r babilen: Automation, configuration-management and centralisation.
11:37 babilen All I'm saying is that you have a SLS that creates states for all users you want on that box. If you re-run that SLS without changes to your pillar data it won't make a difference (states are idempotent)
11:37 babilen If you have changes in your pillar data they will be rolled out
11:38 babilen In fact you could run the entire highstate on a regular basis and target that users state in the state top.sls
11:38 dunz0r Yeah, it just feels shaky to run a full state.highstate on a schedule.
11:38 babilen Why?
11:38 dunz0r I might break something
11:39 dunz0r (the easy answer here is "don't break stuff")
11:39 babilen Your system is much more likely to break if it is the result of a number of unpredictable manual state applications with manual overrides
11:39 babilen Just test what you roll out beforehand
11:40 dunz0r Yeah, I'm not sure why I'm even worrying.
11:40 babilen You want to be in a position in which you can run a highstate whenever you want without the fear of breaking or changing something (unless you made changes)
11:40 dunz0r babilen: Thanks for getting me out of that silly cognitive loop :)
11:41 babilen The worst that could happen is to be in a position in which you can't be sure that what you have in your state is reflected in the state of the minions as you manually ran a number of individual states or even cmd.run applications
11:42 babilen So you don't dare to highstate at all :)
11:42 babilen You obviously want to test what you push into production, but that shouldn't be done by relying on "careful manual state application" IMHO
11:42 dunz0r Yep. Doing a state.highstate test=true right now.
11:42 dunz0r Just to make sure
11:42 babilen That's the spirit :)
11:43 dunz0r I mean, I've written all of these states, I'm certain at what they do, nothing should break :)
11:45 babilen And if they don't you might want to fix them
11:46 dunz0r babilen: Precisely!
11:46 dunz0r It's just all these damn exceptions... :)
11:46 west575 joined #salt
11:47 babilen I had to question it .. we had one user in our company who didn't really trusted salt and treated it as a more powerful pssh/dsh ... In the end the state of the minions were not necessarily in line with the highstate and it made it *really* hard to develop or change states as you could never be sure what state the system was in.
11:47 babilen We sorted that out and he now trusts salt and has adopted a "there is no truth but the highstate" attitude :)
11:51 dunz0r We kind of have that problem here... people doing "special things" with systems, that salt then overwrites
11:51 dunz0r Just bloody tell me...
11:52 dunz0r And then be all like 'uuhuhuh salt just ruins things bububub'
11:52 dunz0r :@
11:55 babilen "Well, you edited a file that specifically mentioned that it shouldn't be changed manually"
11:55 babilen "But it was faster that way .. who has time for all those tests and git malarkey?"
11:59 dunz0r babilen: Exactly.
11:59 saltuser babilen: POST /run and using client='local_async' returns JID. That's something to work with I guess
11:59 KingOfFools can i use onchanges with states?
12:00 felskrone joined #salt
12:00 KingOfFools i'm getting error that requisite wasn't found
12:00 babilen KingOfFools: requisites are always between states .. could you paste what you've done and the exact error to one of http://refheap.com, http://paste.debian.net, https://gist.github.com, http://sprunge.us, … ?
12:00 babilen (or anything ! pastebin.com)
12:03 west575 joined #salt
12:03 KingOfFools oops, looks like my bad
12:03 KingOfFools think, i got it
12:15 Qlawy Can I use "context" in jinja if statement?
12:16 Qlawy I mean I do: file.managed and set context: enable-ui: true
12:16 Qlawy I would like to use this enable-ui  in jinja if-statement
12:20 TooLmaN joined #salt
12:24 jaybocc2 joined #salt
12:28 numkem joined #salt
12:32 babilen You can
12:38 gh34 joined #salt
12:45 dendazen joined #salt
12:48 ssplatt joined #salt
12:51 Qlawy babilen: great, how?
12:55 squishypebble1 joined #salt
12:57 babilen Qlawy: {% if enable-ui %}
12:58 AndreasLutro should probably use underscores instead of dashes
12:58 Qlawy hmm
12:58 Qlawy I did: {% if enable-ui -%}
12:59 babilen Use underscores ...
12:59 babilen So, you used that before and ran into an error?
13:04 XenophonF "But it was faster that way..." is the bane of my professional experience :(
13:05 Qlawy {% if enable-ui -%}    <======================
13:05 Qlawy TypeError: unsupported operand type(s) for -: 'StrictUndefined' and 'StrictUndefined'
13:05 jaybocc2 joined #salt
13:05 Qlawy perhaps its due to -
13:05 Qlawy :X
13:05 XenophonF switch to enable_ui
13:06 Qlawy ok, I will
13:07 alexhayes joined #salt
13:07 babilen Qlawy: Was that your problem all along or were you genuinely unaware that you could use {% if VARIABLE_FROM_CONTEXT %} ?
13:07 flowstate joined #salt
13:09 Qlawy TypeError: unsupported operand type(s) for -: 'StrictUndefined' and 'StrictUndefined' - was my main problem
13:10 babilen Good, ask about your actual problem next time. :)
13:10 babilen - is being interpreted as an operator
13:10 babilen (minus)
13:13 jaybocc2 joined #salt
13:15 bearonis joined #salt
13:17 roock joined #salt
13:19 Tanta joined #salt
13:27 kbaikov joined #salt
13:28 patrek joined #salt
13:39 ssplatt *sigh* why does the salt bootstrap for fedora24 install 2015.5.10
13:40 ssplatt “You asked for latest and you have 2015.5.10 installed, sweet!”  lies.
13:41 racooper joined #salt
13:45 Sylvain31 hi, can you confirm or infirm (the opposite) that https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.rsync.html can't handle ssh extra option as in: rsync -a -e 'ssh -i {{ sshkey }}' {{remote}}:{{ old_documentroot }} {{ new_documentroot }}
13:46 AndreasLutro just use cmd.run or cmd.run_all, which the rsync.rsync function is basically just a wrapper for anyway
13:46 AndreasLutro but yes looknig at the source code, you can't provide the -e argument
13:47 Sylvain31 AndreasLutro: thanks I already have a cmd.run in fact, I miss the - unless: for now… ;)
13:48 AndreasLutro you miss the unless for now? what do you mean?
13:50 blueelvis joined #salt
13:52 Sylvain31 AndreasLutro: a cmd.run rerun every time, so you have to provide a way so it can check if needed, so as I code rsync myself with cmd.run I need to do some test myself before, but it's OK I will handle that.
13:52 Sylvain31 ;)
13:53 averell joined #salt
13:54 AndreasLutro you'd have the same problem using the rsync module function
13:55 flowstate joined #salt
13:55 Sylvain31 oh, there is a state… https://docs.saltstack.com/en/latest/ref/states/all/salt.states.rsync.html
13:56 Sylvain31 with same limitation I need to pass an ssh key.
13:56 ramSeraph joined #salt
13:57 amiskell joined #salt
13:57 babilen Sylvain31: You might want to configure ~/.ssh/config beforehand
13:57 meirw joined #salt
13:58 babilen (if you don't opt for cmd.run)
13:58 subsignal joined #salt
13:58 cmarzullo Sylvain31: I think I ran into the same thing. I eneded up using cmd.run. All the rsync stuff defined by pillar.
13:58 amiskell Hi guys, I have an timeout issue I'm trying to resolve with salt and can't seem to figure out what's going on.
13:59 amiskell I have a couple salt-minions that seem to timeout when trying to connect to the salt-master
13:59 amiskell I see [ERROR   ][2973] SaltReqTimeoutError: after 180 seconds, ran 3 tries in the minion logs
14:00 Sylvain31 babilen: how state.rsync.synchronized will be aware of ~/.ssh/config?
14:00 ramSeraph hey, anyone with experience with filebeat formula?
14:00 timoguin joined #salt
14:00 babilen Sylvain31: Is it not?
14:00 Sylvain31 babilen: does it even have an notion of $HOME?
14:00 aphor How would everyone feel if file_roots and gitfs_roots supported shell globbing for local files/repos and the config['file_roots'] automatically updated whenever a new qualifying folder appeared?
14:01 aphor use case: adding formulas to a salt master without restarting.
14:01 ramSeraph https://github.com/saltstack-formulas/filebeat-formula
14:01 babilen Sylvain31: You could test that - It might not actually pass that env var and it wouldn't work.
14:02 babilen (if you prefer .. i'd stick to cmd.run and define all bits in the pillar)
14:02 ramSeraph the service restart state in filebeat formula seems to just hang till it hits some timeout at 2000 secs
14:02 babilen Well, you could also implement the functionality you need in the execution module and state
14:03 babilen aphor: 'good'
14:03 meirw I have a question about file.recurse (to sync a directory) and a watch on that directory
14:04 Sylvain31 AndreasLutro, replied that I can't by default with rsync module, I read the code and wanted a confirm, that I didn't missed the trick, I will stick to cmd.run for the moment. it is a migration and the foreign server is not managed. ;)
14:04 meirw here's the gist: https://gist.github.com/anonymous/4dc0ca7d85dbc92940bb2159f82129aa
14:04 meirw I can only get it to watch if I give it an id that exavtly matches the watch, like this /etc/nginx/conf.d/*:
14:04 meirw is that correct?
14:05 AndreasLutro meirw: just remove the /*
14:05 AndreasLutro in both places
14:05 aphor babilen: I'm planning to look at the spm stuff and see if some of that dynamic state file space functionality can be extended to file_roots and gitfs_roots
14:06 aphor ok. I'll look a little deeper into that.
14:06 meirw Thanks @AndreasLutro
14:07 meirw documentation had said I needed the /*
14:07 AndreasLutro depends on what you're doing
14:07 AndreasLutro if you have multiple file.managed states for files in /etc/nginx/conf.d then yes, you need the /* in the watch
14:07 AndreasLutro but the /* globbing is for state IDs, not file names
14:13 ThisIsZenified left #salt
14:18 impi joined #salt
14:23 mapu joined #salt
14:23 ZachLanich joined #salt
14:25 johnkeates joined #salt
14:27 bowhunter joined #salt
14:31 Miouge joined #salt
14:38 tiwula joined #salt
14:41 Brew joined #salt
14:50 colegatron joined #salt
14:51 jaybocc2 joined #salt
14:54 Misfit joined #salt
14:57 flowstate joined #salt
14:58 SpX joined #salt
15:02 amy_ joined #salt
15:03 antpa joined #salt
15:06 __saltmaster__ joined #salt
15:06 __saltmaster__ hello
15:06 __saltmaster__ stupid question for the channel, hope you don't kick me off :-)
15:07 __saltmaster__ I have to manage a lot off nfs share and I want to do it with salt
15:07 __saltmaster__ I already used the mounted module
15:07 __saltmaster__ but I noticed that if I remove description from state it doesn't remove the persistent entry in /etc/fstab
15:08 __saltmaster__ this makes sense but I wonder if there is a method to remove unwanted entries without explicit this in the state
15:08 __saltmaster__ with the unmounted module
15:09 __saltmaster__ I was thinking for example, running script that remove all the nfs entries in fstab before run the state with mounted
15:09 __saltmaster__ but may be there is a smarter way to do that
15:10 vilitux joined #salt
15:11 spuder joined #salt
15:11 bearonis joined #salt
15:14 bowhunter joined #salt
15:16 fracklen joined #salt
15:19 jenastar joined #salt
15:20 mohae joined #salt
15:22 cmarzullo __saltmaster__: How are you definining mounts? If you use pillar that contains a list of your mounts and the values for those mounts you can interate over them. Then on some of the mounts they have a value set to absent which removes the mount.
15:24 __saltmaster__ I have defined them in the state
15:24 __saltmaster__ cmarzullo: do you have an example to do that?
15:24 cmarzullo http://pastebin.com/x2RNpfP6
15:25 cmarzullo That's for files. but same principle.
15:25 __saltmaster__ cmarzullo: it seems that I missed some pieces
15:26 __saltmaster__ I didn't know that it was possible to use jinja in pillar definition
15:26 cmarzullo that's a state file. But you can use jinja in the pillar definition also.
15:27 __saltmaster__ ok, I must study a bit more jinja :-)
15:28 cmarzullo here's some sample pillar to go with that state: http://pastebin.com/i3gkYb6V
15:28 cmarzullo So it'll make a ping file but make sure the network file is absent
15:28 __saltmaster__ so your items are ping and network, aren't they?
15:29 cmarzullo I'm not sure what you mean.
15:29 edrocks joined #salt
15:34 ssplatt hmm i made a state to extract the kernel source tarball in /tmp/, but archive.extracted keeps telling me “/tmp/ already exists”  shouldn’t it just drop the tarball in tmp, then extract it so i get /tmp/kernel-<version>/
15:35 __saltmaster__ cmarzullo: I meant if your for cicle is on ping and networks
15:35 __saltmaster__ I'm trying to figure out how I can use your code in my usecase :-)
15:36 __saltmaster__ with a few knowledge of jinja
15:37 cmarzullo So it iterates over the collectd.plugins hash. It takes the key as the file name and passes the data to the rest of the state.
15:37 cmarzullo s/hash/disctionary/
15:37 Rumbles joined #salt
15:37 __saltmaster__ ok
15:38 __saltmaster__ is there a way to test this code without run state?
15:39 cmarzullo https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#salt.modules.state.show_sls
15:42 Brew joined #salt
15:42 confusuSum joined #salt
15:43 ivanjaros joined #salt
15:44 confusuSum left #salt
15:46 cmarzullo If you are asking the largest question of how to test states I'd direct you to this blog: http://unicolet.blogspot.com/2016/05/a-not-so-short-guide-to-tdd-saltstack.html
15:47 cmarzullo *larger
15:52 __saltmaster__ cmarzullo: thanks
15:54 __saltmaster__ cmarzullo: let me read these stuff, I'll come back :-)
15:57 cmarzullo np.
15:58 cmarzullo There's definitely a lot to learn when it comes to jina and the patterns to do what you want.
15:59 onlyanegg joined #salt
15:59 spuder_ joined #salt
16:00 __saltmaster__ cmarzullo: could you point me to a good reference/guide on jinja?
16:01 __saltmaster__ cmarzullo: I've already taken a look to jinja website but I got confused
16:01 impi joined #salt
16:01 cmarzullo Sadly there isn't much. I basically just stared at the jinja website forever until it made sense.
16:02 cmarzullo You can also look through other peoples formulas for hints about how to structure your states.
16:02 __saltmaster__ uhm...ok, but formula still are some wierd things to me
16:02 cmarzullo https://github.com/bechtoldt/saltstack-file-formula/blob/master/file/mounts.sls
16:04 cmarzullo Yeah getting the vocab down is the first step.
16:04 perfectsine joined #salt
16:04 __saltmaster__ I know what it is
16:05 __saltmaster__ but I still have some difficult to understand difference between state and formula
16:05 mpanetta joined #salt
16:05 cmarzullo a formula is a reusable collection of states.
16:06 cmarzullo You can reuse formulas by just changing the data that feeds the formula.
16:07 cmarzullo I have a formula that is called mounts. When invoked it looks at pillar for what it's supposed to do; how many filesystems to mount and how to do them.
16:07 cmarzullo So I can use the mounts formula on two diff servers that have diffrent mount points.
16:08 cyrus_mc joined #salt
16:08 cyrus_mc Is there the concept of a salt client (much like in mcollective world) that can issue commands and retrieve results from the master?
16:08 cyrus_mc I am looking at the Salt API but even with that I don't see that capability
16:09 ageorgop joined #salt
16:10 __saltmaster__ cmarzullo: ok, know it's a bit more clear
16:10 __saltmaster__ does it exist a skeleton/rule to build a formula?
16:11 flowstate joined #salt
16:14 cmarzullo Did you read the blog? :) you can use the saltscaffold github project.
16:14 anotherZero joined #salt
16:15 cmarzullo cyrus_mc: you can push events on to the buss and other minions can react to those events
16:15 edrocks joined #salt
16:16 amcorreia joined #salt
16:18 flowstate joined #salt
16:20 flowstate joined #salt
16:22 flowstate joined #salt
16:23 munhitsu_ joined #salt
16:25 lero joined #salt
16:30 flowstate joined #salt
16:32 perfectsine_ joined #salt
16:34 scsinutz joined #salt
16:37 lero joined #salt
16:39 Lionel_Debroux_ joined #salt
16:42 spuder joined #salt
16:43 lompik joined #salt
16:44 flowstat_ joined #salt
16:47 onlyanegg joined #salt
16:47 murrdoc joined #salt
16:47 murrdoc has anyone successfully virtualenv'ed the salt-minion
16:53 amy_ joined #salt
16:54 flowstate joined #salt
16:56 jenastar left #salt
16:56 sp0097 joined #salt
16:57 murrdoc joined #salt
16:58 lariv joined #salt
17:00 mpanetta Morning/afternoon all.  I wrote a custom grain that pulls role data from pillar.  Are there any drawbacks to this?  I don't want the roles to be easily manipulated and I figured that making a grain from the pillar would be the best way to do this...
17:00 flowstate joined #salt
17:01 badon joined #salt
17:01 babilen wut?
17:01 mvmike joined #salt
17:01 babilen Why don't you just use the pillar data directly?
17:02 whytewolf ^
17:02 mpanetta Because I can't use pillar to select which pillar files I want to read...
17:02 mpanetta Maybe I am doing it wrong?
17:03 edrocks joined #salt
17:03 mpanetta For example, I have 2 pillar files for consul, one to configure a server and one to configure an agent.  I want to be able to select the agent pillar file for systems that have the agent role. I could not seem to do that with pillar top or jinja.
17:04 lariv Seeking some clarification...saltcloud evidently initiates a login to/with each provider that it discovers has a .conf file in /etc/salt/cloud.providers.d/... is this accurate? I can't seem to find anything in Saltcloud docs that confirms this.
17:05 mpanetta lariv: What do you mean by initiates a login?
17:05 mpanetta babilen: So that is my real issue I guess.  I could not find any other way to select which pillar to use based on pillar data.
17:06 mpanetta I tried jinja, but the pillar.get always returned none.  My roles are stored in ext_pillar by minion ID, don't know if that makes a difference or not.
17:07 jaybocc2 joined #salt
17:09 babilen Yeah, you can't target pillars based on pillars (old issue)
17:09 lariv @mpanetta: we launched saltcloud with a map to instantiate a vm in AWS only - but the dir where the <aws>.conf provider file resides also contained a <vmware>.conf file. We had a problem with saltcloud aborting because the Vmware pw had expired, even though we were not doing anything in/with Vmware at the time.
17:09 babilen mpanetta: https://github.com/saltstack/salt/issues/23910
17:09 saltstackbot [#23910][OPEN] Please implement static pillars | Hi,...
17:10 mpanetta lariv: That is odd... It should only attempt to connect to the API used to create the minion specified in your map file...
17:10 lariv @mpanetta: it appears saltcloud is pre-emptively initiating a login with any provider whose .conf it finds...I think.
17:11 mpanetta It shouldn't do that... I have never noticed it doing that...
17:11 mpanetta babilen: Ah!  Thanks for the link.
17:11 lariv Can't find any doc that explicitly confirms it, but I agree with you @mpanetta. Think I'm going to bring this up with SaltStack.
17:12 babilen mpanetta: Could you paste your custom grain?
17:12 perfectsine joined #salt
17:12 babilen just curious
17:12 mpanetta Sure
17:14 autofsckk joined #salt
17:14 mpanetta babilen: https://gist.github.com/bentwire/eda7be0880d2d2c3f95d4d8828d94e16
17:14 lariv mpanetta: Although, there is a description for "--providers-config" which "... defaults to /etc/salt/cloud.providers.d ...", though that seems a bit obscure.
17:14 mpanetta As you can see I use the disk one for a template...
17:15 lariv @mpanetta: Thanks for your feedback! Most helpful.
17:16 mpanetta lariv: No problem.  Wish I could have had more info for you
17:17 babilen mpanetta: Interesting .. you still shouldn't make any sensible data available based on that. I wonder how that copes with the chicken and egg problem of being able to target pillars based on grains ;)
17:17 mpanetta I think it handles it because pillars are compiled on the master
17:18 mpanetta Other than that, I don't know.
17:18 scsinutz joined #salt
17:18 mpanetta The one good thing is, according to the custom grains stuff I read, grains files have the lowest priority, so someone could not override my roles by saying grains.setitem roles foo
17:19 mapu joined #salt
17:21 west575 joined #salt
17:24 alvinstarr joined #salt
17:29 mikecmpbll joined #salt
17:32 ingslovak joined #salt
17:33 cliluw joined #salt
17:36 heaje joined #salt
17:37 felskrone joined #salt
17:40 impi joined #salt
17:40 fracklen joined #salt
17:41 sagerdearia joined #salt
17:45 murrdoc joined #salt
17:47 edrocks joined #salt
17:48 antpa joined #salt
17:52 curious joined #salt
17:53 curious Can Salttack be used to push OS and applciation patches to a homogenous environment?
17:54 murrdoc they made something new for it
17:54 DanyC joined #salt
17:55 cmarzullo curious: yes
17:55 murrdoc http://hubblestack.io/
17:56 murrdoc it sits on top of saltstack and does security patches
17:57 curious So you cannot do it through the "native" features llike orchestration?  BTW, I can't access that hubblestack link.
17:58 cmarzullo you can definitely do it with native features.
17:58 murrdoc you can do it with native features
17:58 murrdoc make a state, and use scheduler
17:59 ssplatt hubblestack is for compliance auditing
17:59 murrdoc https://github.com/hubblestack
17:59 ssplatt and can remediate, but its not the smae as applying ‘apt upgrade’ or ‘yum upgrade'
17:59 ssplatt afaik
17:59 ssplatt maybe it does that as part of remediation
18:00 murrdoc dist upgrading is part of compliance, in my works context
18:00 ssplatt but if all you want to do is pkg.latest, you don’t need hubblestack
18:00 bearonis joined #salt
18:00 ssplatt that was my main point
18:01 murrdoc and i dont disagree
18:01 murrdoc the way we do it , we make a `task` state
18:01 murrdoc and apply that on the regular
18:02 murrdoc ssplatt: if u look at https://github.com/HubbleStack/Nova
18:03 murrdoc its basically a schedule + states
18:03 ssplatt i was in teh presentation at saltconf
18:03 ssplatt its def a good idea
18:03 mibr0 joined #salt
18:03 akhter joined #salt
18:04 ingslovak1 joined #salt
18:04 ingslovak joined #salt
18:04 murrdoc oh , i should watch that
18:04 murrdoc i have been reading the effing code
18:04 ingslovak1 joined #salt
18:06 mdpolaris joined #salt
18:06 amy joined #salt
18:07 blueelvis joined #salt
18:07 hasues joined #salt
18:07 hasues left #salt
18:09 _JZ_ joined #salt
18:09 mdpolaris I am trying to get reactors to use a different saltenv, but no matter how i set it in the kwarg the reactor keeps looking in base
18:15 gmacon left #salt
18:16 curious We would like to "push" patch pacakges (multiple security patches) to clients from YUM and SUS servers on an automated scheduled basis.
18:19 Antiarc joined #salt
18:22 murrdoc joined #salt
18:23 GreatSnoopy joined #salt
18:25 cyborg-one joined #salt
18:34 perfectsine joined #salt
18:36 cmarzullo Great!
18:42 kevinquinnyo joined #salt
18:42 kevinquinnyo sorry irssi is acting up if this is a duplicate msg -- does anyone know if napalm_* modules will work only with Carbon+, or could i drop them into Beryllium/Boron, etc
18:44 antpa joined #salt
18:45 pipps joined #salt
18:46 * LotR just did a double check he wasn't in ##chemistry
18:46 LotR ;)
18:49 scsinutz joined #salt
18:49 KingOfFools is it possible to sort state.show_sls by state order?
18:50 iggy kevinquinnyo: you'll have to test it probably
18:50 kevinquinnyo iggy: ok thanks, just wanted to check on the offchance someone knew
18:50 kevinquinnyo need to provision some test network equipment to actually test them
18:51 iggy probably won't work on beryllium
18:52 iggy wait, my internal version table is skewed
18:52 iggy I hate codenames
18:53 iggy beryllium might work, that's when they did all the proxy minion changes... earlier than that, probably won't
18:53 iggy USE VERSION NUMBERS PEOPLE
18:54 Pulp joined #salt
18:55 Sketch +1
18:55 KingOfFools iggy: are you talking about scientific linux?
18:56 bearonis joined #salt
18:58 stooj joined #salt
18:59 lovecraftian joined #salt
18:59 om joined #salt
18:59 Sketch hopefully he's talking about anything that uses code names instead of version numbers
18:59 scsinutz1 joined #salt
19:00 Matthew_ joined #salt
19:00 KingOfFools well, SL uses codenames and versions at the same time, so idk (:
19:00 KingOfFools but yea, it should be both or only versions
19:02 flowstate joined #salt
19:02 KingOfFools can i loop on some state until it returns true?
19:03 Sketch so does ubuntu
19:05 ksa joined #salt
19:06 LessSneaky joined #salt
19:07 DanyC joined #salt
19:08 devster31 joined #salt
19:09 devster31 joined #salt
19:09 devster31 joined #salt
19:13 stooj joined #salt
19:16 timoguin joined #salt
19:16 omerh joined #salt
19:17 tercenya joined #salt
19:18 murrdoc joined #salt
19:23 DanyC joined #salt
19:23 flowstate joined #salt
19:24 pipps99 joined #salt
19:25 scsinutz joined #salt
19:26 DanyC joined #salt
19:27 stooj joined #salt
19:32 coval3nce joined #salt
19:42 Misfit joined #salt
19:47 DanyC joined #salt
19:48 g3cko joined #salt
19:51 mapu joined #salt
19:54 scsinutz joined #salt
19:56 murrdoc joined #salt
19:57 bearonis joined #salt
19:58 murrdoc1 joined #salt
20:01 debian112 anyone using state.network ?
20:01 debian112 https://docs.saltstack.com/en/latest/ref/states/all/salt.states.network.html
20:01 debian112 in production?
20:01 krymzon joined #salt
20:03 pppingme joined #salt
20:03 tercenya joined #salt
20:03 timoguin joined #salt
20:05 anotherZero joined #salt
20:08 arif-ali joined #salt
20:14 murrdoc joined #salt
20:18 jenastar joined #salt
20:29 sp0097 joined #salt
20:46 jenastar left #salt
20:46 antpa joined #salt
20:50 cscf state.apply returns "Rendering SLS 'base:nextcloud' failed: Jinja variable 'owncloud' is undefined" even though the string 'owncloud' appears literally nowhere in /srv/salt, /srv/pillar, or gitfs remotes
20:50 cscf How is this possible?
20:51 Heartsbane joined #salt
20:51 Heartsbane joined #salt
20:52 Tanta people aren't psychic cscf, you need to post context and logs
20:53 cscf Tanta, nevermind, found it.  Apparently #'s aren't comments if there's a space in front?
20:54 schemanic_ joined #salt
20:59 cmarzullo debian112: yes
21:00 pipps joined #salt
21:08 mpanetta_ joined #salt
21:11 fracklen joined #salt
21:12 timoguin joined #salt
21:16 Sammichmaker joined #salt
21:17 Sammichmaker joined #salt
21:23 debian112 cmarzullo: any problems I should be aware of
21:23 debian112 I was thinking about using it for auto provisioning vlans on hypevisors
21:27 scsinutz joined #salt
21:32 ZiLi0n joined #salt
21:33 ZiLi0n Hello everyone, I am currently using returners to store results in a database. At the same time presence events are enabled, but as far as I can see presence events/ beacon results, are not stored in the database
21:34 ZiLi0n I see there is an event_return parameter at the masterconfig, it is enabled and set to the returner's name, but it doesn't seem to store the events. Is there a way to achieve this?
21:38 flowstate joined #salt
21:42 flowstat_ joined #salt
21:47 pipps joined #salt
21:50 timoguin_ joined #salt
21:53 scsinutz1 joined #salt
21:56 fracklen joined #salt
22:03 murrdoc1 joined #salt
22:04 murrdoc1 joined #salt
22:04 keldwud joined #salt
22:07 scsinutz joined #salt
22:13 stooj joined #salt
22:13 ivanjaros joined #salt
22:27 stooj joined #salt
22:28 murrdoc joined #salt
22:36 mpanetta joined #salt
22:38 jaybocc2 is anyone here using aws KMS for managing the salt master key / signing key?
22:41 mpanetta joined #salt
22:41 flowstate joined #salt
22:50 perfectsine joined #salt
22:58 pipps joined #salt
23:03 perfectsine joined #salt
23:04 arif-ali joined #salt
23:04 scsinutz1 joined #salt
23:08 timoguin joined #salt
23:08 edrocks joined #salt
23:11 JoshuaX joined #salt
23:12 JoshuaX is there a simple way to discover what is in the data dictionary in a reactor?
23:17 keldwud joined #salt
23:22 antpa joined #salt
23:26 dendazen joined #salt
23:29 nZac joined #salt
23:34 sp0097 JoshuaX: I have found running the salt-master in debug mode helps to see the data the events pass.
23:34 arif-ali joined #salt
23:35 sp0097 and running salt-run state.event pretty=True
23:35 sp0097 https://docs.saltstack.com/en/latest/topics/reactor/index.html#debugging-the-reactor
23:37 JoshuaX sp0097: thanks
23:38 JoshuaX I switched to debug mode, and I found the event.  The link is _much_ appreciated.
23:41 flowstate joined #salt
23:43 perfectsine joined #salt
23:49 bbhoss_ joined #salt
23:54 linovia_ joined #salt

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