Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-02-02

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

All times shown according to UTC.

Time Nick Message
00:00 MTecknology heh
00:01 ssplatt joined #salt
00:05 Edgan Ryan_Lane: watch is good for services, I almost never use requires.
00:06 Ryan_Lane we use listen/listen_in even for services
00:06 Ryan_Lane "do all the state things, now restart all the services"
00:06 Ryan_Lane the only cases we use watch is when we need to immediately do an action between states
00:07 Ryan_Lane the end-goal being no re-ordering of states, so everything is fully sequential
00:07 Ryan_Lane a watch is an implicit require and if you have a few things doing a watch on the same thing it'll reorder all of them
00:07 Edgan Ryan_Lane: never had an issue in practice, but reading the documentation for listen, yeah, I should probably switch to listen
00:08 Ryan_Lane listen was a feature I requested ages ago :D
00:08 Edgan Ryan_Lane: I do believe in explicit order. I learned from Puppet why requires and auto dependency graphing is a broken model.
00:09 Ryan_Lane yep. that's also why we wanted sequential
00:09 Edgan Ryan_Lane: Do you use failhard: True?
00:09 Ryan_Lane we moved from puppet to salt
00:09 Ryan_Lane we do
00:09 Edgan Ryan_Lane: Same here :)
00:15 fgimian joined #salt
00:15 xbglowx joined #salt
00:19 MTecknology This is kinda fun. To make /dev/sda an encrypted volume for LVM to hold /boot and the rest of the system, you have to decrypt /boot before the boot process can continue. No worries because grub is pretty neat, but the first entry is more of a bios thing where you get whatever keyboard layout hardware defines. The second time, you can manipulate that. The end result, I have one password that needs
00:20 MTecknology to be entered twice at boot, but each time is using a different keyboard layout.
00:20 MTecknology also.. wrong channel to share that.. but maybe you guys will find that entertaining as well
00:24 abednarik joined #salt
00:25 Eugene Dvorak security?
00:25 smcquay joined #salt
00:32 skullone huh - im getting weird newlines when i iterate pillar data in a jinja template
00:32 Eugene http://jinja.pocoo.org/docs/2.9/templates/#whitespace-control
00:34 skullone oh odd
00:37 MTecknology which part?
00:37 skullone i thought it was my for loop doing it :\
00:39 spuder joined #salt
00:40 tracphil joined #salt
00:40 MTecknology it might be..
00:40 MTecknology depends on lotsa things...
00:41 skullone mmf
00:41 Klas joined #salt
00:41 MTecknology you haven't shown us what you're working with, what you're getting, or what you expect...
00:41 Eugene If you were previously unfamiliar with whitespace control in Jinja, then yes, it would "appear to be" the for loop. Its just Jinja.
00:41 Eugene Nothing salt-specific about it at all
00:43 Eugene I have to muck with the syntax every time, if it makes you feel any better.
00:43 skullone https://gist.github.com/brentrjones/31f2415d36c1da0ab628cefa32c1bed3
00:46 eThaD joined #salt
00:48 tracphil Ok Jinja Warriors, I have been away from SaltStack for about a year or so. I am trying to use defaults.yaml, map.jinja and pillar data in reclass. However, I am getting this error and can quite figure it out. https://gist.github.com/reavon/0d1e72abdf74b58f1238f5a97d80b39e
00:48 tracphil This is my defaults.yaml, map.jinja and pillar example https://gist.github.com/reavon/12dba03c33daaa986c3c2de981f233d3
00:48 tracphil any ideas?
00:55 whytewolf well. i think your first problem is you are passing salt_master in as a string not a variable. and that item in filter_by is supposed to be a dict.
00:57 whytewolf also your error memtions piller.get [a typo??] instead of pillar.get not sure where that came from
01:00 tracphil crap
01:00 tracphil thanks!!!
01:00 tracphil I think I looked at it so long I didn't even notice the typo and I specifically thought of that.
01:00 tracphil back to the drawing board!
01:02 nickabbey joined #salt
01:07 eThaD joined #salt
01:11 PatrolDoom joined #salt
01:18 swa_work joined #salt
01:29 aw110f joined #salt
01:31 Eugene It looks (to me) like installing certbot(and its dependencies) causes salt-minion to fail under CentOS 7. https://github.com/saltstack/salt/issues/39134
01:31 saltstackbot [#39134][OPEN] Installing certbot causes Salt-Minion to fail to start | Description of Issue/Question...
01:32 Eugene Which is a bit of a bummer, because my certs expire this weekend
01:33 pcn joined #salt
01:34 pcn Is there a way to ask salt to return the output of a test.ping with all of the results being in a json document, instead of --out=json returning individual documents per target?
01:35 pcn Oh, and as I ask I see --static
01:36 aw110f joined #salt
01:39 aw110f joined #salt
01:41 Derailed Hey everyone, are there things I need to be careful of if I'm going to use 'pkg.removed' to prune old kernels? (in a debian system)
01:42 whytewolf just don't remove your current kernel
01:42 modulistic joined #salt
01:43 Derailed I want to install the 4.9 and then remove the old one. is there an easy way to force the order of operations? How bad is it if I remove the kernel that's currently booted? Trouble is I can't reboot in the middle of a salt run (or *can* i?)
01:45 whytewolf oh it isn't bad about removeing the currently running kernel unless you havn't replaced it before you do reboot
01:48 whytewolf sometimes i miss the days of lilo
01:48 Derailed I'm guessing I can put a dependency in of some kind though
01:48 Derailed whytewolf: no. you don't :-P
01:48 whytewolf Derailed: you could use a require
01:49 eThaD joined #salt
01:49 whytewolf and actually yes i do. lilo was so fun to troubleshoot. :P my first linux from scratch was befor grub was a thought/.
01:50 spuder_ joined #salt
01:54 MTecknology I don't in any way miss lilo!
01:54 MTecknology I miss some things about grub1, though
02:10 eThaD joined #salt
02:12 prg3 joined #salt
02:15 catpigger joined #salt
02:24 swa_work joined #salt
02:27 juanito joined #salt
02:29 gableroux joined #salt
02:30 k_sze[work] joined #salt
02:30 NightMonkey joined #salt
02:32 swa_work joined #salt
02:38 evle joined #salt
02:39 mosen joined #salt
02:48 ilbot3 joined #salt
02:48 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.3.5, 2016.11.2 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ (please don't multiline paste into channel) <+> See also: #salt-devel, #salt-offtopic <+> Ask with patience as we are volunteers and may not have immediate answers
02:52 eThaD joined #salt
03:02 cacasmacas joined #salt
03:02 pcn Has anyone here used cmd.run in a custom runner?
03:03 edrocks joined #salt
03:03 pcn I'm trying to get some data out of zk, and when my runner code does this:
03:03 pcn minion_ids = client.cmd(minion, "cmd.run", '"zkCli.sh ls /brokers/ids"')
03:04 pcn instead of getting the output from the zkcli, it send me back an error message about cmd.run: 'Passed invalid arguments to cmd.run: run() takes at most 18 arguments (33 given)
03:08 mpanetta joined #salt
03:16 cryptolukas joined #salt
03:21 mavhq joined #salt
03:27 swa_work joined #salt
03:33 onlyanegg joined #salt
03:34 swa_work joined #salt
03:41 pcn Ah found it
03:41 pcn cmd.run in that context wants args in a list
03:55 jas02 joined #salt
03:56 mpanetta joined #salt
04:02 preludedrew joined #salt
04:02 stooj joined #salt
04:05 juanito_ joined #salt
04:18 onlyanegg joined #salt
04:20 cyborg-one joined #salt
04:23 SaucyElf joined #salt
04:46 cro joined #salt
04:50 swa_work joined #salt
04:54 armyriad joined #salt
04:58 eThaD joined #salt
05:14 SDS joined #salt
05:19 eThaD joined #salt
05:22 sagerdearia joined #salt
05:26 swa_work joined #salt
05:29 orianbsilva_ joined #salt
05:30 sagerdearia joined #salt
05:35 emartens joined #salt
05:37 sjorge joined #salt
05:38 swa_work joined #salt
05:43 sh123124213 joined #salt
05:55 swa_work joined #salt
05:57 mpanetta joined #salt
06:01 eThaD joined #salt
06:12 trent_ joined #salt
06:13 nayplum joined #salt
06:13 esc\ joined #salt
06:13 tawm04 joined #salt
06:13 _KaszpiR__ joined #salt
06:14 n1x0n joined #salt
06:14 Micromus joined #salt
06:14 Hipikat joined #salt
06:14 cswang joined #salt
06:14 lionel joined #salt
06:14 iggy joined #salt
06:14 filippos joined #salt
06:14 swa_work joined #salt
06:15 CrummyGummy joined #salt
06:15 Klas joined #salt
06:16 patrek joined #salt
06:16 haam3r joined #salt
06:16 stooj joined #salt
06:17 heaje joined #salt
06:18 Sketch joined #salt
06:18 smkelly joined #salt
06:18 Neighbour joined #salt
06:18 Morrolan joined #salt
06:18 NightMonkey joined #salt
06:18 dijit joined #salt
06:20 binocvlar joined #salt
06:21 cro joined #salt
06:21 v0rtex joined #salt
06:25 Horgix joined #salt
06:26 teclator joined #salt
06:28 twork_ joined #salt
06:34 stooj joined #salt
06:43 eThaD joined #salt
06:57 swa_work joined #salt
06:59 jas02_ joined #salt
07:00 jas02_ hello, how can I run postgresql master state on one minion and after successful end of this task run postgresql slave state on other minion? So I'll be sure of correct order of tasks?
07:01 onlyanegg joined #salt
07:06 swa_work joined #salt
07:25 eThaD joined #salt
07:25 bocaneri joined #salt
07:28 Neighbour jas02: use orchestration and salt.state with tgt: minion1 and the next salt.state with tgt: minion2 and a requirement of the 2nd task on the first
07:29 sh123124213 joined #salt
07:31 nidr0x joined #salt
07:36 ivanjaros joined #salt
07:40 MikaT joined #salt
07:46 eThaD joined #salt
07:46 whytewolf wtf, mysql wtf. why the hell do you work on the second attempt at a deploy when the first time fails...
07:48 Eugene Idempotency is a hell of a drug.
07:48 barmaley joined #salt
07:49 whytewolf the thing that bothers me most about it. is i run a remove script that should be returning the system to the exact state the system was in before i ran the deploy. but i must be missing something
07:50 whytewolf wait ... do i remove the repo?
07:54 whytewolf humm. okay i do remove the package that installs the repo
07:54 lasseknudsen joined #salt
07:54 whytewolf ...
07:54 whytewolf but there is cruft. damn it i normally am more careful then that
07:58 kshlm joined #salt
07:59 mikecmpbll joined #salt
08:03 kshlm joined #salt
08:04 darioleidi joined #salt
08:05 impi joined #salt
08:08 whytewolf I should so be in bed. but i think i found out my issue and it is stupid... somehow the file /etc/my.cnf exists before i install mysql with my states. and because i want to put a setting in that is not compatable with mysql on the first start [before plugins are installed] i have to run it twice, once to get the base system to at least install and go through first start. the second to put in my config setting.
08:08 whytewolf but i have an orchestration file that runs both of those.
08:08 whytewolf but because /etc/my.cnf exists BEFORE i run the orchestration it makes the incomptable change before first start
08:09 whytewolf oh well. easy fix.
08:12 eThaD joined #salt
08:14 tehsu any known issue with 2016.11.2 showing these errors?
08:14 tehsu [ERROR   ] Exception raised when processing __virtual__ function for gentoo_service. Module will not be loaded 'os'
08:14 tehsu [WARNING ] salt.loaded.int.module.gentoo_service.__virtual__() is wrongly returning `None`. It should either return `True`, `False` or a new name. If you're the developer of the module 'gentoo_service', please fix this.
08:18 whytewolf tehsu: what does salt-call grains.get os show for you?
08:21 whytewolf ??
08:23 teclator joined #salt
08:32 rdas joined #salt
08:42 swa_work joined #salt
08:45 pezus joined #salt
08:48 DanyC joined #salt
08:50 pezus hi guys
08:52 pezus has there been a failure in the official saltstack repositories? our wheezy-hosts say that salt now would install 2.6-1 of python-jinja2 but before it installed 2.7.3-1
08:52 pezus thus, we have a package installed not coming from a repository
08:52 nkuttler wheezy? are there still packages for that? security support has ended
08:53 pezus jep, wheezy is oldstable
08:53 whytewolf weezy is EOL in 2018
08:53 pezus and yes, there are still packages for that - from debian and saltstack
08:53 nkuttler security support ended on 2016-04-25
08:53 whytewolf and looking at the salt repo saltstack has jinja2 2.6
08:54 pezus yes, and it was 2.7.3 before
08:55 babilen 2.6 is the version in wheezy .. there really is no need to package those in the saltstacak repos
08:55 whytewolf eh, you know the saltrepos likes to make sure everything is in their repo
08:55 whytewolf even if the same version
08:56 pezus yes, apt-cache policy *now* shows that this package (and others) now are the same version as the official debian repository
08:56 pezus but before it delivered the version mentioned above, thus leaving us now with packages marked as not installed from a repository
08:56 tehsu whytewolf its cent
08:57 babilen whytewolf: They don't package Python or glibc or ...
08:57 whytewolf I'm not sure it came from saltstack pezus looking at the older repo [2015.8] thats is also 2.6 and has been for sometime
08:57 babilen Let's look into salt-pack
08:57 stooj joined #salt
08:57 whytewolf I compleatly forgot about salt-pack
08:57 babilen pezus: Mind searching in /var/log/apt/history.log* ?
08:58 whytewolf actually pezus is right
08:58 whytewolf pkg.python-jinja2.2_7_3.debian8
08:58 whytewolf https://github.com/saltstack/salt-pack/blob/develop/file_roots/versions/2016_11_1/debian_pkg.sls
08:59 pezus i am quite sure it came from salt. we only have the salt repository
08:59 babilen 1.7G git repo :(
08:59 whytewolf interesting
08:59 whytewolf one second
08:59 pezus Upgrade: python-msgpack:amd64 (0.3.0-1~bpo70+2, 0.4.2-1), bsdmainutils:amd64 (9.0.3, 9.0.6), salt-common:amd64 (2016.3.4+ds-1, 2016.11.0+ds-1), salt-minion:amd64 (2016.3.4+ds-1, 2016.11.0+ds-1), python-yaml:amd64 (3.10-4+deb7u1, 3.11-2), python-jinja2:amd64 (2.6-1, 2.7.3-1)
09:00 babilen https://github.com/saltstack/salt-pack/blob/develop/file_roots/versions/2016_11_1/debian_pkg.sls#L48 looks a bit premature
09:00 whytewolf pkg.python-jinja2.2_6.debian7
09:00 whytewolf debian7 should have been 2.6
09:00 whytewolf debian8 was 2.7
09:00 babilen And https://github.com/saltstack/salt-pack/blob/develop/file_roots/versions/2016_11_1/debian_pkg.sls#L63 has the expected version
09:00 pezus well, apparently someone changed the repository lately
09:01 babilen (no idea why they include that)
09:01 whytewolf pezus: the repo is built using salt-pack
09:01 whytewolf thats why we are looking at it's github
09:01 onlyanegg joined #salt
09:02 whytewolf the salt-pack for 2016.11.1 was last changed 2 months ago
09:03 whytewolf unless you somehow pointed at the debian8 repo you should not have gotten 2.7
09:03 pezus from my point of view i can only say that we didn't have any problems with the higher version but at least since yesterday our monitoring is saying we have packages not installed from a repo
09:04 ChrisCologne joined #salt
09:04 ChrisCologne Hi there,
09:05 babilen pezus: When was that upgrade?
09:05 babilen And saltstack should really use correct versioning for backports
09:06 ChrisCologne I did create an own windows package and placed it in /srv/salt/win/repo-ng. by executing  salt '*' state.apply I get Error:
09:06 ChrisCologne File "c:\salt\bin\lib\site-packages\salt\ext\six.py", line 583, in iteritems                   return iter(d.iteritems(**kw))               AttributeError: 'bool' object has no attribute 'iteritems'
09:07 pezus babilen: Start-Date: 2016-12-01  07:44:59
09:07 whytewolf also just noticed you upgraded to 2016.11.0 not to .1
09:07 whytewolf I was looking at .1
09:08 mikecmpbll joined #salt
09:08 edrocks joined #salt
09:08 ChrisCologne sry here is it more confortable: https://gist.github.com/anonymous/7f2cefe0a70ce1b1f044dac76e534aa4
09:08 babilen whytewolf: Doesn't that endif strike you as a bit premature?
09:08 Rumbles joined #salt
09:09 babilen Ah, no
09:09 whytewolf babilen: no, that is the switch from deb8 to deb7
09:09 samodid joined #salt
09:09 babilen whytewolf: Yeah, noticed it the moment I mentioned it :)
09:10 tehsu sorry, figured it out, cause was sse
09:12 pezus these are the all the packages that now have a lower version coming from salt repo: bsdmainutils (9.0.6) libzmq3 (4.0.5+dfsg-3) python-jinja2 (2.7.3-1) python-msgpack (0.4.2-1) python-yaml (3.11-2)
09:13 felskrone joined #salt
09:15 whytewolf pezus: every single one of those is debien 8 versions.
09:15 babilen Maybe you had the jessie repos enabled?
09:16 pezus no, we didn't change the repository line
09:16 babilen Would be obvious if they used backports versioning (bpo8 / bpo70)
09:17 pezus apparently, the repo was updated 2017-01-26 so potentially that was when the update job for apt changed the policy on our local systems
09:17 whytewolf unless there was a logic error in salt-pack when they deployed the server for 2016.11.0 which would have caused a lot of panic if they did. i don't see how you ended up with deb8 versions. when reading the code they have never changed the deb7 to those versions
09:18 felskrone joined #salt
09:19 whytewolf huh
09:20 pezus look, we manage our deb-lines via salt. the system is set up since feb last year, always using the wheezy repository from saltstack. and in december, apparently the saltstack repo was responsible for an upgrade of above mentioned packages
09:20 pezus i don't say you are wrong
09:20 babilen The line from history.log speaks volumes
09:21 whytewolf pezus: I'm not trying to argue with you. I was pointing out what the code was saying. however there was another resource and it actualy shows that you are right
09:21 whytewolf https://repo.saltstack.com/apt/debian/7/amd64/archive/2016.11.0/
09:21 whytewolf there must have been a logic error in salt-pack
09:21 whytewolf adn you were just the first to pick it up
09:22 whytewolf it looks like what happened is saltpack built ALL of the packages, not just the ones for 7
09:22 babilen Only changed with .2
09:27 whytewolf humm. no issue listed for it. wonder if they fixed it with out knowing they did
09:27 pezus any chance of getting the old package versions back? ;) it'd be a pita to manually downgrade each package, not to mention that there might be implications by doing so
09:28 Mattch joined #salt
09:28 whytewolf you might need to file a bug report with https://github.com/saltstack/salt-pack
09:29 impi joined #salt
09:29 whytewolf i guess you could hedge your bets. and have the latest repo and the old 2016.11.1 repo. that way you get the latest salt and the latest packages
09:30 whytewolf [as a work around]
09:30 s_kunk joined #salt
09:34 dijit Jinja variable 'dict object' has no attribute 'P'
09:34 dijit when doing pillar.items?
09:34 dijit that's weird.
09:34 whytewolf that sounds like you have a pillar that isn't rendering correctly
09:37 Cadmus joined #salt
09:43 pezus thanks for helping and investigating!
09:47 lasseknudsen2 joined #salt
09:54 armyriad joined #salt
09:55 dijit whytewolf: that's what I thought, but we don't have any references to "P" also, pillar not rendering on pillar.items? that's weird.
09:59 mpanetta joined #salt
09:59 AndreasLutro maybe you're doing pillar[myvar] somewhere where myvar == 'P'
10:03 Lionel_Debroux joined #salt
10:14 dijit nej
10:14 dijit the thing is, it's just one machine, when there are others with the exact same pillar/states which run fine.
10:27 CrummyGummy joined #salt
10:31 amcorreia joined #salt
10:32 babilen pezus: You'd have to downgrade manually - there really isn't a proper downgrade mechanism in place
10:35 babilen What a unfortunate thing to do
10:38 pezus babilen: well, yes, it is. at least we know now what the problem is. i am wondering if others are affected (likely) and if they are aware of the problem (at least should be)
10:40 babilen I am quite sure that others are affected and there really is not way to solve this unless you package 2.6 with a 2.7 version
10:57 jaemin joined #salt
10:57 jaemin hi all
10:58 jaemin i set gitfs to salt-master
10:58 jaemin and... problem
10:58 jaemin "[ERROR] Got insufficient arguments for grains match from master"
10:58 jaemin what is problem?
11:02 onlyanegg joined #salt
11:06 babilen Do you guys have any suggestions for interesting conferences this year?
11:07 babilen (Europe (maybe Asia) would be preferred)
11:13 riftman joined #salt
11:16 sfxandy joined #salt
11:23 jaemin left #salt
11:30 eThaD joined #salt
11:31 ravenx joined #salt
11:31 ravenx is it possible to use the salt-api with the publisher_acl
11:31 ravenx instead of external auth + pam?
11:32 byteriot left #salt
11:32 byteriot joined #salt
11:36 sjorge joined #salt
11:40 cryptolukas joined #salt
11:42 inad922 joined #salt
11:47 evle joined #salt
11:57 lasseknudsen joined #salt
11:59 eThaD joined #salt
12:02 eThaD joined #salt
12:10 gladia2r joined #salt
12:10 edrocks joined #salt
12:17 abednarik joined #salt
12:24 amcorreia joined #salt
12:37 kettlewell joined #salt
12:45 Tanta joined #salt
12:51 lasseknudsen2 joined #salt
12:54 _Cyclone_ joined #salt
13:01 viq babilen: FOSDEM and Configuration Management Camp this weekend and mon-tue ;)
13:02 kettlewell left #salt
13:03 onlyanegg joined #salt
13:03 jhauser_ joined #salt
13:03 babilen Are you going?
13:04 numkem joined #salt
13:16 Awesomecase joined #salt
13:18 viq Not this year, unfortunately
13:19 viq Oh, yeah, there were some noises that monitorama.eu might happen this year
13:20 viq But then there were also some noises that it may not, because of turbulence caused by the brexit mess (and possibly now trump)
13:22 gableroux joined #salt
13:24 scoates joined #salt
13:25 felskrone joined #salt
13:36 ALLmightySPIFF joined #salt
13:36 inad922 joined #salt
13:38 edrocks joined #salt
13:40 ravenx coudl someone help me with translating a CLI to a json so I can use it via the salt-api:
13:41 ravenx salt --pillar 'tasks_app_role:dev' state.apply
13:41 ravenx i'm kinda loss here as it doesn't have a "tgt"
13:41 ravenx normally, i give salt some servers like 'serverone'
13:41 ravenx but here it is just a --pillar command.  i do have the 'fun=' part though.
13:41 babilen expr_form
13:41 ravenx expr_form?
13:43 fracklen joined #salt
13:44 ravenx i did find the docs, but i suppose an example for my case would be highly appreciated
13:46 amagawdd joined #salt
13:54 thebinary joined #salt
13:55 mswart joined #salt
14:00 mpanetta joined #salt
14:06 ravenx so far i have gotten this:
14:06 ravenx https://paste.debian.net/912479/
14:06 ravenx but ot no avail
14:06 brousch__ joined #salt
14:07 ssplatt joined #salt
14:12 beardedeagle joined #salt
14:24 Sketch joined #salt
14:26 beardedeagle joined #salt
14:34 SaucyElf joined #salt
14:36 spuder joined #salt
14:49 onlyanegg joined #salt
15:01 _JZ_ joined #salt
15:02 nickabbey joined #salt
15:04 toanju joined #salt
15:07 tapoxi joined #salt
15:08 racooper joined #salt
15:08 emartens joined #salt
15:13 HeresJohny joined #salt
15:15 lompik joined #salt
15:16 SaucyElf_ joined #salt
15:17 jas02_ joined #salt
15:20 k4kvm joined #salt
15:22 Miouge joined #salt
15:25 djgerm joined #salt
15:25 mpanetta joined #salt
15:28 mpanetta joined #salt
15:31 beardedeagle joined #salt
15:32 keltim joined #salt
15:39 implicitnewt joined #salt
15:39 djgerm joined #salt
15:42 implicitnewt Has anyone had success using salt-cloud with AWS govcloud?  Any commands I attempt come back with SSLError: [Errno 13] Permission denied.  I'm not sure if it's my configuration or if salt-cloud accesses things not available on govcloud
15:46 SaucyElf joined #salt
15:48 austin_ joined #salt
15:50 tapoxi I'm using it on normal AWS (not govcloud) and I've never seen SSL Error
15:51 tapoxi though that seems odd for an API credential error, it sounds like a problem with ssl negotiation
15:52 tapoxi what do you get from debug (-d) implicitnewt ?
15:53 implicitnewt that's what is throwing me off on this.  I can wget and access the endpoint I configured for govcloud so it's communicating
15:53 implicitnewt here is the output from salt-cloud --list-images
15:53 implicitnewt [DEBUG   ] Configuration file path: /etc/salt/cloud [WARNING ] Insecure logging configuration detected! Sensitive data may be logged. [INFO    ] salt-cloud starting [DEBUG   ] Could not LazyLoad parallels.avail_sizes [DEBUG   ] LazyLoaded parallels.avail_locations [DEBUG   ] LazyLoaded proxmox.avail_sizes [DEBUG   ] Could not LazyLoad saltify.destroy [DEBUG   ] Could not LazyLoad saltify.avail_sizes [DEBUG   ] Could not LazyLoad
15:54 implicitnewt [DEBUG   ] LazyLoaded rackspace.reboot [DEBUG   ] LazyLoaded openstack.list_locations [DEBUG   ] LazyLoaded rackspace.list_locations [DEBUG   ] Using AWS endpoint: ec2.us-gov-west-1.amazonaws.com [DEBUG   ] AWS Request: https://ec2.us-gov-west-1.amazonaws.com/?Action=DescribeImages&amp;Owner=amazon&amp;Version=2014-10-01 [ERROR   ] Failed to get the output of 'ec2.avail_images()': [Errno 13] Permission denied Traceback (most recent call
15:54 tapoxi implicitnewt put on pastebin
15:54 jas02_ joined #salt
15:55 implicitnewt http://pastebin.com/D4vtEuN0
15:57 gableroux joined #salt
16:02 tapoxi implicitnewt: try opening a python shell and stepping through it manually
16:02 tapoxi import requests and then call that endpoint and print out the result of the requests object
16:05 eriko_ joined #salt
16:06 spuder joined #salt
16:06 implicitnewt that suddenly got serious :).  I will look into giving that a shot... my python skills are enough to debug a few things here and there.
16:11 sh123124213 joined #salt
16:16 swa_work joined #salt
16:25 debian112 joined #salt
16:25 onlyanegg joined #salt
16:25 sarcasticadmin joined #salt
16:29 swills_ joined #salt
16:31 Brew joined #salt
16:31 hhhhy joined #salt
16:32 netcho joined #salt
16:33 tapoxi implicitnewt: not as bad as it sounds! the main page of their website basically has what you need to do http://docs.python-requests.org/en/master/
16:34 inad922 joined #salt
16:34 tapoxi foo=requests.get(uri)
16:35 tapoxi then just foo to get the output
16:37 xMopxShell joined #salt
16:42 mikecmpbll joined #salt
16:43 Brew1 joined #salt
16:46 ivanjaros joined #salt
16:49 gableroux joined #salt
16:53 DanyC joined #salt
16:54 sh123124213 joined #salt
16:58 nickabbey joined #salt
16:59 DanyC joined #salt
17:04 woodtablet joined #salt
17:04 hoonetorg joined #salt
17:04 art5005 joined #salt
17:05 art5005 Hey all.. Is there a way to add a 'require' that points to a service running on a different minion that still works when targeting specific minions?
17:05 aw110f joined #salt
17:05 art5005 Like, I have 'consumer1' and 'service1' minions.. something on 'consumer1' requires a service on 'service1' to be running.
17:06 art5005 But I still want to be able to do:  salt 'consumer1' state.apply
17:06 sp0097 joined #salt
17:09 jas02_ joined #salt
17:12 Brew joined #salt
17:12 swa_work joined #salt
17:17 beardedeagle joined #salt
17:17 sh123124213 joined #salt
17:19 cacasmacas joined #salt
17:20 daxroc Do mine.get queries consume a worker_thread ?
17:22 anotherzero joined #salt
17:26 eThaD joined #salt
17:26 tapoxi art5005: https://docs.saltstack.com/en/latest/topics/orchestrate/orchestrate_runner.html#orchestrate-runner
17:27 tapoxi art5005: orchestrate runner is higher level than running state.apply and lets sets of services depend on other sets of services
17:27 art5005 ahh.. perfect.. thank you!
17:27 whytewolf art5005: there is also reactors.
17:35 implicitnewt tapoxi: thanks for your help.  It boiled down to a system issue, the salt user was unable to read the ca-bundle on my server
17:36 tapoxi no problem!
17:38 toastedpenguin joined #salt
17:40 hoonetorg joined #salt
17:43 swa_work joined #salt
17:45 yuhll joined #salt
17:46 aboe joined #salt
17:46 aboe2 joined #salt
17:48 pepoluan joined #salt
17:48 aboe joined #salt
17:50 swa_work joined #salt
17:50 nickabbey joined #salt
17:57 fracklen joined #salt
17:58 hoonetorg joined #salt
18:01 sjorge joined #salt
18:03 swa_work joined #salt
18:04 SaucyElf joined #salt
18:08 Deliant joined #salt
18:19 edrocks joined #salt
18:22 cyteen joined #salt
18:23 DanyC joined #salt
18:23 swa_work joined #salt
18:24 Edgan joined #salt
18:25 jken joined #salt
18:25 jken How can I go about changing the root passwords on my salt minions all at once?
18:28 aw110f joined #salt
18:30 sc250024 joined #salt
18:31 sc250024 Has anyone successfully tested getting IPv6 to work in AWS with Salt Cloud?
18:31 sc250024 With an IPv6 enabled subnet ?
18:31 PatrolDoom joined #salt
18:37 Trauma joined #salt
18:38 nickabbey joined #salt
18:43 DanyC joined #salt
18:43 gableroux joined #salt
18:49 Rumbles joined #salt
18:49 fleaz joined #salt
18:54 s_kunk joined #salt
18:55 ssplatt joined #salt
18:57 swills__ joined #salt
19:01 nickabbey joined #salt
19:04 ssplatt joined #salt
19:11 ssplatt joined #salt
19:31 Miouge joined #salt
19:33 nidr0x joined #salt
19:34 djgerm joined #salt
19:34 djgerm Is there a way to set the reactor configuration to default to a different branch, other than base?
19:38 beardo joined #salt
19:39 DanyC joined #salt
19:52 djgerm Or rather, when I append ?saltenv=newbranch to reactor.conf stuff, it seems that I can no longer specify other environments
19:52 djgerm like with saltenv= on th e command line
19:53 sc250024 djgerm Do you have your current config?
19:53 sc250024 I can take a peak
19:54 djgerm sc250024: http://paste.debian.net/912554/
20:00 jas02_ joined #salt
20:00 ChubYann joined #salt
20:02 nickabbey joined #salt
20:03 toanju joined #salt
20:12 sc250024 djgerm I know with 'file_roots' and 'pillar_roots' you define the environment as a YAML key, and then define you environment specific values underneath
20:12 sc250024 Maybe try...
20:13 sc250024 https://gist.github.com/sc250024/e4fe51576d229091b1a1b2320e17d7b2
20:19 Rumbles joined #salt
20:23 Praematura joined #salt
20:26 eThaD joined #salt
20:30 cb joined #salt
20:31 DanyC joined #salt
20:34 nickabbey joined #salt
20:43 gableroux joined #salt
20:43 swa_work joined #salt
20:46 djgerm for gitsfs, do you know if pygit2 or gitpython is more recommended?
20:48 whytewolf do you need auth?
20:49 djgerm yes
20:49 whytewolf the pygit2
20:49 djgerm sweet!
20:56 anotherzero joined #salt
21:08 abednarik joined #salt
21:12 jas02_ joined #salt
21:18 SaucyElf joined #salt
21:38 anotherzero joined #salt
21:43 djgerm I am getting a bizarre error saying Unable to cache file 'salt://reactor/react_start.sls' from saltenv 'Production' - but that file isn't there anymore (it was removed from the gitfs backend)…. I don't understand it.
21:44 abednarik joined #salt
21:44 robinsmidsrod joined #salt
21:49 Rumbles joined #salt
21:52 cscf Is there a (good) way to get salt-cloud to bootstrap using apt rather than the bootstrap download?
21:53 cscf Or even do nothing?  We have an lxc template that comes with salt-minion
21:54 cscf Or does it do that automatically?
21:55 fracklen joined #salt
21:58 ssplatt you could write your own bootstrap script
21:58 ssplatt or make your own image that already has salt installed
21:59 carl_ joined #salt
22:02 nZac joined #salt
22:07 cwu joined #salt
22:07 cwu root@cwu-client:/home/cwu# tail -n 3 /etc/salt/minion beacons:   inotify:     /home/cwu/aaa root@cwu-client:/home/cwu# salt-minion --version salt-minion 2016.11.0-670-g79b6fa5 (Carbon)
22:08 cwu TypeError: argument of type 'NoneType' is not iterable [CRITICAL] The beacon errored:  Traceback (most recent call last):   File "/usr/lib/python2.7/dist-packages/salt/minion.py", line 2219, in handle_beacons     beacons = self.process_beacons(self.functions)   File "/usr/lib/python2.7/dist-packages/salt/minion.py", line 411, in process_beacons     return self.beacons.process(b_conf, self.opts['grains'])  # pylint: disable=no-member   Fi
22:08 cwu My just add three lines into minion config
22:09 cwu Then I get this error
22:12 druonysus_ joined #salt
22:12 abednarik joined #salt
22:17 druonysus_ left #salt
22:17 druonysus_ joined #salt
22:23 druonysus_ left #salt
22:23 druonysus_ joined #salt
22:25 druonysus_ left #salt
22:32 fracklen joined #salt
22:32 whytewolf cwu: can you please post that to a gist or pastebin site so that we can see the actual formatting on it
22:35 druonysus_ joined #salt
22:37 druonysus_ left #salt
22:37 debian112 joined #salt
22:37 druonysus_ joined #salt
22:37 aboe joined #salt
22:40 gableroux joined #salt
22:43 druonysus_ joined #salt
22:45 whytewolf cwu: from the documentation for beacons that should be /home/cwu/aaa: {}
22:46 t_O joined #salt
22:47 druonysus__ joined #salt
22:47 druonysus__ left #salt
22:48 druonysus__ joined #salt
22:48 t_O Hi, I'm having an issue here, not sure why the named state won't update the managed file.
22:48 t_O https://gist.github.com/towens/4d0abd6de75d9c47666c6b14c062dd19
22:49 t_O The state with the path to the script works as expected.
22:49 whytewolf is there any errors?
22:49 t_O Assuming it's something obvious.
22:49 whytewolf also runn the state with salt-call and use -l debug
22:50 t_O no errors, just the jinja var is empty
22:51 t_O Oh hey it's you, figured out the optional pip thing
22:51 t_O -name 'airflow[hive]'
22:51 t_O is the .sls
22:52 whytewolf well one thing. when useing mode. if it starts with a 0 wrap that in single quotes or yaml will read an interger and evaluate a octal
22:53 whytewolf t_O: ahhh kewl. must have been the [] throwing off yaml then
22:54 t_O fully was the [] :)
22:55 whytewolf btw. other then the mode thing i see no reason why one would work and the other wouldn't
22:56 t_O sweet, good to know. I'll poke at the mode.
22:58 whytewolf also, you have stanzas for user and group right?
22:58 whytewolf that create them?
22:58 whytewolf or at least make sure they are there
23:00 t_O I do. awesome idea with the debug. Weird thing is the requisites are failing for the user even with sudo cat /etc/passwd | grep airflow
23:01 t_O They are absolutely being created in a upstream sls
23:02 whytewolf requisistes are compleatly about states. there has to be a state during the current run the matches the information
23:02 t_O The current run being the .sls that is being evaluated?
23:02 whytewolf or highstate
23:02 t_O The entire run
23:03 t_O got it
23:03 whytewolf yeah they check if the state is there and compleated correctly.
23:06 t_O updated the gist, took off all the requirements and instead of running the hightstate, just running the single state
23:06 t_O https://gist.github.com/towens/4d0abd6de75d9c47666c6b14c062dd19
23:06 t_O ala... sudo salt-call --local state.apply dag_sync -l debug
23:07 t_O looks good now.
23:08 fracklen joined #salt
23:08 debian112 joined #salt
23:11 t_O Thanks for the yaml mode tip, didn't know it was going to evaluated as an int
23:12 bowhunter joined #salt
23:12 whytewolf yeah, processing on numbers that starts with 0 tend to really mess things up in most langs
23:14 jas02_ joined #salt
23:17 t_O Yeah I didn't think about that in terms or YAML parsing it.
23:19 t_O I think what happened here is that when I started to find the error I stopped running the highstate and started applying the individual state. Which thankfully and logically you pointed out that the context for the require is missing at that point.
23:24 fgimian joined #salt
23:26 jor_ joined #salt
23:28 Heartsbane joined #salt
23:28 Heartsbane joined #salt
23:29 _beardedeagle joined #salt
23:38 abednarik joined #salt
23:48 ipmb joined #salt
23:51 cyborg-one joined #salt
23:51 DammitJim joined #salt
23:54 mikecmpbll joined #salt
23:58 mikecmpbll joined #salt

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