Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-05-25

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

All times shown according to UTC.

Time Nick Message
00:02 brousch__ joined #salt
00:05 Edgan nm, figured out I have to explicitly change it on the master :\
00:09 justan0theruser joined #salt
00:24 coval3nce joined #salt
00:28 mavhq joined #salt
00:32 Antiarc joined #salt
00:50 sh123124213 joined #salt
00:55 mikecmpbll joined #salt
00:59 Praematura_ joined #salt
01:01 onlyanegg joined #salt
01:14 sh123124213 joined #salt
01:14 _JZ__ joined #salt
01:23 MTecknology is ext_pillar available to pillar?
01:26 whytewolf MTecknology: iirc you have to set this to true and then in thoery yes. https://salt.readthedocs.io/en/stable/ref/configuration/master.html#ext-pillar-first
01:26 whytewolf never tried it personally just going off of what i have heard
01:28 debian112 joined #salt
01:32 MTecknology excellent!
01:41 __number5__ MTecknology: ext_pillar to pillar just like custom grains to graius
01:46 __number5__ so whatever you return in ext_pillar will be available in `pillar.get` etc.
01:46 MTecknology Now I just need to get that far..
01:46 MTecknology __number5__: you know anything about salt cloud?
01:48 XenophonF MTecknology: what do you want to know re: salt-cloud?
01:51 MTecknology XenophonF: I'm tring to s/salt-cloud/salt-call cloud.*/ so I can move everything into pillar (except for cloud.map.. until the nitrogren release). I have etc/salt/cloud.{providers,profiles}.d/* moved to pillar @ cloud:{profiles,providers}:*  I used to be able to successfully run most queries except for list images on proxmox. Now, I can list my proxmox nodes as locations but DO shows no
01:52 MTecknology locations. (all DO queries used to work w/ salt-cloud and static files).
01:52 MTecknology DO =>  Failed to get the output of 'digital_ocean.avail_locations()': Invalid header value 'Bearer 1404c43fa6ca300dc836989377e91cfad434281919eb13edd3101c2945dfd627\n'
01:53 MTecknology hopefully that's not some secret token I just pasted..
01:54 hrumph joined #salt
01:54 MTecknology ah, nope.. time to re-issue the access token.
01:55 XenophonF :-D
01:56 MTecknology all done, back to the original problem
01:56 dendazen joined #salt
01:57 XenophonF ok so you're using cloud states instead of salt-cloud to do stuff, right?
01:58 XenophonF and the right api token or whatever is in the salt-minion's config?
01:58 XenophonF could just be that the exec module is buggy
01:58 XenophonF i use aws w/ salt-cloud but maybe i can set that up here
01:59 MTecknology profiles and providers are in pillar for the master's salt-minion process
02:00 pbandark joined #salt
02:01 MTecknology I get a feeling there's a whole lot of buggy in here. I'm wondering if I could just run develop on the master without breaking everything for a little while
02:02 SaucyElf joined #salt
02:02 zerocoolback joined #salt
02:06 __number5__ MTecknology: know nothing about salt-cloud, we use Terraform for provisioning to AWS
02:07 jas02 joined #salt
02:08 masterinire joined #salt
02:31 PatrolDoom joined #salt
02:34 MTecknology time for more pudb.... pee yew
02:38 onlyanegg joined #salt
02:43 gmoro joined #salt
02:51 evle joined #salt
02:53 MTecknology XenophonF: you familiar with pudb?
02:53 justanotheruser joined #salt
02:56 prg3 joined #salt
02:58 XenophonF no
02:58 MTecknology You should be! :D
02:59 XenophonF weren't you the one telling me to learn pycharm? or was that someone else?
02:59 MTecknology nope, definitely not me
02:59 XenophonF i'll check it out!
02:59 XenophonF a full-screen on-console python debugger, eh?
02:59 XenophonF noice
03:00 MTecknology AFAICT, the exact correct request is being made from api.py. This should definitely be working.
03:01 walker joined #salt
03:01 MTecknology It seems to be every bit as powerful as the visual studio debugger, just for a good language instead.
03:02 XenophonF LOL
03:02 XenophonF i might have an immediate need for it
03:02 XenophonF git.is_worktree isn't returning true for a git clone that salt made :(
03:02 MTecknology pudb /usr/bin/salt-call ...
03:03 MTecknology n a few times, s, a few more n's, then another s, and spelunking you shall go
03:05 XenophonF oh new verson of salt's available
03:05 XenophonF i'd better upgrade first
03:05 XenophonF spelunking after
03:05 SaucyElf joined #salt
03:05 MTecknology OH!!!! FFS!!!
03:05 * XenophonF prays "please fix this bug, please fix this bug, please fix this bug"
03:05 MTecknology Authorization': 'Bearer $foo\n'
03:06 XenophonF oh no
03:07 MTecknology That doesn't really make sense since this wasn't working before I updated the token, but let's make dang sure no newline and try again. :S
03:08 XenophonF there's a \n in the error message you pasted earlier
03:08 walker joined #salt
03:12 MTecknology well.. that was the problem
03:19 nethershaw joined #salt
03:31 MTecknology XenophonF: Maybe you can confirm this for me. I see no way to set any 'location=' in [1] if coming from [2]...  [1] https://github.com/saltstack/salt/blob/develop/salt/cloud/clouds/proxmox.py#L395 [2] https://github.com/saltstack/salt/blob/develop/salt/cloud/__init__.py#L869
03:37 MTecknology It almost looks like that should just blindly accept and pass kwargs to the cloud provider. I'm sure that's not a small task and would take lots of extra work, but it also looks like others may need the same thing?..
04:11 MTecknology ... and here we go!  https://github.com/saltstack/salt/issues/40621
04:18 Praematura joined #salt
04:23 jdshewey joined #salt
04:24 jdshewey Is anyone able to answer https://devops.stackexchange.com/questions/1238/how-can-a-share-a-global-variable-between-salt-states
04:25 hemebond jdshewey: Generate it manually and put it into a pillar?
04:27 jdshewey @Homebound - I need a unique OTP for each host. I could stick it into a pillar, but I still need a unique string for each and every run. For security reasons, I'd also rather keep it locally on the client as much as possible.
04:27 hemebond Oh it has to be unique for each run? That's okay then.
04:28 jdshewey Homebound: Runs also couldn't conflict. So If I defined it as a pillar, wouldn't I have two hosts using the same OTP if I do a > salt '*' state.apply assuing I have two unprovisioned hosts?
04:28 jdshewey *assuming
04:28 hemebond No. You could generate the OTP in a pillar and it would be generated for each host.
04:33 jdshewey Hmm. That's not ideal, but it could work. I'm trying to keep the pillar as user friendly and uncomplicated as possible. I might try generating a random string as a grain instead to see if it can keep it out of the pillar sls...
04:33 hemebond Not ideal?
04:34 hemebond Why? Just so you don't have Jinja in your pillar?
04:36 jdshewey More or less. The more the pillar is just strait, static YAML, the easier it it is for the uninitiated to figure out. The more I clutter it with jinja ifs, and random funciton calls, the harder it becomes to understand and deploy. Really the pillar should be passing parameters to a
04:37 jdshewey "black box" the more I can keep the code and heavy lifting in the black box, the better.
04:37 jdshewey Or at least in the case.
04:38 jdshewey Trying to keep the hard work (looping, branching, ifs, function calls) in the state files as much as possible.
04:39 whytewolf well you could make a grain module that sets a new otp every grain refresh.
04:39 jdshewey That's kind of what I am thinking...
04:41 whytewolf but i wouldn't run a highstate more then once an hour
04:43 jdshewey Are the high states/grains not calculated uniquely for each client run?
04:43 whytewolf as for the pillar method it really would just be otp: {{salt['random.get_str'](20)}}
04:44 whytewolf there is a refresh. but it can be turned off. which means it isn't a gerentee they are fresh
04:44 whytewolf everything is tested against the cache. so a otp grain might refresh every highstate.
04:46 whytewolf and it would have to be a module it couldn't be set in a state or jinja
04:48 jdshewey Hmm. I'm actually a bit surprised it doesn't work as is. You would think the Jinja would render a single YAML file and that otp variable would be accessible in both places when the jinja is rendered (assuming your ordering is correct) or at least you would be able to access
04:48 jdshewey freeipa.example.otp.
04:48 whytewolf each file is rendered indavidually
04:49 whytewolf and there is no shared registery among them
04:49 jdshewey I am also surprised there is not a pillar.set function to set pillar data (locally) on the fly.
04:49 whytewolf pillar isn't local. it is rendered on the master and sent to the minion
04:50 jdshewey Good to know. I was under the impression they rendered into (essentially) one big state file.
04:50 whytewolf oh they are rendered into one big state file. the jinja render happens before that
04:50 jdshewey Ohhhhhhh.... OK. That makes sense then.
04:52 jdshewey As for the pillar data being rendered on the master - I was aware of that. But I would expect a pillar.set would allow you to insert data into (what I assume is) the local dict on-the-fly.
04:52 jdshewey Seems like it would be handy. Maybe I'll open a feature request...
04:54 whytewolf i would rather not have pillar mutable on the minion side.
04:54 sh123124213 joined #salt
04:55 whytewolf mostly because of formulas
04:55 MTecknology seems like that would be a scary idea... having minions manipulate pillar data on-the-fly?
04:56 jdshewey Maybe if, instead of making it mutable (eg, can't override a value) you could just add to existing data?
04:57 MTecknology that's still manipulating pillar
04:57 whytewolf i would rather use a third data system.
04:57 whytewolf one that is basicly a registry
04:57 MTecknology didn't you just describe sdb?
04:57 whytewolf ;) now your getting it
04:58 MTecknology ooooh... so have them use pillar to populate sdb and then read values from sdb! :D
04:58 MTecknology (not serious.. dear god, please, no.. don't)
04:58 MTecknology $client would..
04:58 seanz joined #salt
04:59 beardedeagle joined #salt
04:59 seanz joined #salt
04:59 whytewolf $client needs a lesson in logic and practice
04:59 seanz Is the ext_pillar module intended to "just work"?
04:59 whytewolf which one?
04:59 seanz By configuring it and restarting the salt master, does it get checked out automatically?
04:59 whytewolf ext_pillar is a set of modules
05:00 seanz Hm. I'm lacking info.
05:00 seanz I'm using salt-master 2016.11.5 (Carbon).
05:00 whytewolf so am i
05:00 seanz :)
05:00 seanz What info should I give?
05:00 seanz I configured the git ext_pillar.
05:00 prg3 joined #salt
05:01 MTecknology seanz: as far as the config goes, ya.. if you have auth configured, just restart the master and it should get checked out
05:01 whytewolf do you have a git python module installed?
05:01 seanz pgit2 0.25.1.
05:01 seanz I was getting git checkout errors, but I resolved those.
05:01 whytewolf okay. restart the master. and run salt-run git_pillar.update -l debug
05:02 seanz Ah…trying that!
05:02 MTecknology git_pillar.update... a thing I just learned about today that I thought was covered in fileserver.update which has been a headache for a while... now I know why.
05:03 seanz I got a False back, but at least that's progress!
05:03 lorengordon joined #salt
05:03 whytewolf False could mean that it already is on the current version
05:03 * MTecknology has python-git and python-gitdb installed
05:03 armyriad joined #salt
05:04 seanz Ah…that's misleading but lines up with the "success" "true" output.
05:04 MTecknology whytewolf: you sure? it always shows True for me. I can run it ten times back to back and get True. Or is that an older bug?
05:05 whytewolf I'm pretty sure it is correct. it always returns false for me. when i don't have updates.
05:05 whytewolf but let me double check if i am crossing that with fileserver.update
05:05 whytewolf [remeber i don't run these commands often alone]
05:06 MTecknology heheh.. true
05:06 seanz whytewolf: So if I'm still getting pillar rendering errors, does that mean salt isn't picking up my env settings?
05:06 MTecknology I wouldn't be surprised if it's a behavior change in newer versions.
05:06 MTecknology seanz: look at master logs
05:06 whytewolf git_pillar remote 'master git@github.com:whytewolf/salt-phase0-pillar.git' is up-to-date and it returned False
05:06 MTecknology or your debug output
05:06 MTecknology what version?
05:07 MTecknology http://dpaste.com/276WME8
05:07 whytewolf 2016.11.5
05:07 MTecknology I'm on 2016.3
05:07 seanz Ah…how about that. The log output indicates the error.
05:07 seanz It is something I can correct.
05:07 whytewolf funny how that works :P
05:08 MTecknology I lied, I'm on 2016.11.3
05:09 whytewolf humm, interesting. the event had this info 'return': {'master git@github.com:whytewolf/salt-phase0-pillar.git': False}, 'success': True
05:09 MTecknology OH!
05:09 MTecknology cli_summary:
05:10 MTecknology nope, that didn't change anything. dunno
05:10 whytewolf it is strange. my pillar is prety static. the only time i Get a True is when i update something then run that
05:11 whytewolf maybe it is because i am on github and you have a local repo?
05:11 whytewolf yours might actually be updating a header every time
05:11 whytewolf and i wouldn't be surprised if githubs git is strange
05:12 MTecknology that went over my head, but I can take your word for it
05:15 * whytewolf shrugs. it is working for us both.
05:15 Bock joined #salt
05:15 * MTecknology groans. Once --list-images is working, I'm going to move on to trying to create a VM and I expect that to not work.
05:15 whytewolf good luck. that prox cloud module looks pretty raw.
05:17 impi joined #salt
05:17 * whytewolf kinda wishes _cloud and _fileserver were a thing
05:18 seanz whytewolf: I'm back on track; thank you for helping me out.
05:18 whytewolf np
05:19 whytewolf MTecknology: was th one that suggested checking the logs though
05:19 MTecknology I'm about to suggest whiskey until I pass out.
05:19 seanz MTecknology: Sorry, didn't mean to forget you! The logs are what pointed me in the right direction once I confirmed that git-pillar was working.
05:20 whytewolf a whiskey does sound good. but i could really use a rum.
05:23 _JZ_ joined #salt
05:29 feld joined #salt
05:32 watersoul joined #salt
05:36 borgstrom joined #salt
05:37 watersoul joined #salt
05:42 prg3 joined #salt
05:49 Kanoxbox_ joined #salt
05:51 candyman88 joined #salt
05:53 gnomethrower_ joined #salt
05:58 armyriad joined #salt
06:02 capnhex joined #salt
06:11 gnord joined #salt
06:17 Kanoxbox_1 joined #salt
06:23 inad922 joined #salt
06:26 capnhex joined #salt
06:38 onlyanegg joined #salt
06:42 Ricardo1000 joined #salt
07:03 rayanimesh joined #salt
07:07 xet7 joined #salt
07:16 jas02 joined #salt
07:17 jas02 joined #salt
07:18 mpanetta joined #salt
07:19 feld joined #salt
07:20 darioleidi joined #salt
07:28 justan0theruser joined #salt
07:29 pbandark joined #salt
07:33 Inveracity joined #salt
07:34 pbandark joined #salt
07:34 preludedrew joined #salt
07:35 cyteen joined #salt
07:35 candyman88 joined #salt
07:38 mikecmpbll joined #salt
07:49 darioleidi joined #salt
07:49 Rumbles joined #salt
07:50 evle joined #salt
07:53 LondonAppDev joined #salt
07:57 mavhq joined #salt
08:00 Sammichmaker joined #salt
08:07 Kanoxbox_ joined #salt
08:08 Kanoxbox_ joined #salt
08:09 Kanoxbox_ joined #salt
08:10 mikecmpbll joined #salt
08:11 impi joined #salt
08:11 Kanoxbox_ joined #salt
08:13 Kanoxbox_ joined #salt
08:14 Kanoxbox_ joined #salt
08:14 zulutango joined #salt
08:15 Kanoxbox_ joined #salt
08:17 Kanoxbox_ joined #salt
08:18 Kanoxbox_ joined #salt
08:20 Mattch joined #salt
08:24 k_sze[work] joined #salt
08:28 om2 joined #salt
08:31 capnhex Morning, I have been trying to use file.directory to set the group ownership of a directory to a group which contains spaces 'domain computers' Whenever I then run the state it says:
08:31 capnhex Group domain computers is not available
08:31 capnhex
08:31 capnhex Heres a snip of the state file:
08:31 capnhex file.directory:
08:31 capnhex - name: /var/log/archive
08:31 capnhex - group: 'domain computers'
08:31 capnhex - dir_mode: 775
08:31 capnhex - file_mode: 644
08:31 capnhex
08:31 capnhex However if I replace 'domain computers' with the gid of that group it works fine,
08:31 capnhex - group: 76600515
08:32 capnhex dering if this was expected or if file.directory should handle spaces in group names but I'm escaping it incorrectly?
08:33 capnhex And sorry - I was expecting that all to go through as one message :(
08:35 Neighbour IRC doesn't work that way...this is fine
08:37 capnhex Thought I'd check here before raising a github issue.
08:37 teclator joined #salt
08:39 onlyanegg joined #salt
08:39 candyman88 joined #salt
08:43 Kanoxbox_ joined #salt
08:45 Kanoxbox_ joined #salt
08:45 Kanoxbox_ joined #salt
08:47 Kanoxbox_ joined #salt
08:49 Kanoxbox_ joined #salt
08:50 Kanoxbox_ joined #salt
08:52 Kanoxbox_ joined #salt
08:54 babilen capnhex: On which platform are you setting this?
08:54 babilen (that's not a valid group name on many)
08:54 capnhex Centos 6
08:55 babilen Did they relax the specification to allow for spaces in the group name?
08:55 babilen Or whitespace
08:55 capnhex but the group itself is via kerberos/sssd from Active Directory.
08:55 babilen Ah, so it's some Windows shit?
08:56 capnhex Yup!
08:56 capnhex But all my work is on the linux devices.
08:56 babilen In that case I would identify it by GID rather than an invalid group name
08:57 babilen You normally want your user/group names to match [a-z_][a-z0-9_-]*[$]? -- Debian relaxes this a little in that they "must neither start with a dash ('-') nor plus ('+') nor tilde ('~') nor contain a colon (':'), a comma (','), or a whitespace (space:' ', end of line: '\n', tabulation: '\t',"
08:57 capnhex You can't add a group with a space in to a server using 'groupadd' but you can chown or chgrp a file using the group name
08:58 babilen See useradd(8)/groupadd(8)
08:58 babilen Well, it's really using the GID and the name mapping probably comes from your AD integration
08:58 babilen The name, in and of itself, is still invalid
08:59 babilen Maybe you can replace spaces with underscores
09:01 babilen http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276 is what POSIX allows
09:02 capnhex Given I don't have control of the AD infrastructure I can't rename the group. (and other parts of the overall system may rely on the name of that group remaining as it is) Are you saying that the state file is expecting an underscore instead of the space?
09:03 babilen Depending on your AD mapping that could work
09:03 babilen Do you know if the GID is stable?
09:03 babilen (stable as in 'not changing')
09:04 capnhex Not sure. I'm hoping so - I used the GID to prove that  the group existed and I could change the group ownership. And the few servers I've looked at have the same ID. But I don't know enough about how it works under the covers to know if that is the case indefinitely.
09:07 babilen Figure out how AD is integrated .. it should, IMHO, be solved on that layer. You could also check if escaping the space is working for you
09:09 babilen I mean .. in the end these are conventions and different libraries will implement the user/group name handling differently. My recommendation would be to stick to the conventions as code is most likely to work in that case (as evidenced by your problem)
09:09 SaltNPeppa joined #salt
09:10 impi joined #salt
09:11 DamageInc joined #salt
09:11 babilen By escaping I am referring to something like: "domain\ computers"
09:13 capnhex Thanks babilen. I've tried multiple ways to escape the space with no success so far before I got here, and its unlikely that I'd be able to change the mappings so I'm probably going to need to stick with the GID for now.
09:13 capnhex Given salt is cross platform though I wonder if it should be able to support group names which do contain spaces if the future?
09:14 candyman88 joined #salt
09:14 babilen If file.* can be used like that on MS Windows, then sure ..
09:14 * babilen wonders what dir_mode: 755 does there
09:14 babilen capnhex: Have you tried the underscore?
09:15 capnhex let me try that now...
09:15 babilen Or investigated how AD is integrated?
09:17 DamageInc left #salt
09:17 kedare joined #salt
09:17 kedare Hi all :)
09:18 kedare Question about the gitfs, something is not very clear, is the gitfs pulled only on the master and then the minions get the files from the master, or the minion get the files directly from the git repositories ?
09:18 IPutTheScrewInTh joined #salt
09:19 babilen The former
09:19 capnhex RE :AD integration. it uses sssd to connect to AD, it's taken years of iteration to tune the settings right so realistically it would not be changed for my relatively small project when I have a working workoaround. But I will take a look into this later for insight.
09:20 kedare babilen, Only the master access the repository so ?
09:20 babilen capnhex: All I'm saying is that the "whitespace in user/groupnames" problem might have been solved already
09:21 babilen kedare: That's what I was trying to allude to, yeah
09:21 capnhex Here's the results of the underscore test: 'Group domain_computers is not available' so unfortunately that won't work :(
09:21 kedare Thanks :)
09:21 babilen capnhex: Fair enough
09:22 kedare Basically what would be the difference between using gitfs or using rootfs with a directory inside my saltstack configuration that is already on a git repository ? What would be the recommended option ?
09:25 inad922 joined #salt
09:25 capnhex funily enough - on a test box I created a non AD group with a space inthe name "spacey groupname" (by editing /etc/group) and could  successfully "salt-call file.chgrp /srv/spacey 'spacey groupname' " to set the group ownership. so that might be a way forward.
09:30 SaltyVagrant_ joined #salt
09:33 babilen kedare: There wouldn't be a difference
09:34 babilen Apart from the fact that GitFS handles the checkout and update stuff on fileserver.refresh
09:35 kedare Ok :)
09:35 kedare Thanks
09:35 om2_ joined #salt
09:35 inad922 joined #salt
09:36 capnhex Thanks for your help earlier @babilen much appreciated.
09:38 babilen capnhex: I hope for your sanity that GIDs are stable and that you could just use them. Whitespace in user/group names will cause you endless pain and there might be a good way to solve that issue (e.g. by defining a clear mapping on the AD layer)
09:42 fredvd joined #salt
09:45 Reverend capnhex - trust me, babilen is the true hero in this channel 90% of the time. s/he is unbelieveable.
09:46 Reverend it'd be kinda cool is babilen was some really fancy AI
09:46 Reverend :D
09:46 capnhex :)
09:46 babilen capnhex: Look into override_space for sssd
09:46 capnhex FAB!
09:48 babilen https://www.systutorials.com/docs/linux/man/5-sssd.conf/ → override_space (string): "This parameter will replace spaces (space bar) with the given character for user and group names. e.g. (_). User name "john doe" will be "john_doe" This feature was added to help compatibility with shell scripts that have difficulty handling spaces, due to the default field separator in the shell."
09:50 babilen Reverend: "he" btw :)
09:50 gmoro_ joined #salt
09:58 darioleidi joined #salt
10:01 lorengordon fwiw, we've used pbis-open to join centos6 boxes to an AD domain. works quite well. it defaults to '^' for overriding spaces in group names
10:05 Reverend babilen: i love you... fyi. just saying. I think I owe you some pizza or something. The amount of times you've helped out is amazing :) keep up the good work sir!
10:05 pbandark cant we use "-name" option with "pkg.group_installed" ? as its failing for me: https://paste.fedoraproject.org/paste/0E5CXl~qno27AQJbrHx-XF5M1UNdIGYhyRLivL9gydE=
10:08 kedare Is there a way to tell the cmd.script to use specific parameters when calling the interpreter ? In my case it's adding automatically a -NoProfile and I would like do run the script without this switch (Powershell)
10:11 Mattch joined #salt
10:12 capnhex I've also been looking at the salt code (which I'm slow at!! ) and I think it uses the python 'grp' module under the covers which is able to return a gid for the 'domain computers' group. I'll dig higher up!
10:17 haam3r_ kedare: Seems that the NoProfile is hardcoded in the code...but if you can somehow tell the cmd.script module to use the 'encode_cmd' parameter, then the -NoProfile switch is not used
10:18 haam3r_ kedare: Take a look at: https://github.com/saltstack/salt/blob/develop/salt/modules/cmdmod.py#L336
10:30 dendazen joined #salt
10:32 cyborg-one joined #salt
10:36 pbandark anyone  ^^ ?
10:40 onlyanegg joined #salt
10:40 babilen pbandark: I would expect that to work *exactly* as you used it. I take it that it works if you use the group name as state ID?
10:41 pbandark let me confirm. but yes I guess it should work with group name as state ID
10:42 megamaced joined #salt
11:00 pbandark babilen: sorry. it was my mistake in specifying the group name. me--  :(
11:00 pbandark thanks for looking into it babilen
11:01 babilen pbandark: What was the mistake?
11:02 pbandark I am using external pillar where I have specified "group name" as list. but, in salt state file I forgot that I am using list and I used "- name: {{ cpp['packages'] }}"  where it should be "- name: {{ cpp['packages'][0] }}"
11:03 kedare haam3r_, I found another way at the end, thanks :)
11:03 kedare Another small question, about winrepo, is there a way to use a package defined on the saltstack winrepo but provide my own parameters ? (Typically the install location)
11:03 babilen pbandark: So you didn't actually use the state you pasted?
11:04 pbandark yeah. I though to keep things simple and replaced the values in state file :(
11:04 babilen Don't do that :)
11:04 pbandark :)
11:04 babilen It just makes it impossible to help
11:04 sh123124213 joined #salt
11:04 pbandark yeah.. sorry for that
11:05 babilen No worries, but wrong assumptions are quite often the underlying problem and you just don't spot them if you work with "sanitised" code :)
11:33 Elsmorian joined #salt
11:39 evle joined #salt
11:59 Kanoxbox_ joined #salt
12:00 thinkt4nk joined #salt
12:02 Kanoxbox_ joined #salt
12:03 thinkt4n_ joined #salt
12:06 toastedpenguin joined #salt
12:17 Praematura joined #salt
12:17 XenophonF kedare: i haven't had a chance to play with this yet, but winrepo-ng now lets you use jinja (etc.)
12:17 XenophonF if those files get rendered on the minion side, you can pass parameters that way
12:18 XenophonF if you figure it out, pls msg me because i want to be able to customize windows package installs, too
12:21 XenophonF does anyone out there have a git repo they can test git.is_worktree against?
12:22 XenophonF i want to know if it's only broken for me for some reason
12:22 puzzlingWeirdo joined #salt
12:22 XenophonF i'm running `salt-call git.is_worktree /path`, which returns False
12:22 XenophonF but `git rev-parse --show-toplevel` returns /path, so I think I found a bug
12:25 Reverend joined #salt
12:29 darioleidi joined #salt
12:33 chrysanthemum joined #salt
12:34 zerocoolback joined #salt
12:35 zerocool_ joined #salt
12:37 dendazen joined #salt
12:41 onlyanegg joined #salt
12:43 impi joined #salt
12:46 thinkt4nk joined #salt
12:53 Trauma joined #salt
12:54 kedare How can I know if a winrepo is correctly loaded ? I've configured one, it get it from git correctly but I cannot use it with pkg.install, it cannot see any package from this repository
12:54 kedare Same with : salt-run winrepo.genrepo, the packages from this repository are not in the list
12:55 Kanoxbox_ joined #salt
12:55 amcorreia joined #salt
12:56 Kanoxbox_ joined #salt
12:57 Kanoxbox_ joined #salt
12:58 kedare Also when I try to use salt "my-minion" pkg.available_version xxx, I always get : 'pkg.available_version' is not available
12:59 Kanoxbox_ joined #salt
12:59 kedare I don't need the repositories to be listed in file_roots right ?
13:00 prg3 joined #salt
13:01 Kanoxbox_ joined #salt
13:04 snarked joined #salt
13:04 aldevar joined #salt
13:06 XenophonF so for winrepo-ng your packages won't show up in winrepo.genrepo
13:06 XenophonF and in fact i don't think winrepo.genrepo is necessary
13:07 XenophonF lemme check my notes + TFM
13:07 kedare No it's not needed on latest versions
13:07 kedare Oh ok so yes my packages are in -ng, I though they would all be shown
13:08 kedare I added them in file_roots but same thing, even with packages from the standard repositories like firefox, it cannot find anything
13:08 XenophonF you should just have to do `salt-run winrepo.update_git_repos` followed by `salt -G 'os:windows' pkg.refresh_db`
13:09 XenophonF i vaguely recall running into problems with environments...
13:09 kedare And the refresh_db only shows 0 everywhere, I don't know if it's normal
13:09 Vasya666 joined #salt
13:10 XenophonF did you try to install a package?
13:10 kedare Yes
13:10 kedare salt "bcn6-web-staging-1" pkg.install firefox => Unable to locate package firefox
13:11 XenophonF oh yeah - here's the problem I ran into with environments
13:11 kedare environments ?
13:13 XenophonF basically, the win/repo and win/repo-ng directories only get generated in the base environment
13:13 edrocks joined #salt
13:13 XenophonF so i ran into some problems when running pkg.installed states in other environments
13:13 kedare I'm only using the base environment
13:14 kedare There's nothing else to do than having the repositories cloned to have it working right ? Nothing to put in the pillar or state ?
13:14 XenophonF so in your master config, you've set `winrepo_remotes_ng` to a list of git remotes, right?
13:15 XenophonF hang on I'll show you mine
13:15 kedare Yes
13:15 kedare And they are both cloned successfully
13:15 kedare (Well the default one and another private one)
13:15 XenophonF hm i didn't have to clone anything
13:16 kedare No no, using the winrepo.update_git_repos I mean
13:16 kedare If I go to the locations of the clone I can see that all the files from the repository are there
13:18 swills joined #salt
13:20 XenophonF https://github.com/irtnog/salt-pillar-example/blob/master/salt/example/com/init.sls#L258
13:20 XenophonF anything in the master error logs?
13:20 XenophonF or minion?
13:21 kedare https://pastebin.com/1QhjwBBH
13:21 kedare Let me check
13:22 cyborg-one joined #salt
13:22 XenophonF the winrepo dirs don't need to be in file_roots
13:22 XenophonF oh
13:22 XenophonF rather
13:22 kedare Oh ok, I added them in doubt
13:22 XenophonF their parent directory needs to be in file_roots
13:22 kedare so repo-ng in my case ?
13:22 XenophonF that's why it doesn't work
13:22 kedare or win/ ?
13:23 XenophonF salt://win/repo-ng/... needs to resolve to /srv/salt/win/repo-ng/...
13:23 XenophonF by default /srv/salt is in file roots but you broke it
13:23 XenophonF ;)
13:23 kedare Hmm ok, so I need to put /etc/salt in the file_roots ?
13:24 swills joined #salt
13:24 XenophonF effectively
13:24 kedare I remove everything else so ? As everything is already in subdirectories of /etc/salt
13:24 XenophonF well no that will break other stuff you've already done
13:25 kedare Ok, let me try
13:26 XenophonF e.g., if you have states under /srv/salt/git/states, replacing that with /srv/salt will make all of your SLS IDs change to git.states.whatever instead of whatever
13:26 kedare Ok that was that :)
13:26 kedare Yes I tough of that after
13:26 kedare Thanks ! :)
13:28 XenophonF yay!
13:35 SaucyElf joined #salt
13:36 XenophonF so why the hell isn't cron.present updating the command that job runs?
13:40 impi joined #salt
13:40 swills joined #salt
13:41 XenophonF oh duh i am overriding the command in pillar
13:41 XenophonF :(
13:45 SaucyElf joined #salt
13:46 debian112 joined #salt
13:46 kedare Also another question, can we use pillar in pillar definition ? For example somewhere I have the pillar application_environent that I want to reuse somewhere else when defining other pillars
13:52 SaucyElf joined #salt
13:52 XenophonF so generally no
13:53 XenophonF because pillar SLS render time comes before pillar SLS parse/load time
13:53 XenophonF (compare renderers like Jinja with how a C preprocessor works)
13:53 XenophonF BUT
13:53 XenophonF there are a few ways to workaround this
13:54 XenophonF I think pillarstack is the canonical example.
13:54 XenophonF I don't like it
13:54 XenophonF if I have default values i want to use in multiple pillars, i tend to use jinja + import_whatever, like import_yaml or import_json
13:55 XenophonF maybe someone else can chime in here?
13:55 XenophonF oh there are also tricks like YAML backreferences, which are actually rather powerful but only work within a single file IIRC
13:56 coval3nce joined #salt
13:56 PatrolDoom joined #salt
13:56 onlyanegg joined #salt
13:57 ssplatt joined #salt
13:59 sh123124213 joined #salt
13:59 kedare Hmm ok, I don't know yet how I'll do that, or I'll just do if in the .sls level of my states
14:00 Neighbour the order is grains -> ext_pillar (if so defined in master config) -> pillar
14:00 Neighbour However, you can update pillar values in orchestration sls files, and pass the 'new' pillar to salt.state calls
14:06 johnkeates joined #salt
14:09 desku joined #salt
14:10 ventris joined #salt
14:12 johnkeates anyone know if salt's gonna get straight with LDAP users? Currently, things like file.directory fail when permissions refer to a user that's not local but in LDAP. chown from the shell works fine
14:14 _JZ_ joined #salt
14:18 ventris joined #salt
14:18 Praematura joined #salt
14:23 XenophonF hm, let me test that johnkeates
14:24 johnkeates it's basically this: https://github.com/saltstack/salt/issues/23947
14:24 johnkeates right now i have to do something stupid like cmd.run 'salt-call state.apply' to get the pwd module to cooperate
14:24 XenophonF hm works for me but i'm using NIS to pull in users from Active Directory
14:24 johnkeates i'm using SSSD, LDAP and FreeIPA
14:25 sarcasticadmin joined #salt
14:25 johnkeates tools like getent and id report correct data, but salt doesn't always get it right :(
14:26 XenophonF that's really freaking weird
14:26 XenophonF b/c it should ultimately use the libc getpw* routines
14:26 XenophonF which should DTRT
14:27 XenophonF ever hear of pudb?
14:27 johnkeates no, what's pudb
14:27 XenophonF it's a full screen console debugger for python
14:27 XenophonF might be worth tracing the file.directory funcall
14:28 XenophonF that's an awfully old bug :(
14:28 johnkeates yep
14:28 johnkeates i should probably debug this to solve it for everyone
14:28 dxiri joined #salt
14:29 XenophonF if you don't i'll probably end up hitting that bug in the next month or so, b/c you just described a directory service i'm building out for work
14:29 XenophonF so i'd be mighty obliged ;)
14:29 johnkeates haha, I can imagine ;-)
14:29 johnkeates whats weird too is that *sometimes* with doing a state.apply with -ltrace it works too
14:29 XenophonF ???
14:30 XenophonF that sounds like a timing issue
14:30 johnkeates as if tracing increases the runtime which fixes race conditions or timeouts
14:30 johnkeates but salt-call on the minion always works
14:30 johnkeates and salt with no trace never works
14:30 johnkeates this is mind-boggling
14:31 XenophonF i assume this is linux - but what dist/vers?
14:31 johnkeates must be in the python module used for getting pw stuff
14:31 johnkeates Debian 8
14:31 johnkeates salt 2016.11.5
14:31 johnkeates also using Fedora 25, same issue
14:32 johnkeates i bet that means it's also broken on CentOS, RHEL, Ubuntu etc..
14:33 XenophonF most likely
14:34 mikecmpbll joined #salt
14:36 johnkeates it appears a comparable issue exists and i was +1 that too https://github.com/saltstack/salt/issues/12803
14:36 johnkeates so sad
14:37 Yamazaki-kun joined #salt
14:37 kedare Another small question about winrepo, I could install the package for the first time without issue, but when I run the state again, it's trying to reinstall it, and it's failing, did I do something wrong ? https://gist.github.com/kedare/144a0438890db2c42cdba3551c4e8ad9
14:39 kedare Is it related to the fact that it's named xxx-python3 ?
14:40 justan0theruser joined #salt
14:40 kedare Because it's quite similar to the official Python3 ones : https://github.com/saltstack/salt-winrepo-ng/blob/master/python3_x64.sls
14:41 Kanoxbox_ joined #salt
14:41 babilen Kelsar: use underscores
14:41 babilen kedare: ^
14:41 johnkeates of, if you are a hipster: use overscores
14:41 PatrolDoom pfft
14:42 Kanoxbox_ joined #salt
14:43 kedare Hmm I can try, that's what is causing the issue ?
14:45 woodtablet joined #salt
14:51 feld joined #salt
14:55 zerocoolback joined #salt
14:55 GMAzrael_ joined #salt
14:56 colegatron joined #salt
15:01 jas02 joined #salt
15:11 numkem joined #salt
15:11 zerocoolback joined #salt
15:12 mikecmpbll joined #salt
15:15 kedare Hmm ok I used underscore and now I have something different : https://gist.github.com/kedare/2129d6487f34fcf698b866427b9218a3
15:15 kedare The state is shown as failed but the package install status as success
15:16 kedare Also something else that should be simple for you, I'm trying to force an order on those tasks : https://gist.github.com/kedare/79d9c9117333351da0a45cc5fe35b02b
15:16 kedare But the files get cleaned before the script is ran
15:16 kedare Am I doing something wrong ?
15:17 SaucyElf joined #salt
15:21 jmiven joined #salt
15:22 haam3r_ require statement should be: - cmd: Install specific GAC modules
15:23 kedare Oh ok
15:23 kedare Let me try
15:23 haam3r_ The generalized form of a requisite target is <state name> : <ID or name>
15:23 dev_tea If I'm using the manage.key_regen runner in an environment with syndics, does it need to be run just on the master of masters or also on each syndics?
15:24 haam3r_ this is from: https://docs.saltstack.com/en/latest/ref/states/requisites.html
15:25 racooper joined #salt
15:27 kedare Hmm when adding cmd:, I'm getting "https://docs.saltstack.com/en/latest/ref/states/requisites.html" for all of them
15:27 kedare Wrong paste xD
15:27 kedare "The following requisites were not found"
15:28 kedare I updated the Gist
15:30 kedare Or cmd: should not be used on both case there ?
15:32 kedare Hmm ok when I just use cmd: in the last case, it's working apparently
15:32 kedare So there's no way to just point a state (of wathever type) as dependency ? Depending of the type of task it's a different way ?
15:33 mavhq joined #salt
15:39 kedare Ok no even with that it's failing... What I don't understand is that when I run this specific state with state.apply mystate it's working fine
15:40 kedare But when I run it through the state.highstate, it's not the same order inside this state
15:40 kedare I had the same behaviour before
15:40 rmelero joined #salt
15:41 hashwagon joined #salt
15:45 onlyanegg joined #salt
15:48 duckfez joined #salt
15:48 randomsaltynick joined #salt
15:49 v0rtex joined #salt
15:49 utahcon joined #salt
15:50 dimeshake joined #salt
15:52 jas02 joined #salt
15:53 sillywilly joined #salt
15:58 raspado joined #salt
15:59 kedare Time to leave, see you tomorrow :)
15:59 kedare And thanks for your help
16:00 GMAzrael joined #salt
16:01 raspado_ joined #salt
16:02 Kanoxbox_ joined #salt
16:03 lovelyday joined #salt
16:03 lovelyday left #salt
16:04 Kanoxbox_ joined #salt
16:05 Kanoxbox_ joined #salt
16:05 sillywilly I'm trying to configure a printer on Windows via Salt with the PrintUI library. If I run this command (https://gist.github.com/wimurphy/bada34f170adc97d7e1de06840912802) through Salt (salt 'machinename' cmd.run), everything seems to pass, but the settings don't propagate. However, if I run the same command through the CMD on the machine, everything works and the settings propagate
16:06 Kanoxbox_ joined #salt
16:08 Kanoxbox_ joined #salt
16:09 Kanoxbox_ joined #salt
16:10 Kanoxbox_ joined #salt
16:11 TomJepp joined #salt
16:18 SaltyVagrant joined #salt
16:19 jab416171 joined #salt
16:20 _JZ_ joined #salt
16:21 Kanoxbox_ joined #salt
16:23 Kanoxbox_ joined #salt
16:25 onlyanegg I'm not familiar with using Salt for windows. Can you run `salt-call -l debug cmd.run ...` on the windows machine?
16:26 onlyanegg salt-call usually gives you better debug logs
16:28 xet7 joined #salt
16:30 mavhq joined #salt
16:37 major do the master and minions have an implicit watch on their own configs?
16:39 babilen major: They don't .. you can manage salt with salt-formula though
16:40 major is there some provision for rolling back the master/minion configs should any changes result in a restart failure?
16:46 babilen I don't think so
16:46 major hmm
16:48 edrocks joined #salt
16:53 armyriad joined #salt
16:55 thinkt4n_ joined #salt
16:57 jas02 joined #salt
16:58 sillywilly It seems to be an issue with the service worker.
16:58 sillywilly I ran the salt-minion directly in the cmd and the settings propagated. When Salt Minion runs as a service it failed
17:00 edrocks joined #salt
17:02 sillywilly The issue is with permissions on the service. If I attach the user credentials to the service it works. I now need to find a way to do so programmatically. Windows sucks, lads. Wouldn't touch it
17:02 raspado joined #salt
17:04 MSUTriGeek joined #salt
17:17 pbandark Hi.. I want to create state file which will check if package version is specified in pillar or not. if its pillar then install the package with specified version. but if the version is not provided in pillar then simply install the package to latest version. i have created https://paste.fedoraproject.org/paste/dk3WA2HazdSyqeuCg-xQiV5M1UNdIGYhyRLivL9gydE=  but it fails if i specify package without version.  can anyone help me on the same ?
17:18 pbandark *if its *specified* in pillar then*
17:20 Trauma joined #salt
17:21 Renich joined #salt
17:21 major soo .. has there been any progress made on pre-commit hooks for testing salt syntax .. and possibly even doing mock runs w/out contacting any minions?
17:25 Kanoxbox_ joined #salt
17:26 Edgan major: for the mock stuff, people use test-kitchen
17:26 major wrong mock?
17:27 major salt-call state.highstate --file-root=$PWD --local --retcode-passthrough mocked=True
17:27 Edgan major: I took your use of mock as testing without taking to the "production" instances
17:27 Kanoxbox_ joined #salt
17:28 Edgan major: I believe more in actual testing before commiting code. I use salt-ssh for this.
17:29 Kanoxbox_ joined #salt
17:29 Edgan major: some people use docker and other use vagrant
17:29 Tom__ joined #salt
17:29 Edgan major: I prefer to operate against actual instances
17:29 major seems a fairly heavy lifting option to find a possible simple syntax check
17:30 major I sort of prefer tiering my tests.. *shrug*
17:30 Kanoxbox_ joined #salt
17:30 Edgan major: I use syntax checking in Atom
17:31 Edgan major: I do agree that commit/push hooks would be nice. The problem is git is decentralized, and local hooks are not enforcable and require more setup.
17:31 Edgan major: It is the same people with trying to enforce ssh key passwords
17:31 rmelero +1 for Atom. Sometimes i have to bust out http://jinja2test.tk/
17:31 major yah, but the thing about syntax checking states is that you really can't tell if you misnamed a variable or something w/out unlayering everything
17:31 Kanoxbox_ joined #salt
17:31 Edgan major: A less than ideal but enforcable model I have used before is a push hook. The problem with that is if you are using github.com, you can't do push hooks.
17:32 major options like test=True and mocked=True sort of help in doing some syntax checking .. it just isn't all that deep .. and mocked=True tends to want special permissions
17:32 Edgan major: But you also can't know you didn't name the package name wrong without actual testing it either.
17:32 major right, which is why I do tests in tiers
17:33 Kanoxbox_ joined #salt
17:34 major can certainly do pre-commit hooks and do your tests locally via git w/out worring about push hooks
17:34 Edgan major: Also your laptop might be OSX, Windows, etc and salt-call locally might not behave the same as it would on an actual instance. This is where docker/vagrant can come in. Docker's model of one service is why I don't use it. Vagrant has too many special cases to cover for my test, after experience.
17:34 rmelero would take awhile, but what about something like a .travis.yml build?
17:34 major I try not to push until I have tested stuff .. and even taken a moment to clean-up/rebase my unpublished changes to make the change history more concise
17:35 major Edgan, well .. like I was asking .. has pre-commit testing come along any further than test=True and mocked=True
17:35 major like .. a salt-lint would be sort of nice
17:36 major less interested in being sold on an alternate development model honestly
17:36 walker joined #salt
17:36 * major shrugs.
17:36 Kanoxbox_ joined #salt
17:36 major hmmm ... https://github.com/jfroche/salt-lint
17:40 Edgan major: People haven't spent enough time to develop a real salt linter.
17:40 Edgan major: There is an open issue for it
17:40 major yah, I noticed
17:41 Edgan major: Part of the reason is salt code is really just yaml+jinja, so checking both will get you along.
17:41 whytewolf a salt linter would have to work in three parts. render engine linting, yaml linting, then finally salt linting
17:41 Edgan major: I have seen a puppet linter, but it is it's own stand alone syntax, so someone had to start from scratch
17:42 walker joined #salt
17:42 major yah .. and I have some puppet code that causes puppet-lint to segfault...
17:42 whytewolf most of that can be handeled simpley by showing the highstate or lowstate
17:42 whytewolf state.show_highstate
17:42 Edgan whytewolf: and that is assuming you only use yaml and jinja. You could be using wempy, mako, etc.
17:42 major right, most of what I have in my checks works w/ those
17:42 Edgan whytewolf: he wants automation of this low level testing
17:43 SaucyElf joined #salt
17:43 whytewolf Edgan: thats why i said render engine. it should output data objects that get covered by the second level render
17:44 Edgan whytewolf: doesn't have to be yaml either, but yes, we agree
17:44 whytewolf automation of low level? jenkins and vm's smoke testing some times is the easiest way
17:45 Edgan whytewolf: It just wrote the code 30 seconds ago, he hasn't committed it, and he wants to syntax check it before he commits
17:45 Edgan whytewolf: jenkins is well down the line
17:45 Edgan major: what text editor do you use?
17:46 whytewolf ah, yeah that is a problem then cause salt doesn't spit out error codes for even the most basic of stuff sometimes
17:46 major Edgan, vim
17:47 whytewolf vim? salt-vim is nice for handaling basic syntax checking. wouldn't call it a linter though
17:47 major yah .. have the vundle installed
17:47 major it certainly helps
17:48 whytewolf ... vundle is just a package manager for vim
17:48 whytewolf s/package/plugin
17:48 walker joined #salt
17:48 major well .. I have the vundle for the vim-salt installed
17:49 major or vim bundle, or whatever it wants to be called :)
17:49 nixjdm joined #salt
17:49 whytewolf vundle has nothing to do with salt-vim :P it just installs it from git. :P
17:50 nixjdm joined #salt
17:50 major well .. it was the first installation information in the README.md that I followed ..
17:50 major the Option #2 method was to manually clone it and do a bunch of copying/linking of files ..
17:50 whytewolf don't get me wrong, vundle is nice. makes vim plugins easy to manage.
17:51 whytewolf i use it myself
17:51 whytewolf but i odn't tell people that i use yum version of mysql. i just say i am using mysql
17:52 major fair enough
17:52 major though you might still say that you installed the mysql rpm
17:53 whytewolf only if i was having install problems ;)
17:53 major but your point is still taken
17:53 major hmm
17:53 major right
17:53 major I am not certain I understand salt-call
17:54 whytewolf what isn't there to understand about it
17:54 whytewolf it runs commands locally
17:54 whytewolf thats about it
17:55 major thinking I am failing to grok how to make it run w/out privs when mocked=True
17:56 whytewolf mocked=True never even seen that option before
17:59 whytewolf and most likely you might not get it to work with out privs
18:00 candyman88 joined #salt
18:02 prg3 joined #salt
18:02 major seems making a testing config and using it via --config-dir="${PWD}/testing" works fairly well
18:07 Edgan major: I very seriously recommend you switch to Atom. I am a vim user too, and vim can be made to do most of what Atom does. But it is harder, and Atom is still better at it.
18:07 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.3.6, 2016.11.5 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic <+> We are volunteers and may not have immediate answers
18:08 Edgan major: I say this from the writing Salt code and programming in general prespective. Not from the editing a config file perspective, or via ssh.
18:13 mavhq joined #salt
18:18 Edgan rmelero: What Atom packages do you use?
18:19 rmelero language-yaml and atom-jinja2 for salt related stuffings
18:20 Edgan rmelero: language-salt, linter-js-yaml, language-yaml, atom-jinja2
18:21 rmelero ew nice. gunna get those too
18:21 Edgan rmelero: autocomplete-python and language-python
18:22 rmelero yup got those
18:22 MSUTriGeek joined #salt
18:23 testuser_ joined #salt
18:23 Edgan rmelero: do you know about sync-settings?
18:23 MSUTriGeek hello
18:24 Edgan MSUTriGeek: whats up?
18:24 MSUTriGeek is it possible to query for a list of minions that fit a particular set of grains and return the minion ids?
18:25 rmelero I have it installed, but haven't configured it. haven't switched dev machine in a while since i got a mbp from work
18:25 MSUTriGeek I know I could do a simple test.ping with the grains specified but I want to target a group of minions that are powered down and the test.ping would take quite a while to return
18:25 Edgan rmelero: https://gist.github.com/edgan/bffb45205f1c8b7feb80f86658abc872
18:25 rmelero best i've been able to find it running it with -l debug and that'll give you a list of targeted hosts
18:26 rmelero `salt \* test.ping -l debug` for example.
18:26 Edgan MSUTriGeek: You could try creating a mock module to return the list without doing anything
18:28 capnhex joined #salt
18:29 schemanic joined #salt
18:29 schemanic hi
18:29 schemanic I can't seem to find a place on the saltstack page that lists the standard 'library' of grains
18:30 MSUTriGeek thanks!
18:30 schemanic I found them. sorry: https://docs.saltstack.com/en/latest/ref/grains/all/salt.grains.core.html
18:31 whytewolf that actually doens't tell you much about the grains, just the functions that create them
18:38 onlyanegg joined #salt
18:41 MSUTriGeek has anyone taken the saltstack training classes?
18:41 xet7 joined #salt
18:41 MSUTriGeek considering trying to convince my company to send me to one or both of them
18:42 whytewolf company i worked at last was one of the first companies to take them. I still was better at salt then everyone who went [and i didn't go cause i already had another job lined up]
18:43 whytewolf not saying they don't help.
18:43 whytewolf they did improve
18:45 MSUTriGeek I've been using basic salt stuff for management for years now. I'm a little worried the first class will be all repeat info
18:45 MSUTriGeek but they seem to require the basic class before you can take the advanced one
18:45 MSUTriGeek thanks for the feedback whytewolf
18:47 whytewolf to be fair the guys that went to the class before the class were using bash scripts to run cmd.run lines. and had no want of even looking at switching off of that
18:47 whytewolf it was a nightmare
18:48 rmelero "I'll never give up my emacs!"
18:48 MSUTriGeek haha yow
18:51 whytewolf coarse the guy above me wanted to use reactor to auto reboot windows boxes. I basicly told him. that yes that would work. but if you can't get your guys to at least use states. reactor is just not really going to do anything for you.
18:58 watersoul joined #salt
18:59 MichaelB is there anything I'm missing that stops 'salt 'deploy*' pillar.get core:env saltenv=base' from getting core:env from my base environment
19:00 MichaelB I suspect I'm doing something stupid! but I've no idea what that might be
19:00 MichaelB (it seems to always return from my dev env)
19:03 euidzero joined #salt
19:03 walker joined #salt
19:04 carmony joined #salt
19:12 MichaelB it seems to be something very similar to this - https://github.com/saltstack/salt/issues/30234
19:12 saltstackbot [#30234][MERGED] Pillar Environment not working with the parameter pillarenv=qa u others environments | Version SaltStack 2015.8.3 (Beryllium)...
19:14 schemanic does saltstackbot post when there is a code updatE?
19:14 mikecmpbll joined #salt
19:14 Trauma joined #salt
19:15 MichaelB joined #salt
19:15 cscf group.present for www-logs tries to create the group and fails, because it already exists
19:16 MichaelB did my previous message get through? I'm not sure if I may have got booted
19:16 MichaelB I appear to be having the same problem - https://github.com/saltstack/salt/issues/30234
19:16 saltstackbot [#30234][MERGED] Pillar Environment not working with the parameter pillarenv=qa u others environments | Version SaltStack 2015.8.3 (Beryllium)...
19:17 cscf MichaelB, yup, I see both
19:17 cyborg-one joined #salt
19:18 MichaelB is it possible to use a single minion to run against multiple environments?
19:19 cscf MichaelB, a single minion applying states from different envs to the same host?
19:19 DammitJim joined #salt
19:19 DammitJim how do you guys deal with ssh key generation per server?
19:20 MichaelB I have a Windows minion acting as a bridgehead into Azure - so doing all of the orchestration via PowerShell
19:20 cscf DammitJim, host key or id_rsa?
19:21 DammitJim cscf, I'm assuming id_rsa
19:21 MichaelB so yes, basically I'm wanting it to run states from all envs
19:21 DammitJim so, a private key to put in the client server and the public key to put on the server
19:22 DammitJim or at this time, it's all about cmd.run ?
19:22 Praematura_ joined #salt
19:34 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.3.6, 2016.11.5 <+> Support: https://www.saltstack.com/support/ <+> 1st Salt Cloud Working Group meeting June 1st, 2017 https://goo.gl/o2OK49 <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic <+> We are volunteers and may not have immediate answers
19:36 puzzlingWeirdo joined #salt
19:36 cscf MichaelB, that sounds horrifying
19:36 cscf MichaelB, there's probably a better way to solve your problem than that
19:37 MichaelB Well I was hoping it would be reasonably easy! - I've got a bunch of PS scripts that need fit in with orchestrating other stuff
19:38 MichaelB so figured I could just have a bridgehead for those...
19:38 whytewolf sounds like what you want is a syndic master
19:38 MichaelB how would that fit in?
19:39 whytewolf well, minions only care about themselves.
19:39 whytewolf masters don't
19:39 MichaelB (I'll probably deploy one for running inside vnets)
19:40 MichaelB I'm not sure what that solves in this scenario?
19:40 whytewolf well sounds like you are trying to turn a minion into a master to perform tasks on other systems.
19:40 whytewolf if that is not the case ignore what i said
19:41 MichaelB I'm trying to run some Powershell scripts on a bridgehead box - and configuring that to be capable of running all environments
19:42 whytewolf yeah i don't see that happening
19:42 whytewolf enviroments are finiky to begin with
19:42 MichaelB well, I wouldn't want it being easy :)
19:45 whytewolf well, it can have an enviroment set in the config. other wise it won't be able to see them all. then all of the states need to have seperate id's between all of the enviroments. and the top file needs to have configurations for that box in all of the enviroments. and then you need to be able to run a highstate for each enviroment. and that isn't getting into pillar which most likely just won't work at
19:45 whytewolf all. as it is going to merge enviroments together
19:45 whytewolf can't not can
19:46 MichaelB all of the stuff that is running against the bridgehead is going to be running as orchestrations - can I pass that different pillars?
19:48 whytewolf passing pillar to your orchestration run only passes that to the orchestration not to the underling states.
19:48 whytewolf you need to add - pillars to each stanza in your orchestration to give it the set of pillars
19:48 whytewolf and i think there are saltmod functions that don't take - pillars
19:50 whytewolf you are not looking at impossable. but it is looking like a land war in asia levels of difficulty
19:50 walker joined #salt
19:52 MichaelB so kinda like going against a Sicilian when death is on the line then
19:53 MichaelB so would it be possible to build all of the pillars into one - and chose between them with a variable?
19:53 whytewolf lookup tables. i do that all of the time.
19:54 whytewolf but they have to be setup in the states
19:54 MichaelB well I'm writing all the states from scratch anyway - at the moment I'm just figuring out how to make it work
19:55 whytewolf i would say find a way to drop the munging of the enviroments.
19:55 whytewolf if you can get past that hurdle the rest should be a cake walk
19:56 Neighbour whytewolf: salt.state takes a pillar argument...you can hide everything behind that :)
19:57 whytewolf Neighbour: yes, but not evenrything can be neatly put away into states :P sometimes salt.function is needed.
19:57 puzzling1 joined #salt
19:57 Neighbour whytewolf: Sure, but you can call module.run from a state :)
19:57 major is there a way to specify multiple file_roots from the CLI?
19:57 MichaelB munging of environments?
19:58 whytewolf the multiple enviroment requirment
19:58 whytewolf major: try a list. ['path1','path2'] not sure it will work but it has the best chance
20:00 major yah .. doesn't seem to work
20:00 whytewolf anddddd. meeting time
20:00 Neighbour whytewolf: I've got an orchestration setup that salt.states sls-files to various minions, and if there are specific module.function calls required to be done by a minion, that is called from a such a state file using module.run
20:05 whytewolf and yes i know about module.run ... i try and avoid it on purpase. it isn't that clean if you have a module that needs name
20:06 Neighbour you get used to m_name :)
20:08 prg3 joined #salt
20:09 MichaelB so if at the top of my state file I have something like {% set env = pillar['env'] %}  - and set that with salt '*' state.apply test pillar='{"env": "dev"}' < is that likely to do what I want?
20:12 Kanoxbox_ joined #salt
20:12 Neighbour If you want the jinja variable 'env' to contain 'dev', yes
20:12 walker joined #salt
20:13 Kanoxbox_ joined #salt
20:14 Kanoxbox_ joined #salt
20:14 Herman joined #salt
20:14 MichaelB any obvious downfalls for that?
20:15 Kanoxbox_ joined #salt
20:18 MSUTriGeek joined #salt
20:20 Herman Im (running RHEL7.0) having a dependency issue where the salt repo want's to update yum-utils to 1.1.31-29.el7, but needs yum-3.4.3-120, the RHEL7 repo does not provide that yet and only has 3.4.3-118 which is currently installed. Any idea?
20:21 gtmanfred you probably need to move to a newer version of rhel
20:27 sjorge joined #salt
20:27 Herman My rhel repo version is now 7.0, and my saltstack repo is 7, but I see several on the salt server 7, 7.0 and 7Server etc...
20:28 prg3 joined #salt
20:29 Herman all repo's in my satellite synced and up to date
20:30 edrocks joined #salt
20:32 N-Mi joined #salt
20:32 N-Mi joined #salt
20:33 gtmanfred rhel 7.3 is the newest rhel version
20:34 gtmanfred actually
20:34 Herman yes I am aware of that, but one of our software suppliers currently does not support the latest.
20:34 gtmanfred if you do a yum search do you see yum-utils available at all?
20:35 gtmanfred oh, sorry
20:35 gtmanfred I would say that you need to contact your software supplier to figure out why you have a newer version of yum-utils but not yum?
20:39 patrek joined #salt
20:39 Herman salt has a newer version of yum-utils, but the redhat repo does not have the required yum version, I would think that salt should follow redhat when it comes to yum?
20:40 gtmanfred there is no yum-utils in our repo as far as I am aware http://repo.saltstack.com/yum/redhat/7/x86_64/latest/
20:40 gtmanfred oh, it is in the base
20:40 amcorreia joined #salt
20:41 gtmanfred if you install epel, you do not need the base repository, otherwise, please open an issue for david on the salt-pack issues page
20:41 gtmanfred https://github.com/saltstack/salt-pack
20:45 prg3 joined #salt
20:46 Herman tnx gtmanfred
20:47 gtmanfred no problem, sorry it took me a bit to figure out what you were actually seeing
20:48 Herman no worries, tnx!
20:50 Diaoul joined #salt
20:52 major hmm .. can't use gitfs_roots w/ salt-call?
20:52 major and can't figure out a way to specify multiple --file-root entries...
20:53 whytewolf you can with masterless.
20:53 whytewolf [not using cli passed options
20:53 whytewolf https://docs.saltstack.com/en/latest/topics/tutorials/quickstart.html
20:54 major oh
20:54 major so specify them in the master file..
20:54 major doh
20:54 major okay .. so salt-call --local ....
20:54 major thanks
20:55 whytewolf basicly, either be masterless and get gitfs, or use a master and don't use --local
20:55 major this is still for testing stuff
20:56 fracklen joined #salt
20:56 whytewolf yes, that doens't change anything
21:09 major sigh
21:09 major file_roots do not support relative paths? not even relative to root_dir?
21:17 fracklen joined #salt
21:17 mavhq joined #salt
21:19 major and .. gitfs_remotes do not seem to be working for me with salt-call --local (nor with file_client: local) .. version issue?
21:20 whytewolf minion config
21:20 whytewolf not master config
21:20 major yah .. its in the minion file
21:22 whytewolf https://github.com/saltstack/salt/issues/6660 this says it works
21:22 saltstackbot [#6660][MERGED] salt-call --local with gitfs | I would like to propose the gitfs support for salt-call....
21:22 Ryan_Lane gtmanfred: howdy
21:23 gtmanfred Ryan_Lane: hi
21:23 Ryan_Lane pretty sure I can make the salt-cloud meeting, but I have concerns that definitely don't fit into 30m :)
21:23 whytewolf i think it is just the first of many meetings.
21:24 gtmanfred that is the plan ^^
21:24 Ryan_Lane well, I don't want to derail it, it's just that I think the way it's implemented is just fundamentally wrong
21:24 gtmanfred we are also planning on working getting a slack setup for more discussions as we add more working groups
21:25 Ryan_Lane basically right now salt-cloud is essentially just another CLI
21:25 Ryan_Lane and since all of it's in core, it's impossible to backport things, it's impossible to extend it effectively
21:25 gtmanfred so, the goal is to standardize it so that all the functions can be used from the cloud module and state, and to have a standard format across all the providers
21:26 Ryan_Lane the approach taken in the boto_* modules is _way_ better
21:26 SalanderLives joined #salt
21:26 major well .. it certainly doesn't seem to be working for me..
21:26 gtmanfred we could have a cloud_lb module, etc
21:27 Ryan_Lane the AWS support in the boto_* stuff is really, really extensive
21:27 gtmanfred Ryan_Lane: i want to model it after the way the boto modules work, but have the main code be driven from teh drivers
21:27 Ryan_Lane why can't the salt-cloud stuff just hook into the normal module/state system?
21:27 major everything else works .. just not the gitfs_remotes
21:27 whytewolf major: what version are you on?
21:28 Ryan_Lane fundamentally, salt-cloud should work more like terraform
21:28 major salt-call 2015.8.8 (Beryllium)
21:28 Ryan_Lane it's what we're actually competing against
21:28 gtmanfred how about this
21:28 gtmanfred we create a new cloud modules subsystem
21:28 gtmanfred that is used by salt-cloud and by the cloud modules
21:29 gtmanfred and the cloud runner
21:29 Ryan_Lane here's the thing, though. I don't _want_ to use salt-cloud. I never, ever want to call the cli.
21:29 whytewolf you don't have to call the cli
21:29 Ryan_Lane and I don't want to rewrite or port any of the modules
21:29 gtmanfred that is fine, i am not saying you should, but i want to come up with a central place to put the code so it can be used in salt-cloud, salt-run and salt-call
21:30 Ryan_Lane salt-run and salt-call can currently use the modules and states
21:30 Ryan_Lane so why don't we make salt-cloud use the module and state system?
21:31 whytewolf https://docs.saltstack.com/en/latest/ref/states/all/salt.states.cloud.html
21:31 gtmanfred can you draw up a path on how you would setup the salt-run and salt-cloud to share the code with salt cloud modules and states, and then we can talk about it,beacuse i already have a vision in how I want to organize this better than it is being organized right now
21:31 Ryan_Lane my general issue is that the AWS support is _really_ great
21:32 Ryan_Lane and the rest of the cloud support is..... not so great
21:32 Ryan_Lane and a lot of the reason behind this is because people have been really good at adding new state and execution modules
21:32 whytewolf yes, but following the boto_* path for all clouds is the worst plan ever
21:32 Ryan_Lane why is it?
21:32 Ryan_Lane this is basically how terraform is modeled
21:32 whytewolf because that would be thousands of moduels to maintain
21:33 Ryan_Lane that's a _good_ thing
21:33 whytewolf no, it isn't. that is a logistical nightmare
21:33 Ryan_Lane the reason salt-cloud is limited in usefulness is that it tries to be generic
21:33 [Jacek] joined #salt
21:33 Ryan_Lane the reason terraform is what everyone is using right now is because it isn't generic
21:33 [Jacek] left #salt
21:34 Ryan_Lane and the reason for that is because people don't want to just create ec2 instances
21:34 Ryan_Lane they want to create dynamodb tables, SQS queues, redshift databases
21:34 Ryan_Lane in GCP they want to create spanner databases and tables, they want to create GKE clusters, etc.
21:34 Ryan_Lane you can't do any of that generically across the clouds
21:35 Ryan_Lane when you make tooling generic across clouds you get the most limited amount of support, because it needs to work across all the clouds
21:35 Ryan_Lane this is why libcloud is a shitty API, for instance
21:36 lorengordon my vote would also be for more boto_*-like modules
21:36 Ryan_Lane also, it means that people that know AWS really well, for instance, can work on the boto modules and ignore all the other ones
21:36 Ryan_Lane and people who know GCP can write against those
21:36 Ryan_Lane and no one has to worry about breaking support for other clouds
21:36 whytewolf does salt have the man ower to maintain that many modules?
21:37 Ryan_Lane saltstackinc doesn't support the boto modules basically at all
21:37 Ryan_Lane lyft is the primary maintainer of those
21:37 lorengordon though i could see dropping them behind something like the "provider" feature, so they don't all have to be called as "boto_"
21:37 Ryan_Lane and we'll likely start adding some gcp modules that look similar to the boto ones
21:38 Ryan_Lane lorengordon: yeah, for generic stuff you can have state modules call the underlying provider ones
21:38 whytewolf so, how does the boto_* states install salt onto the underlying system?
21:38 Ryan_Lane so we could have the "cloud" module do vendor independent stuff and map it to the vendor dependent stuff
21:38 Ryan_Lane whytewolf: they don't and that's a plus
21:39 whytewolf how do you handle that, because it is needed for some setups
21:39 Ryan_Lane salt-cloud still doesn't support autoscale groups, right?
21:39 Ryan_Lane you have to use a reactor for that
21:39 whytewolf react to what?
21:39 whytewolf no minion spin up
21:39 whytewolf means no event
21:40 Ryan_Lane you can't use the salt-cloud model for autoscale groups, is what I'm saying
21:40 whytewolf actually i have seen it done
21:40 Ryan_Lane people use salt reactors for this
21:40 Ryan_Lane you have to
21:40 Ryan_Lane because you don't control spin up of the nodes
21:41 Ryan_Lane you can't control their names, they can terminate and launch at any time
21:41 Ryan_Lane https://github.com/saltstack/salt/issues/11021
21:41 saltstackbot [#11021][OPEN] Support ec2 autoscaling groups in salt-cloud | Being able to manage individual instances is nice, but it would be great to be able to manage autoscaling groups as well....
21:41 Ryan_Lane still open
21:41 Ryan_Lane been open for 3 years
21:42 rav joined #salt
21:42 Ryan_Lane boto_asg was one of the first modules we added
21:42 major gitfs_roots fixed .. local environment error
21:42 Ryan_Lane it was easy to support because we don't need to support injecting salt
21:42 Ryan_Lane hell, maybe you inject ansible
21:42 Ryan_Lane the basic idea, though, is that we should treat orchestration separately from config management
21:43 Ryan_Lane salt, the cloud orchestrator, is a competitor to terraform
21:43 Ryan_Lane and that's different from salt the config management system
21:43 gtmanfred ok Ryan_Lane i think i understand what you want, and I want that too, i just want a few other things along side of it
21:43 SaucyElf joined #salt
21:44 gtmanfred Ryan_Lane: my end goal would be to be able to take all the boto modules out of the modules directory, drop them in the new directory, but still be able to use them in the same way
21:44 gtmanfred just to also make them available in salt-run
21:44 gtmanfred without changing any of the code in the modules
21:44 whytewolf that i agree with. I just see a nightmare of maintaince coming ahead. what happens if lyft stops supporting boto_* can saltstackinc take over.
21:44 Ryan_Lane @gtmanfred would the state api change for this?
21:44 gtmanfred no
21:45 Ryan_Lane for instance, would I still be able to use a state via boto_asg.present?
21:45 gtmanfred yes
21:45 Ryan_Lane and in the code, we'd be able to use __states__['boto_asg.present'] ?
21:45 gtmanfred yes
21:46 Ryan_Lane and we'd still be able to use __context__ in the execution modules?
21:46 mavhq joined #salt
21:46 gtmanfred yes
21:46 Ryan_Lane this sounds pretty confusiong
21:46 Ryan_Lane so we'd have two states and execution modules locations?
21:46 Ryan_Lane and we'd be monkey patching in the combo of these?
21:46 gtmanfred just for the cloud stuff.
21:47 gtmanfred and it wouldn't be monkey patching, we just add it as a new location for the states to load from
21:47 gtmanfred i just don't want to have to inject all of the execution modules when trying to load cloud driver stuff
21:47 Ryan_Lane this is somehow less work then making it possible for salt-cloud to access the modules?
21:47 gtmanfred once this was done, we would then work on getting salt-cloud to use the modules
21:47 Ryan_Lane so, here's the thing. we orchestrate a lot more than just cloud providers
21:47 gtmanfred when using salt-cloud, i don't want to load linux_lvm.present
21:48 Ryan_Lane we orchestrate github, pagerduty, thousandeyes, etc
21:49 Ryan_Lane ok, so from the perspective of overwriting these, if we add a custom state and execution module directory and those are named the same thing, it'll still continue working?
21:50 Ryan_Lane we keep the boto_* modules as backwards compat as possible so you can drop them into custom modules folders so you can use them in older versions of salt
21:50 Ryan_Lane I definitely don't want to lose that
21:50 gtmanfred yeah, it shouldn't change how the modules are used
21:50 Ryan_Lane cool
21:50 Ryan_Lane this all sounds reasonable
21:51 gtmanfred i just don't want to load ALL modules when running salt-cloud
21:51 gtmanfred that is my main complaint
21:51 Ryan_Lane you're essentially just shifting modules into directories to avoid overhead
21:51 gtmanfred yes
21:51 Ryan_Lane ????
21:51 gtmanfred cool
21:51 gtmanfred None of these changes will probably take place until flourine though
21:53 Ryan_Lane sounds good
21:54 whytewolf so, any plans to have some kind of ironic party when sodum is released?
21:55 whytewolf damn i sodium
21:57 gtmanfred ha
21:58 gtmanfred I also like splitting out the code into functions, because right now, it is just a nightmare of like 4k long files in salt-cloud
21:58 whytewolf s. my take away from this is, a. saltify should be split out of salt-cloud. into it's own thing that could be usful for people that want to put salt onto anything. removing the salting of instances.
21:59 whytewolf b. ) more modules for every cloud type system for general control
21:59 whytewolf c.) everything should be accessable from states/modules
22:00 Ryan_Lane my end-goal would be to have as much support as terraform
22:00 Ryan_Lane (aws already does)
22:01 whytewolf yes but boto_* != salt-cloud that is other modules.
22:01 whytewolf salt-cloud defintly should use those modules though
22:01 Ryan_Lane yeah, what I'm saying is that ideally salt-cloud would be a wrapper over the top of the cloud-specific modules
22:02 Ryan_Lane for instance, if you wanted to create a vm in 3 clouds, you could use the cloud module, but if you wanted to use all the features available for a vm in a cloud, you'd use the cloud-specific one
22:03 gtmanfred that is the goal
22:03 gtmanfred i want them both along side each other
22:03 gtmanfred which is something terraform cant do afaik
22:03 whytewolf yes, that was always the goal from the start from what i understand
22:03 gtmanfred it was, but it was designed before all the DBaaS stuff and Kube stuff started
22:04 edrocks joined #salt
22:04 Edgan Ryan_Lane: I support converting salt-cloud into a terraform like thing using your boto stuff. I don't touch salt-cloud, because it only does instances. One super key feature is a mapping of security group names to security group ids. I don't want to touch security group ids directly in definitions in any AWS resource.
22:04 Ryan_Lane Edgan: yep. that exactly :)
22:04 Edgan Ryan_Lane: Which is what I do in my customer python/boto script
22:05 Ryan_Lane and there's all kinds of fancy things we do in the modules that terraform requires chaining to do
22:05 gtmanfred Ryan_Lane: i played with terraform for the first time a couple weeks ago, and that was my biggest complaint
22:05 Ryan_Lane for instance, the dynamodb state module can automatically create datapipeline jobs to make backups of the tables
22:06 Ryan_Lane or the autoscale group state module can automatically create scaling policies, cloudwatch alarms, etc.
22:06 Ryan_Lane the elb module can manage route53 records for the elb
22:07 Edgan gtmanfred: The big issue I have with terraform is it's expectation that is it is the end all be all of how you touch AWS infrastructure, and in some cases it is written to destroy something that could just be tweaked. This is because it holds state of everything. Their(Hashicorp) answer to this problem is if you don't want state, as of 0.9, you can just delete the state file. Because the broke it into two pieces. One is state, and one is a cache of
22:07 Edgan api data.
22:07 gtmanfred yeah, that was the other thing I didn't like
22:07 gtmanfred importing stuff into terraform after it had been created was awful
22:08 Ryan_Lane Edgan: hm. I thought terraform could reference by name via chaining
22:08 Ryan_Lane where you take the output of a managed secgroup and use it as input for another resource
22:09 gtmanfred i tried that, it did not like it
22:09 Edgan Ryan_Lane: maybe it can reference by name. I have never dug that deep into it, because of fundamental design issues.
22:09 gtmanfred but i only tried once
22:09 Edgan Ryan_Lane: I was more talking about salt-cloud and naming
22:09 Ryan_Lane the statefulness is why I don't like terraform
22:09 Edgan Ryan_Lane: yes
22:09 Ryan_Lane and why the boto_* modules are written to be stateless
22:09 Ryan_Lane well, I wrote these before terraform existed
22:10 gtmanfred Edgan: did you see the email to salt-users about the salt-cloud working group?
22:10 gtmanfred or
22:10 gtmanfred Salt Cloud workign gruop
22:10 gtmanfred not going to fix it
22:10 Edgan gtmanfred: no, but now I know :)
22:10 gtmanfred it is in /topic
22:10 gtmanfred we are having our first meeting on June 1st
22:10 Edgan Ryan_Lane: and my new employer has been extending salt boto with you
22:10 Ryan_Lane yeah :)
22:11 major anyone know the status of salt-ssh in regards to windows targets?
22:11 Edgan major: Never tried it, but I am the biggest salt-ssh user
22:11 whytewolf does windows nativly support ssh? when did that happen
22:11 Edgan whytewolf: there is ubuntu embedded in Windows 10
22:11 major well, or a winrm interface .. but ..
22:11 gtmanfred not just ubuntu
22:11 major https://github.com/saltstack/salt/issues/39614
22:12 saltstackbot [#39614][OPEN] Trying to install salt-ssh on windows from powershell | Description of Question...
22:12 gtmanfred fedora and opensuse too
22:12 onlyanegg joined #salt
22:12 major well .. any agentless interface for windows ..
22:12 whytewolf yeah they have the virtuals but that isn't directly into windows
22:12 gtmanfred major: it isn't supported right now, there are some stuff in the way windows does os.fork (since it doesn't have it) that arent supported in the salt-ssh code
22:12 major oh
22:12 major yah .. os.fork ..
22:13 gtmanfred so it won't even work with the ubuntu/fedora/opensuse WSL
22:13 major Cygwin dealt with that as well
22:13 Edgan major: I am working on a new style of salt-ssh that might work better with Windows.
22:13 whytewolf salt-ad :P
22:13 whytewolf just kidding, not a thing
22:13 gtmanfred we have salt-winrm in enterprise for the next release
22:13 major when is the release date for that?
22:14 major TBD?
22:14 gtmanfred we don't have an RC out yet
22:14 Edgan major: I am replacing salt-call with salt-master/minion inside salt-ssh, but I just started.
22:14 gtmanfred but, the hope is the first week of july
22:14 whytewolf salt-winrm in enterprise? is that going to go opensource?
22:14 gtmanfred we will see
22:14 major kk .. just curious if it was even on the board
22:14 gtmanfred whytewolf: i don't think so.
22:15 whytewolf major, have a enterprise license?
22:15 major not yet .. waiting on quotes
22:15 Edgan major: Which should have near 100% compatibility, unlike salt-ssh with salt-call.
22:16 major we also sort of have no clear idea as to how many minions we would need to even put under the license .. our use case is sort of out there ;)
22:16 whytewolf also gtmanfred that sucks. don't like seeing major features like that being behind a paywall. the gui i can understand it isn't needed. but a agentless setup for windows ...
22:16 Edgan whytewolf: yeah, I agree, that has been one of the great things about salt
22:17 gtmanfred it may be open sourced one day, but it was paid for by a customer who wanted it written.
22:18 whytewolf okay, I'll go pout for a while.
22:18 whytewolf :P
22:18 gtmanfred also, i don't make that decision
22:18 gtmanfred if it was up to me, it would be opensourced, go get your company to pay us buttloads of money to opensource it :P
22:18 whytewolf [which really this doesn't effect me at all as i have 0 windows minions of any kind]
22:19 gtmanfred whytewolf: https://www.youtube.com/watch?v=MiJPsOI61qE
22:19 whytewolf lol
22:20 whytewolf https://www.youtube.com/watch?v=YG6DifUtPvs
22:20 gtmanfred but seriously, right now it is about adding value to enterprise
22:20 whytewolf eapi, and the gui don't add value?
22:21 whytewolf or just not enough to get customers
22:21 whytewolf ?
22:21 gtmanfred just not enough right now, it is ramping up, i just saw some larger deals come through
22:22 whytewolf oh i have a thing you can add to get customers. a reporting runner
22:22 whytewolf generate reports with a single command :P
22:22 gtmanfred that is in the gui
22:22 gtmanfred and in the eapi
22:23 whytewolf ... well fuck. now i want the eapi and gui
22:23 gtmanfred right! who wouldn't
22:24 whytewolf still wish there was like an enterprise light version [not a trial] for those of us that have very small setups at home
22:28 whytewolf oh i have a feature that can get you on the latest treand. machine learning. hottest trend out nowdays
22:29 gtmanfred ha
22:29 gtmanfred elastic just released a machine learning plugin xpack like 3 weeks ago
22:29 whytewolf yeah and google just announced machine learning in gce
22:30 whytewolf https://cloud.google.com/products/machine-learning/
22:30 whytewolf if salt had machine learning it could devise a way to fix deployment problems on the fly ;)
22:31 whytewolf and before i have time to utter another sentance we have skynet and all problems are taken care of
22:31 gtmanfred that isn't a bad idea, need to hire someone immediately in the field
22:34 walker joined #salt
22:34 gtmanfred aight, i gotta go do work, too much loitering in irc
22:35 whytewolf agreed. i gota go build skyne... elasticsearch
22:39 mavhq joined #salt
22:54 gtmanfred joined #salt
22:55 woodtablet joined #salt
22:57 debian112 joined #salt
23:04 debian112 joined #salt
23:15 SaucyElf_ joined #salt
23:16 autofsckk joined #salt
23:44 Trauma joined #salt
23:45 ahrs joined #salt
23:45 whiteinge joined #salt
23:56 nidr0x joined #salt

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