Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-12-15

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

All times shown according to UTC.

Time Nick Message
00:00 saltslackbridge joined #salt
00:02 pipps joined #salt
00:12 masber joined #salt
00:13 wevanscfi joined #salt
00:15 cgiroua joined #salt
00:15 justanotheruser joined #salt
00:16 aphor @james: --log-level and --log-file-level and --out and --state-output are different options, so they are handled differently already.
00:16 pipps99 joined #salt
00:16 deuscapturus joined #salt
00:17 Manor joined #salt
00:24 saltslackbridge <james> But does that mean I'd have to scrape the logs?
00:24 cgiroua joined #salt
00:24 dxiri joined #salt
00:25 saltslackbridge <james> I'd be happy with json to file and a brief output on screen
00:26 tobiasBora From the gitfs program, is it possible to specify a file in /srv/formula for example instead of /srv/salt (which is linked to salt:// if I'm not wrong ?)
00:33 dxiri joined #salt
00:37 onlyanegg tobiasBora: you can use the file protocol or http(s)
00:38 onlyanegg for example, I have this repo mounted for testing: file:///mnt/my_formula
00:42 tobiasBora onlyanegg: not sure to understand. How can you specify the content of the folder /srv/formula/my_formula/?
00:43 tobiasBora and using the file:/// is quite a practical idea. I'm just a bit lost (the last time I use salt was 1 year ago, so I'm not sure to remember everything), in which file will you put that?
00:43 cilkay joined #salt
00:46 onlyanegg you just need to specify where your git repository lives
00:48 onlyanegg if you have a git repository in /srv/formula/my_formula, then you can refer to as file:///srv/formula/my_formula
00:49 onlyanegg if it's on github, you can refer to it as https://github.com/tobaisBora/my_formula.git
00:49 tobiasBora onlyanegg: you mean in the salt master configuration file in /etc/salt/master?
00:49 pipps_ joined #salt
00:53 cilkay Hello. I find myself often doing {% set something = somethingElse %} at the top of states and that I'm doing it in more than one file suggested to me that I should have central location for all those things, like settings/init.sls. I'm thinking of even assigning values from pillars and grains in that state and then doing a {% import "settings/init.sls" as settings %} at the top of each state. Is this good practice?
00:54 onlyanegg tobiasBora: yeah, for example, here's a snippet of our master config - https://gist.github.com/onlyanegg/76e369e590af751d6a5d66c6c0ee411a
00:54 cilkay I can then reference those variables as settings.foo, settings.bar, etc. It makes it easier to read and any changes that would previously required me to change multiple state files can now be done in one place.
00:55 cilkay I don't see a downside.
00:57 tobiasBora onlyanegg: ok, but now let's imagine that I would like to control over git all the files in my salt master, in order to be able to easily recreate it if it fails. I understand that you can deal with the files in /srv/salt by using gitfs. But if I want to keep in mind the server configuration, with the list of all the formulas and so on, I can't do that right? I need to manually write a tool that will deploy my
00:57 tobiasBora git code right?
01:01 oida joined #salt
01:02 onlyanegg I'm not sure I follow
01:05 onlyanegg A salt master by default looks for states in /srv/salt or whereever, but you can specify that instead of storing the files on the local disk, you can mount a git repository with gitfs and pull from that instead...
01:06 dxiri joined #salt
01:06 onlyanegg anyway, I apologize, but I need to leave. Best of luck!
01:06 user-and-abuser joined #salt
01:09 _JZ_ joined #salt
01:10 cilkay @tobiasBora, I git clone repos on my VMs but I don't use gitfs. I have a private key baked into the VM that has a limited shell on the server that hosts the repos. Would something like that work for you?
01:10 zerocoo__ joined #salt
01:10 tobiasBora onlyanegg: yes I agree. So let's imagine now that I've a git repo mysite/gitrepo.git with all the files that will be in /srv/salt. Now, because the files in /srv/salt refers to salt-formulas, it's also useful to keep updated a list of the formula git repo I use right? And this list will grow when the /srv/salt code will grow, so it's meaningful to also keep this list in a git repository. But because this list
01:10 tobiasBora is not in /srv/salt, I cannot put the formula list in my git repo mysite/mygitrepo.git
01:11 tobiasBora By the way, even if you left, thanks onlyanegg for your help ;)
01:13 tobiasBora So to finish, because I can't put my list of formulas into my repo mysite/mygitrepo.git, I need to find another solution. For now, I'm thinking to use a local git repo with a hook, that would edit the files in /srv/ and in /etc/salt/master.d/, but I'm trying to see if no better way exists.
01:13 tobiasBora cilkay: whoo looks strange
01:14 cilkay I use masterless nodes. The VMs have to be self-configuring.
01:14 tobiasBora oh ok I see
01:14 cilkay The VMs are often behind firewalls.
01:15 tobiasBora so you have a global git server, and the vm maintain a git clone of this git server
01:15 tobiasBora but I'm not sure to see why they need a shell on the server
01:15 cilkay No one needs a shell on the server.
01:16 jholtom joined #salt
01:17 cilkay The servers are treated like an appliance. I have a Django application to configure the server. When the user submits the config form, that saves the key/value pairs to a sqlite db and also to a YAML file which is watched by a process using inotifywait. That process kicks off a shell script that runs all the salt states.
01:18 cilkay tobiasBora, The shell script is just a two-liner. /usr/bin/salt-call --local state.sls ss.init; /usr/bin/salt-call --local state.highstate
01:18 cilkay ss.init updates the salt states. Running highstat then runs through the latest salt states.
01:21 tobiasBora so it's the server that can connect to the VM in order to let them know when the config changed?
01:25 pipps99 joined #salt
01:28 tobiasBora Hum, I don't now why, but I tried to use "curl -o bootstrap-salt.sh -L https://bootstrap.saltstack.com; sudo sh bootstrap-salt.sh git develop" in order to get salt, I have a "salt-master" executable, but I don't have a systemctl service for it. While I've a systemctl service for the minion...
01:31 zerocoo__ joined #salt
01:36 dcrouch joined #salt
01:47 cilkay tobiasBora, No. The VM is managed via Salt. Salt uses git to clone/update some of the software stack and uses rsync for some other parts of the software stack contained within the VMs. The VMs are deployed at customer sites and we only have visibility into them if the customer allows it.
01:47 cilkay The VMs are self-contained appliances. They can configure themselves based on key/value pairs that are entered into a web form.
01:48 tobiasBora cilkay: ohh so the Django runs on the VM?
01:49 tobiasBora I think that what you call VM and server are in fact the same thing, while at the beginning I thought that you add one server, and lot's of small VM.
01:49 cilkay Exactly. Every virtualization technology has some way of presenting a VM console. I created an autologin account called kiosk that launches Chromium. In the VM console, Chromium displays a kiosk page which is served via Django.
01:49 cilkay Yes and no. We have servers that contain things like git repos, Jenkins build/test processes, etc.
01:50 cilkay The VMs have access to those servers to fetch the software stack to be deployed/updated within itself.
01:50 tobiasBora ok it's clearer now. Quite funny, and interesting!
01:51 tobiasBora Thanks for sharing ideas ;)
01:51 cilkay The kiosk page shows just enough information for the users to be able to begin the config process, like the dynamically assigned IP address.
01:51 cilkay They point a browser at that IP address and nginx serves up a static page that gets them started.
01:53 cilkay Well, we had some particular requirements, that precluded us from using a conventional master/minion configuration so all the VMs are masterless minions.
01:53 mikecmpbll joined #salt
01:54 cilkay They don't store any state that can't be re-created within minutes by throwing away the appliance and configuring a fresh appliance.
01:55 tobiasBora that's fun!
01:58 cilkay Lots of lessons learned along the way, like don't bother cloning/updating Angular/Node.js applications and running the build process in the VM. Only deploy build artefacts. The build artefacts are differentiated for different releases by diretory naming conventions.
01:59 cilkay One of the key/value pairs in the Django application is "version". For our customers to update the application, they just have to change the string in that field, save the form, and Salt will bring the software stack within the VM to that version.
01:59 esharpmajor joined #salt
01:59 kettlewell joined #salt
01:59 cilkay Our customers often have multiple versions of our software deployed internally, one for production and at least one more for testing the next release.
02:06 pipps joined #salt
02:06 pipps99 joined #salt
02:16 mikecmpb_ joined #salt
02:24 Larri joined #salt
02:25 mikecmpbll joined #salt
02:30 mikecmpbll joined #salt
02:41 pipps joined #salt
02:59 mrBen2k2k2k joined #salt
03:01 ilbot3 joined #salt
03:01 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.8, 2017.7.2 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic, and https://saltstackcommunity.herokuapp.com (for slack) <+> We are volunteers and may not have immediate answers
03:15 shortdudey123 joined #salt
03:24 bigjazzsound joined #salt
03:24 mikecmpb_ joined #salt
03:28 Larri joined #salt
03:33 wongster80 joined #salt
03:38 masber joined #salt
03:41 pipps joined #salt
03:57 mikecmpbll joined #salt
04:05 kettlewell joined #salt
04:21 mikecmpb_ joined #salt
04:28 akar joined #salt
04:30 mikecmpbll joined #salt
04:32 tikedbus joined #salt
04:36 deuscapturus_ joined #salt
04:47 onlyanegg joined #salt
04:50 pipps joined #salt
04:50 mikecmpb_ joined #salt
04:56 DanyC joined #salt
04:56 deuscapturus joined #salt
05:01 mikecmpbll joined #salt
05:04 cyteen_ joined #salt
05:14 shripadr joined #salt
05:23 justanotheruser joined #salt
05:23 justanotheruser joined #salt
05:31 onlyanegg joined #salt
05:33 wootoot joined #salt
05:34 armyriad joined #salt
05:48 mikecmpb_ joined #salt
05:55 shiranaihito joined #salt
06:21 LocaMocha joined #salt
06:31 rgrundstrom joined #salt
06:43 Lionel_Debroux joined #salt
06:57 DanyC joined #salt
06:58 pipps joined #salt
06:59 felskrone joined #salt
06:59 pipps joined #salt
07:01 tiwula joined #salt
07:06 akar joined #salt
07:22 sayyid9000 joined #salt
07:25 Ricardo1000 joined #salt
07:31 sh123124213 joined #salt
07:31 aldevar joined #salt
07:33 Elsmorian joined #salt
07:36 yuhl joined #salt
07:40 yuhl_ joined #salt
07:44 Manor joined #salt
07:46 Manor_ joined #salt
07:49 aldevar left #salt
07:50 Manor joined #salt
07:50 felskrone joined #salt
07:50 Church- Hey folks
07:51 Church- So just curious when provisions instances using salt-gce how would I go about installing salt-minion with a modified config file to point to my master's ip?
07:52 aldevar joined #salt
07:59 Church- Nevermind, I'm an idiot.
08:04 tchettle joined #salt
08:05 tchettle_ joined #salt
08:07 evle joined #salt
08:07 akar joined #salt
08:09 Larri joined #salt
08:11 darioleidi joined #salt
08:15 Hybrid1 joined #salt
08:19 dxiri joined #salt
08:20 DanyC joined #salt
08:30 sol7 joined #salt
08:34 mikecmpbll joined #salt
08:44 robman joined #salt
08:44 Tucky joined #salt
08:49 mikecmpb_ joined #salt
09:08 mikecmpbll joined #salt
09:09 zerocoo__ joined #salt
09:12 akar joined #salt
09:30 sol7 joined #salt
09:30 nitin__ joined #salt
09:37 nitin__ I got one scheduler configured.
09:37 nitin__ get ithrottle stats:   schedule.present:     - function: state.apply     - job_args:       - get_ithrottle     - seconds: 300     - returner: influxdb
09:37 nitin__ there are data lost sometime.
09:38 nitin__ can splay help me here. I couldnt find the real use of splay.
09:40 jhauser joined #salt
09:43 doubletwist joined #salt
09:47 pbandark joined #salt
09:48 oida joined #salt
10:08 doubletwist joined #salt
10:11 kedare joined #salt
10:31 GrisKo joined #salt
10:31 doubletwist joined #salt
10:37 Nazca joined #salt
10:46 Elsmorian joined #salt
10:47 mrBen2k2k2k joined #salt
10:49 Nazca joined #salt
10:58 doubletwist joined #salt
11:06 Manor joined #salt
11:14 Tucky joined #salt
11:22 stewgoin joined #salt
11:25 colegatron joined #salt
11:26 darioleidi joined #salt
11:32 Manor joined #salt
11:32 peters-tx joined #salt
11:38 darioleidi joined #salt
11:56 zach joined #salt
12:17 kettlewell joined #salt
12:22 17WAABQ1G joined #salt
12:28 onlyanegg joined #salt
12:37 Guest43884 joined #salt
12:42 jeremytiki joined #salt
12:49 aldevar left #salt
12:53 darioleidi joined #salt
13:11 mkoskar joined #salt
13:17 Nahual joined #salt
13:18 miruoy joined #salt
13:21 shakalaka joined #salt
13:24 Antiarc joined #salt
13:25 aarontc joined #salt
13:25 vaelen joined #salt
13:25 packeteer joined #salt
13:27 sjorge joined #salt
13:32 cyteen_ joined #salt
13:33 shripadr joined #salt
13:38 shripadr_ joined #salt
13:44 edrocks joined #salt
13:54 shripadr joined #salt
14:16 deuscapturus joined #salt
14:26 schemanic joined #salt
14:31 wevanscfi joined #salt
14:35 jeremytiki joined #salt
14:36 cgiroua joined #salt
14:36 netcho joined #salt
14:44 sjorge joined #salt
14:50 darioleidi_ joined #salt
14:58 cgiroua joined #salt
15:01 agustafson joined #salt
15:01 agustafson1 joined #salt
15:11 asyncsec joined #salt
15:11 racooper joined #salt
15:21 aneeshusa joined #salt
15:31 _JZ_ joined #salt
15:44 izrail joined #salt
15:47 deuscapturus joined #salt
15:54 scarcry joined #salt
16:11 dxiri joined #salt
16:14 pipps joined #salt
16:15 pipps joined #salt
16:19 colegatron left #salt
16:19 dendazen joined #salt
16:31 izibi joined #salt
16:41 edrocks joined #salt
16:42 saltslackbridge <adammike> nitin__: Splay is used to ensure the jobs don't kick off all at the same time
16:42 saltslackbridge <adammike> for example
16:42 saltslackbridge <adammike> you have 10000 minions with the same schedule
16:42 saltslackbridge <adammike> do you really want them all to update influxdb at the same time?
16:42 saltslackbridge <adammike> so you'd specify a splay value and it would randomize the launch time of the job
16:42 saltslackbridge <adammike> within the splay value
16:56 DanyC joined #salt
17:09 tiwula joined #salt
17:16 pcn If I use the client api to instantiate a RunnerClient and execute runner.cmd(), what can I do to get the jobid of that?  I'd like to be able to reference the full output from the runner by logging it in the engine I'm writing, and then extracting it with the job runner
17:16 pcn But I seem to just get a boolean back from cmd()
17:17 DanyC joined #salt
17:20 hoolio joined #salt
17:24 izibi joined #salt
17:25 izibi joined #salt
17:25 major joined #salt
17:26 jeremytiki joined #salt
17:31 Guest86 joined #salt
17:32 Guest86 left #salt
17:32 DanyC joined #salt
17:34 cyborg-one joined #salt
17:41 echoe joined #salt
17:43 onlyanegg joined #salt
17:46 DanyC joined #salt
17:52 zerocoolback joined #salt
17:57 edrocks joined #salt
18:05 jeremytiki joined #salt
18:07 Aleks3Y joined #salt
18:31 mikecmpbll joined #salt
18:38 mikecmpbll joined #salt
18:43 DanyC_ joined #salt
18:58 schemanic Hey everyone. I have a question about structuring application deployments with salt states. I run app servers that run multiple single-tenant applications. I want to re-write our deploy in salt, but I'm struggling conceptually with how to handle isolating the application deploys from one another.
18:59 schemanic My first thought is to write one state called myapp.deploy that iterates through myapp's pillar data, and does a deploy for each key in a certain subdict in the pillar
18:59 onlyanegg joined #salt
19:00 schemanic the question I have it, how do I only run the state for the applications that are meant to be acted on?
19:16 DanyC joined #salt
19:18 onlyanegg joined #salt
19:24 penguincoder joined #salt
19:28 penguincoder is it possible to use salt file.restorecon in an sls? Based on the docs it only shows a CLI example, and I cannot get it to work in an SLS. Here is a paste wtih what I' think should be in the SLS, and the error I'm getting: http://dpaste.com/2PR3PQ9
19:29 schemanic joined #salt
19:33 mikecmpbll joined #salt
19:37 coredumb penguincoder: try something like salt['file.restorecon'](path, recursive)
19:39 coredumb penguincoder: or that https://docs.saltstack.com/en/latest/ref/states/all/salt.states.module.html
19:43 lastjedi joined #salt
19:45 pipps joined #salt
19:47 penguincoder coredumb: thanks for the answer. Using the information at the second link I am able to get the state to apply in test mode - http://dpaste.com/394A26H. How would I go about making sure the restorecon is only performed when the monit package is installed? Is it a mater of adding -onchanges: - cmd: <identifier> ?
19:48 coredumb I guess a watch requisite on the pkg should do the trick
19:49 penguincoder okay, that's what I thought. I will try it. Although, that makes the restorecon state considered a failure...
19:50 ymasson joined #salt
19:50 coredumb why would it be a failure?
19:51 penguincoder yeah, that makes the state 'failed' - http://dpaste.com/0BWBTCG I'll need to look into how to ignore the failure on that.
19:51 coredumb no make a watch on the state that installs your monit package
19:52 coredumb or use onlyif/unless to test if binary exist
19:55 penguincoder I used a -stateful: on the state that installes the package. Is there something else that should be used? http://dpaste.com/3YJCV6E
19:57 nielsk joined #salt
19:57 onlyanegg joined #salt
19:59 coredumb penguincoder: the state monit is not a cmd
19:59 coredumb it's a pkg
19:59 coredumb you should have - onchanges: - pkg: monit instead
19:59 coredumb and stateful in a pkg statement doesn't make sense AFAIC
20:00 coredumb I'm surprised it doesn't even spit out an error
20:00 penguincoder okay, thanks. I changed the sls now to this - http://dpaste.com/0E5A7WN, which seems to work in test.
20:01 penguincoder I want it to install monit and then only do the restorecon after the initial installation, just so it's not running restorecon every update.
20:01 penguincoder now I need to expand that file list out. Probably a good idea to use pillars and templating for that
20:01 coredumb should be fine like that
20:01 penguincoder Thanks coredumb
20:02 coredumb you're welcome
20:02 penguincoder still tryin to learn salt, and best practices for these state files.
20:03 Arendtsen joined #salt
20:03 coredumb sometimes the flexibility in syntax is it's own downfall ... you just have to find the one that suits you and stick with it
20:05 penguincoder and how to apply things. I would have never though based on docs, that the selinux file items had to be used in that module.run manner
20:06 coredumb well you have to understand the difference between exec modules and state modules
20:06 penguincoder is there a better way to manage secontext in salt?
20:07 penguincoder the only option I see for the state is 'encforcing'
20:07 coredumb per file/dir context seems right being under the file module
20:11 lionel joined #salt
20:19 nixjdm joined #salt
20:21 schemanic joined #salt
20:39 yuhl joined #salt
20:43 noraatepernos joined #salt
20:43 yuhl joined #salt
20:52 Manor joined #salt
20:59 mcqueenorama1 joined #salt
21:21 edrocks joined #salt
21:26 yuhl joined #salt
21:29 yuhl joined #salt
21:32 yuhl joined #salt
21:33 astronouth7303 -_- repo.saltstack.org doesn't have armhf, so I use it with my raspberry pi
21:33 astronouth7303 should i file that as a bug?
21:34 astronouth7303 (the work-around is to use the raspbian package, which is 2016.11.2
21:49 aldevar joined #salt
21:50 pipps joined #salt
21:59 aldevar joined #salt
22:03 mikecmpbll joined #salt
22:19 mikecmpb_ joined #salt
22:24 pipps joined #salt
22:26 mikecmpbll joined #salt
22:34 pipps joined #salt
22:35 mikecmpb_ joined #salt
22:38 darioleidi_ joined #salt
22:39 Elsmorian joined #salt
22:42 onlyanegg joined #salt
22:42 dcrouch joined #salt
22:43 pipps joined #salt
22:47 onlyanegg joined #salt
22:52 shoogz joined #salt
22:54 shoogz joined #salt
22:55 shoogz joined #salt
22:56 dxiri joined #salt
22:57 shoogz joined #salt
22:58 shoogz joined #salt
23:00 shoogz joined #salt
23:19 pipps joined #salt
23:21 pipps99 joined #salt
23:29 wevanscfi joined #salt
23:49 pipps joined #salt
23:55 baikal joined #salt

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