Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2018-03-31

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

All times shown according to UTC.

Time Nick Message
00:53 dkehn joined #salt
01:01 dkehn joined #salt
01:20 zerocoolback joined #salt
01:40 zerocoolback joined #salt
01:42 zerocoolback joined #salt
01:56 zerocoolback joined #salt
01:58 ilbot3 joined #salt
01:58 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.9, 2017.7.4 <+> RC for 2018.3.0 is out, please test it! <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic, and https://saltstackcommunity.herokuapp.com (for slack) <+> We are volunteers and may not have immediate answers
02:26 dezertol joined #salt
02:37 zerocoolback joined #salt
02:43 aldevar joined #salt
02:48 zerocoolback joined #salt
02:55 shiranaihito joined #salt
02:55 dsfadasdfasdf joined #salt
02:58 karlthane joined #salt
03:08 sauvin joined #salt
03:08 zerocoolback joined #salt
03:48 zerocoolback joined #salt
03:59 zerocoolback joined #salt
04:21 zerocoolback joined #salt
04:32 zerocoolback joined #salt
04:54 zerocoolback joined #salt
05:00 jas02_ joined #salt
05:03 jas02 joined #salt
05:05 zerocoolback joined #salt
05:13 jas02 joined #salt
05:25 jas02 joined #salt
05:27 justanotheruser joined #salt
05:36 jas02 joined #salt
05:36 justan0theruser joined #salt
05:43 jas02 joined #salt
05:46 aldevar joined #salt
05:49 dvdmuckle joined #salt
05:53 zerocoolback joined #salt
05:55 jas02 joined #salt
06:01 oida joined #salt
06:04 jas02 joined #salt
06:13 evle joined #salt
06:13 jas02 joined #salt
06:20 cro joined #salt
06:25 jas02 joined #salt
06:50 rollniak joined #salt
06:53 jas02 joined #salt
07:04 jas02 joined #salt
07:05 zerocoolback joined #salt
07:50 zerocoolback joined #salt
08:03 sjorge joined #salt
08:03 zerocoolback joined #salt
08:05 rollniak joined #salt
08:29 chowmeined joined #salt
08:41 tyx joined #salt
08:47 aldevar joined #salt
08:50 Hybrid joined #salt
09:14 kukacz joined #salt
09:16 exarkun joined #salt
09:24 sjorge joined #salt
09:32 mavhq joined #salt
09:42 sjorge joined #salt
10:17 sjorge joined #salt
10:17 aviau joined #salt
10:30 hoonetorg joined #salt
10:38 zerocoolback joined #salt
10:56 sjorge joined #salt
11:13 demize joined #salt
11:27 Trauma joined #salt
11:39 aldevar joined #salt
12:05 aldevar joined #salt
12:11 zerocoolback joined #salt
12:27 rollniak joined #salt
12:37 shpoont joined #salt
12:42 Trauma joined #salt
12:53 Trauma joined #salt
12:54 shpoont joined #salt
13:05 XenophonF thanks again babilen - defaults.merge works like a charm
13:05 XenophonF new formula - https://github.com/irtnog/satosa-formula
13:05 XenophonF so here's a formula style question for the crowd
13:06 XenophonF right now I have a bunch of separate top-level Pillar/defaults keys
13:07 XenophonF satosa (formula settings like packages and pathnames), satosa_proxy (proxy_conf.yaml settings), satosa_internal_attributes (internal_attributes.yaml settings), and so forth
13:07 XenophonF I did that to keep from having dictionaries fall off the right edge of the screen LOL
13:07 zerocoolback joined #salt
13:08 XenophonF (SATOSA keeps its configs in YAML, which is nice)
13:11 XenophonF but would it be better to keep everything in one key?
13:11 sjorge joined #salt
13:12 XenophonF so instead of satosa, satosa_proxy, satosa_internal_attributes, etc., I'd have satosa, satosa:proxy, satosa:internal_attributes, etc.?
13:24 evle1 joined #salt
13:40 zerocoolback joined #salt
13:44 demize joined #salt
13:47 demize joined #salt
14:03 zerocoolback joined #salt
14:05 sjorge joined #salt
14:38 zerocoolback joined #salt
14:45 zerocoolback joined #salt
14:53 tiwula joined #salt
15:09 shpoont joined #salt
15:37 demize joined #salt
16:05 aldevar joined #salt
16:16 viq https://pbot.rmdir.de/lOSVRLevFAiUcHHmDGiQLQ  - what am I doing wrong?
16:21 shpoont joined #salt
16:59 justanotheruser joined #salt
17:13 JPaul joined #salt
17:13 matti joined #salt
17:13 matti joined #salt
17:14 jxs1 joined #salt
17:14 tom29739 joined #salt
17:15 k1412 joined #salt
18:33 dendazen joined #salt
18:36 Guest75414 joined #salt
18:40 lukecarrier joined #salt
18:42 lukecarrier Hi! I'm having a strange issue with a file.managed state using a Jinja template where I see a TemplateNotFound error for an import directive, but only when applying the state via docker.sls_build. I had been assuming that passing --local and --file-root to salt-call would set the template search path to include that directory -- have I misunderstood?
18:47 q1x joined #salt
19:04 ponyofdeath joined #salt
19:05 MTecknology isn't config management not supposed to exist within docker?
19:06 iggy if the docker stuff behaves anything like salt-ssh, you may have to tell it to include extra files
19:07 iggy f.ex. salt-ssh has --extra-filerefs
19:10 viq MTecknology: this is using config management as instructions to build the container image
19:10 viq There are similiar concepts for puppet and chef, from what I've seen. Alas, I don't know off-hand how --file-root works
19:11 viq Right now I'm getting beaten by thorium
19:14 viq On one host it works, on another it says it cannot find thorium top.sls file
19:19 aldevar joined #salt
19:23 lukecarrier MTecknology: sure, but being able to use Salt to both manage configuration and orchestrate container image builds is pretty handy for hybrid environments
19:24 lukecarrier iggy: thanks for hint, have found a few similar tickets around salt-ssh that suggest that option, none specifically related to the docker module as of yet. Will give it a shot :)
19:25 shpoont joined #salt
19:28 aldevar joined #salt
19:31 zer0def isn't docker's idea to get configuration preferrably from envvars?
19:34 lukecarrier zer0def: you still have to install software on the containers in the first place... the docker module allows applying states to a base container image in order to build another image
19:36 zer0def well, if you insist on using salt for building your images, you might want to take a peek at packer, since it's not horribly designed; the potential drawback is that you'll end up with a single-layered image, though
19:40 viq But with packer you're still pretty much building your container with bash, instead of DSL
19:41 zer0def why bash? you can use salt-masterless
19:42 viq Which is kinda what they're trying to do, minus packer ;)
19:43 viq I'm finding https://habitat.sh interesting - though tring to put salt in it fails horribly
19:43 viq https://forums.habitat.sh/t/plan-for-saltstack-having-issues/457/7 kind of horribly
19:45 zer0def nice advertising
19:46 zer0def of a product that breaks with intended case :P
19:46 viq I find the idea very interesting, this was my "hey, I'm having issues with salt-master running on archlinux and thorium and slack reactors, it seems to work better when running installed in virtualenv from pip, but that feels a bit dirty. I'll try habitat!"
19:47 viq Well, it works for a lot of people with a lot of applications. It's just salt that appears to do some strange things with how it loads libraries
19:47 zer0def so basically appimage? :P
19:48 zer0def or anything between appimage, flatpak and snaps
19:48 MTecknology packer is a neat tool if it fits your goals
19:49 MTecknology I never liked it, but always respected it as a solution for those goals
19:49 zer0def well, given the case of building a container image with salt, seemed appropriate to mention
19:49 viq Well, habitat does more, since it also gives you for free a supervisor, service discovery, way to manage config of your app and sync it between instances, and ability to output the package as a docker container
19:50 zer0def so it's basically a whole container cluster orchestrator
19:50 MTecknology does more... doesn't mean does good :P
19:51 zer0def i'm pretty sure that's shoving way too large of a software package into too narrow of a use case, effectively bloating horribly
19:51 viq That I cannot comment on.
19:52 viq Since my first attempt at running something in it ended up with people who know it responding with "It does what??" :P
19:53 zer0def the manner in which you've described it, also makes it look like a superset of any cluster orchestration, yet somehow useful for image building
19:56 viq ish, you still need cluster orchestration to tell cluster how many to run, and what ports to expose, but inside the container you have "how do I start the app", "how to apply configuration" and "how to find other instances of the app / things I should talk to" taken care of for you, from what I understand
19:57 viq And you don't need to figure out what distro to base your container on, and how to install things into the container, since the app itself (with versioned dependencies) becomes the image.
19:58 zer0def the more you're trying to convince me of its supposed benefits, the more you're convincing me to not use it
20:00 zer0def "how do i start the app?" - provide the command or rely on image's default; "how to apply configuration?" - the app-container paradigm clearly favorizes envvars, so make sure your image handles them accordingly in entrypoint; "how to find other instances of the app?" is something container orchestration (most prevalently, kubernetes) does
20:00 shpoont joined #salt
20:00 viq *shrug* I find it an interesting idea, I don't have a horse in this race otherwise.
20:00 viq Well, yes and no, I believe you still need some support for what kubernetes exposes inside the app/container
20:01 viq For service discovery I mean.
20:01 zer0def you sure have something in mind for how specifically vague you are
20:02 zer0def every container orchestrator follows purpose-groups of containers by periodically health checking
20:03 viq eh, nevermind. I don't know enough about most of those things to provide concrete arguments, and I don't have direct experience with them.
20:04 zer0def from that point, you usually use virtual ips or dns names to target particular apps
20:07 Dev0n joined #salt
20:17 lukecarrier zer0def: why introduce another tool into the release process when we already have the states written up for Salt? I've used Packer+BoxStarter for working with Windows images, but I'm not sure I see a compelling reason to use it in this case
20:21 zer0def as far as i can tell, all you really need to do is shove your file_roots (and optionally pillar_roots) through packer into your intended image build process for it to do a `salt-call --local`
20:22 lukecarrier ...but that's exactly what docker.sls_build already does: https://docs.saltstack.com/en/develop/ref/modules/all/salt.modules.docker.html#salt.modules.docker.sls_build
20:23 shpoont joined #salt
20:26 shpoont joined #salt
20:26 zer0def ok, i wasn't aware this existed
20:27 zer0def certainly didn't when i was on the hunt for something akin to this
20:28 armyriad joined #salt
20:30 petererer joined #salt
20:32 lukecarrier zer0def: yep, it's only been usable for a couple of months now. AFAIK there's no way to set CMD/ENTRYPOINT at the moment, you don't have grains so you have to use environments to target configuration and there's some limitations of templating that seem to be shared with salt-ssh
20:33 lukecarrier It's a neat feature, I hope others adopt it so it gets some polish. I don't really know enough of Salt's internals to contribute anything substantial :/
20:34 zer0def haven't bumped into a solution other than Dockerfile that would set up CMD/ENTRYPOINT; salt-ssh does leverage grains, though
20:37 lukecarrier I wouldn't imagine it's too difficult to add those two options to sls_build
20:38 zer0def the function tasked with running those sls files sure seems to be shoving grains into the pillar: https://github.com/saltstack/salt/blob/develop/salt/modules/dockermod.py#L6743
20:38 MTecknology The more I see docker, the more I hate docker.
20:39 lukecarrier hmm, so you could template /etc/salt/grains then build on it
20:39 lukecarrier MTecknology: yeah I'm kinda with you, k8s makes it difficult ignore though. It has its virtues in the wider ecosystem, makes software deployment/scheduling and integration _much_ simpler
20:40 MTecknology in my experience, it's not that useful outside of aws
20:41 lukecarrier MTecknology: it's a heckuva lot easier to maintain local developer environments with Compose than Vagrant
20:41 MTecknology k?
20:42 lukecarrier All of the major CI platforms look to be converging around Docker too, so you can run tests against the same environment you deploy on for free
20:42 zer0def i'm inclined to agree that it makes easier for developers and testing environments, not quite as inclined for production systems
20:43 MTecknology docker is good for spinning up envs to run test cases, but I don't see it's value beyond that market.
20:43 lukecarrier This is probably akin to swearing around these parts, but AKS (Azure Container Service) tames Kubernetes a little. I'd be surprised if similar offerings weren't arriving from other vendors
20:44 zer0def the main tangible benefit i can come up with is that your software package isn't dependent on a distro config
20:45 MTecknology "package"? in the sense of .rpm or .deb?
20:45 zer0def more like concept of a project's repo
20:45 zer0def since it basically comes with it's own chroot
20:46 lukecarrier plus saner service discovery and separation of ephemeral and enduring state by default, both of which ease scaling out
20:46 zer0def but even then it still can fall over, if your ABI isn't glibc :P
20:48 zer0def i'm still not quite convinced by the service discovery argument, since you're still pointing your apps to some sort of endpoint that doesn't have to guarantee availability
20:49 zer0def whether that endpoint is handled by the container cluster, it is just a webserver with an inner domain name pointed to it or is just a bouncer to your database, conceptually it's still referring to an API and a predetermined point :P
20:49 zer0def s/and a/at a/
20:50 zer0def and, in the case of dc/os, it's basically just haproxy with some sprinkles inside
21:13 sjorge joined #salt
21:18 lukecarrier true, it's only a convention
21:19 lukecarrier right, I'm out... will dig into how Salt packages up the state/pillar trees tomorrow
21:33 hrumph joined #salt
21:44 sjorge joined #salt
21:45 hooksie1 joined #salt
22:03 mavhq joined #salt
22:07 jab416171 joined #salt
22:32 kline left #salt
22:58 johnkeates joined #salt
23:06 zulutango joined #salt
23:10 justan0theruser joined #salt
23:11 justan0theruser joined #salt
23:14 viq joined #salt
23:43 hrumph hi
23:43 hrumph what governs whether or not a salt runner will be using python 3 or not?

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