Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-02-21

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

All times shown according to UTC.

Time Nick Message
00:00 jcockhren anyone here use lita bot?
00:00 joehoyle Ryan_Lane: ping :)
00:01 Ryan_Lane joehoyle: sup?
00:02 joehoyle Ryan_Lane: your name was mentioned to me, as I heard you run a lot of salt masterless, and I was wanting to compare notes on using custom modules masterless as I can't seem to get mine to work
00:02 Ryan_Lane sure. what's up?
00:02 Ryan_Lane we actually have a lot of custom modules
00:02 * Ryan_Lane is writing a custom external pillar right now
00:02 jcockhren go Ryan_Lane go
00:02 joehoyle cool - so, I'm using s3fs as my file server backend
00:02 joehoyle and I can't seem to get my modules / grains etc piccked up
00:03 Ryan_Lane heh. well, I don't actually know there :)
00:03 joehoyle ah :)
00:03 joehoyle are you using local disk backend?
00:03 Ryan_Lane yeah. we deploy everything to our nodes
00:03 Ryan_Lane using a custom artifact deployer
00:03 joehoyle ah ok
00:04 Ryan_Lane what's your fileserver look like?
00:04 joehoyle and yoru modules are just in the environment root, ee.g. base/_modules ?
00:04 Ryan_Lane I know that was added really recently to masterless
00:04 joehoyle yeah exactly
00:04 Ryan_Lane we have a really custom layout
00:04 Ryan_Lane we embed our salt config into our service repos
00:05 bluenemo_ joined #salt
00:05 Ryan_Lane and have a second "base" repo
00:05 Ryan_Lane we deploy both of them, then we specify our module paths explicitly
00:05 joehoyle ah, much more complex than me i think
00:05 joehoyle so, on running a saltutil.sync_grains I get this: https://gist.github.com/joehoyle/36819e86ce77f7c2ebea
00:05 joehoyle which seems to indicate it's found the custom grain
00:05 joehoyle but, I don't know how to debug further to see why those grains are not showing up on a grains.items call
00:06 Ryan_Lane ah, interesting. I don't use sync_*
00:06 Ryan_Lane (because I specify my paths)
00:06 joehoyle presumably these are fetched on a highstate too
00:06 Ryan_Lane you probab;y need that, though
00:06 Ryan_Lane indeed, they should be fetched on highstate
00:06 Ryan_Lane oh...
00:06 joehoyle I thin I need to improve my salt debugging skills in that case then!
00:06 Ryan_Lane are you /sure/ it's not actually using the grain?
00:06 Ryan_Lane it's possible that you're missing some dependency for the grain
00:06 joehoyle well, the same grain is working on a mastered setup I have
00:07 joehoyle ah
00:07 joehoyle would that be showin ghte a -l debug for highstte maybe?
00:07 Ryan_Lane maybe
00:07 Ryan_Lane it's possible that module doesn't have any debugging at all
00:07 Ryan_Lane if not, add some
00:07 joehoyle was hoping any errors would be shown here with sync_*
00:07 Ryan_Lane it should show up there too
00:07 Ryan_Lane but if the module has no debug statements....
00:07 joehoyle ok - looks like I might need to do some python hacking!
00:07 Ryan_Lane you probably want one in the __virtual__ function
00:08 joehoyle that is called when the grain is included?
00:08 jasonrm joined #salt
00:08 Ryan_Lane yeah. if it doesn't return true (or a string) it'll not load
00:09 Ryan_Lane joehoyle: seems that grain doesn't have a virtual function
00:09 Ryan_Lane it's this one, right? https://github.com/saltstack/salt-contrib/blob/master/grains/ec2_info.py
00:09 joehoyle hmm, I wonder why it would be working on my mastered setup then
00:09 perfectsine joined #salt
00:09 joehoyle ya
00:10 Ryan_Lane it probably isn't being loaded...
00:10 joehoyle ok cool, I'm goign to dig into that - that's for help help, much appreciated!
00:10 Ryan_Lane joehoyle: run salt-call --local grains.get ec2_account-id
00:11 Ryan_Lane with log-level debug
00:11 TTimo joined #salt
00:11 joehoyle Ryan_Lane: https://gist.github.com/joehoyle/361085ddf8405dfd0b6a
00:12 Ryan_Lane hm. interesting.
00:12 joehoyle yeah, seems it's a bit tight on the logging!
00:13 Ryan_Lane joehoyle: I'd likely open a bug. this seems like a bug to me
00:13 joehoyle ok cool
00:13 Ryan_Lane isn't terribly surprising. this is a really new feature for masterless
00:13 joehoyle yeah - I seem to be fairly alone in this setup :P
00:13 Ryan_Lane there aren't a lot of tests for masterless right now, either
00:16 Ryan_Lane joehoyle: I was strongly considering the route you're going when I started, but the fs module didn't work in masterless at the time
00:16 joehoyle ah yeah - I have been waiting like 2 months for it!
00:16 joehoyle in the meantime I did mastered with it's self, kindathing
00:18 Ryan_Lane joehoyle: how are you dealing with the S3 caching?
00:19 joehoyle Ryan_Lane: S3 does caching by default?
00:19 Ryan_Lane doesn't the fs module do caching?
00:19 Ryan_Lane or does it check the metadata every time?
00:19 joehoyle yeah
00:19 joehoyle it's slow if the bukcet is in a different region
00:20 joehoyle pretty fast otherwise
00:20 Ryan_Lane ah. cool
00:27 loggyer joined #salt
00:27 loggyer guys his can i create a array of hashes for a config file in jina
00:28 loggyer cannot find a way to achieve this
00:30 iggy grains don't have a virtual function
00:31 Ryan_Lane iggy: you sure?
00:31 Ryan_Lane I don't see why they wouldn't. some grains require third party libs
00:31 iggy none of the ones I've ever written have one
00:31 drawsmcgraw left #salt
00:32 Ryan_Lane they definitely support it
00:32 Ryan_Lane some of the core modules have virtual functions
00:32 iggy and none of the ones in salt-contrib have one
00:32 Ryan_Lane see the junos grain in core
00:33 Ryan_Lane or the rest_sample
00:34 joehoyle so, I synced down my files local, and switch away from s3fs and then my modules et work - so I'm guessing it's a bug in s3fs
00:34 joehoyle or external backends anyway
00:34 iggy yeah... I wonder if they actually do anything though (or if someone just wrote them in there because they are used to writing execution modules)
00:35 Ryan_Lane iggy: I'd be very surprised if they didn't work
00:35 Ryan_Lane since every other type of module supports them
00:35 Ryan_Lane and the basic idea is to protect salt from throwing stacktraces when it can't load modules
00:36 iggy yeah, fair enough
00:36 iggy and both of those look like proxy-minion grains too (which explains why you wouldn't want them loading normally ;)
00:39 bhosmer_ joined #salt
00:45 Aikar joined #salt
00:46 Aikar can anyone point me to an example of cloning with git.latest and chown?
00:54 baweaver joined #salt
01:07 otter768 joined #salt
01:21 pdayton joined #salt
01:26 TTimo joined #salt
01:26 Aikar ok i have some chowns working now - but next question - how can i set multiple git config entries in 1 dec
01:32 tristianc joined #salt
01:42 che-arne joined #salt
01:45 mikaelhm joined #salt
01:52 zugzwang joined #salt
01:53 zugzwang how do I read string values from pillar? if I read a 'var: on' with {{ pillar['var'] }} it returns True!
01:53 zugzwang I want the literal value from the pillar, not a conversion to True/False
01:59 zugzwang ok I just discovered I have to quote true/false,on,off,yes,no  when used in pillar files
02:03 baweaver joined #salt
02:08 JlRd joined #salt
02:08 donmichelangelo joined #salt
02:09 Morbus joined #salt
02:15 bash1245_ joined #salt
02:18 mikaelhm joined #salt
02:30 jhauser_ joined #salt
02:30 Furao joined #salt
02:30 mailo joined #salt
02:32 mailo joined #salt
02:41 pdayton joined #salt
02:45 subsignal joined #salt
02:47 joehoyle Ryan_Lane: 5 hours later! https://github.com/saltstack/salt/pull/20885
02:54 falican joined #salt
03:05 aron_kexp joined #salt
03:05 rudi_s Hi. Can I access the current grains when I generate a pillar? Neither salt, __salt__ nor __grains__ seems to be defined in the jinja template in pillar/foo.sls
03:07 otter768 joined #salt
03:08 erikols joined #salt
03:08 forrest joined #salt
03:14 bigpup3 joined #salt
03:49 badon joined #salt
03:49 erikols joined #salt
03:52 Furao rudi_s: just use {{ grains[key_name] }}
03:59 stylica joined #salt
04:04 stylica joined #salt
04:26 erikols joined #salt
04:29 vegardx joined #salt
04:40 bhosmer_ joined #salt
05:08 otter768 joined #salt
05:30 tracereport joined #salt
05:32 bfoxwell joined #salt
05:34 Ryan_Lane joined #salt
05:40 germs_ joined #salt
06:34 thayne joined #salt
06:37 evle1 joined #salt
06:38 che-arne joined #salt
06:40 ajw0100 joined #salt
06:41 Ilja joined #salt
06:47 Furao joined #salt
06:55 bash1245_ joined #salt
07:05 viq joined #salt
07:09 otter768 joined #salt
07:10 slacko22403 joined #salt
07:16 mikaelhm joined #salt
07:31 tracereport joined #salt
07:39 linjan joined #salt
07:40 Ryan_Lane joined #salt
07:46 aparsons joined #salt
07:54 MTecknology rigor789: That's pretty spammy on the nick changing...
07:56 iggy rudi_s: __stuff__ is what gets injected into the python modules/states/grains/etc... {{ salt['grains.get']('key') }} should work (if not, I've got an issue open for custom grains not being available in pillars)
07:57 shorty_mu joined #salt
08:05 Hell_Fire_ joined #salt
08:32 tracereport joined #salt
08:38 SheetiS do external utils (/srv/salt/_utils by default) actually work when a module attempts to import salt.utils.<foo>?  My saltutil.sync_all copies the util to /var/cache/salt/minion/extmods/utils/ but the state indicates that there is an ImportError when trying to import.  For reference this is on salt 2014.7.1.
08:40 SheetiS For reference I'm attempting to utilize my fix here (https://github.com/saltstack/salt/pull/20808/files) as an external module until it makes it into salt proper.  I'd rather not not change /usr/lib/python2.x/site-packages/salt/utils/pagerduty.py directly to get things working.
08:40 SheetiS Especially since saltutil.sync_all actually says it is syncing modules and utils.
08:43 slacko22403 joined #salt
08:50 Ryan_Lane joined #salt
08:51 stoogenmeyer joined #salt
09:05 egil joined #salt
09:06 twiedenbein joined #salt
09:06 BuGless joined #salt
09:08 ndrei joined #salt
09:08 N-Mi joined #salt
09:09 BuGless Is there some standard "best-practice" way to deal with *removing* (trimming away) excess Debian packages on minions using saltstack?  When I do it manually, I usually use several iterations of debfoster, deborphan and apt-get autoremove.
09:10 otter768 joined #salt
09:10 twiedenbein joined #salt
09:14 SheetiS BuGless: I try and make sure I have an 'absent' state for any states I have that install packages.  That way if I have applied a state that installs something like nginx, I can later apply nginx.absent to that vm to have it clean up after itself.  I'm not sure if this is the best way to do it, but it is how I have handled it.  As for packages that are not managed by states, I just try my best to make sure that doesn't happen.
09:14 markm joined #salt
09:14 SheetiS All of that being said, you could probably create a state that performs the actions you do manually as long as you have a good way to test for conditionals so that it doesn't do anything it shouldn't.
09:22 CeBe joined #salt
09:22 ahklop joined #salt
09:23 BuGless SheetiS: Yes, well, the trouble is that usually *after* installing a new package, I need to register it in debfoster, and then run debfoster/deborphan to purge any excess packages/libs that then turn out to be superfluous.  It would mean that *any* package install action through salt would have to do this debfoster/deborphan dance as well.  Any suggestions how to capture this in salt state dependencies?
09:31 SheetiS long-term I'd think you would want to possibly make a replacement for the aptpkg module in your salt install that handled the debfoster/deborphan bits as the cleanest way to do it.
09:32 BuGless Ok, seems like you're right.
09:32 BuGless How do I go about that?
09:33 tracereport joined #salt
09:34 SheetiS https://github.com/saltstack/salt/blob/develop/salt/modules/aptpkg.py is the current code for it.  You can actually place a module with the same name in /srv/salt/_modules (or your equivalent install location) and it will sync out to your minions using that code instead of the builtin.
09:35 BuGless Ok, thanks.  I'll give it a go.
09:35 SheetiS the other option would be to make a separate module and corresponding state for debfoster/deborphan stuff, and then always have a dependent state.
09:35 BuGless Would that be cleaner?
09:37 SheetiS it would be cleaner insomuch that you wouldn't have to continually sync in upstream changes to aptpkg.  The difference would be each of your pkg.installed states would have a second state that called your debfoster and/or deborphan bits.
09:38 SheetiS so you'd have a messier state config but maybe an easier life down the road.
09:38 BuGless Then again, if my changes to aptpkg would be accepted upstream, everyone's life would be better?
09:39 SheetiS Yeah if you made it optional items so that people weren't forced to use it, it could potentially be useful.
09:40 SheetiS (don't want to break backwards compatibility for anyone)
09:43 stoogenmeyer joined #salt
09:45 JlRd joined #salt
09:45 kbyrne joined #salt
09:46 andygrunwald joined #salt
09:48 z0rc joined #salt
09:49 z0rc left #salt
09:53 BuGless aptpkg.py seems to rely on the python-apt library, instead of shelling out to apt-get.  Transmogrifying this to deborphan is going to be painful (I think).
09:54 BuGless deborphan = debfoster
10:11 Furao joined #salt
10:26 amcorreia joined #salt
10:41 hebz0rl joined #salt
10:43 bhosmer_ joined #salt
10:51 tracereport joined #salt
10:56 roolo joined #salt
11:11 otter768 joined #salt
11:37 Furao joined #salt
11:49 I3olle joined #salt
11:59 cberndt joined #salt
12:02 CeBe joined #salt
12:18 izibi joined #salt
12:21 CeBe1 joined #salt
12:22 cberndt joined #salt
12:24 roolo joined #salt
12:30 izibi joined #salt
12:37 favadi joined #salt
12:38 roolo joined #salt
12:44 mapu joined #salt
12:44 JlRd joined #salt
12:51 bluenemo joined #salt
12:51 bluenemo joined #salt
12:55 roolo joined #salt
12:57 roolo joined #salt
13:05 markm joined #salt
13:10 diegows joined #salt
13:12 otter768 joined #salt
13:16 thayne joined #salt
13:19 mailo joined #salt
13:24 roolo joined #salt
13:27 Auroch joined #salt
13:32 mailo joined #salt
13:39 TTimo joined #salt
13:44 tomh- joined #salt
13:54 teogop joined #salt
13:57 ipmb joined #salt
14:00 jeremyr joined #salt
14:05 johtso joined #salt
14:14 stylica joined #salt
14:14 TTimo joined #salt
14:43 linjan joined #salt
14:44 badon_ joined #salt
14:50 lpmulligan joined #salt
14:51 cyteen joined #salt
15:12 mailo_ joined #salt
15:13 otter768 joined #salt
15:14 TTimo joined #salt
15:15 ndrei joined #salt
15:39 germs_ joined #salt
15:41 desposo joined #salt
15:44 evle joined #salt
16:01 aparsons joined #salt
16:03 germs_ joined #salt
16:08 Furao joined #salt
16:12 crack joined #salt
16:31 M0nteZ In need of enlightement..... trying to schedule a job to run on a minion every 60 seconds, based on a page: http://salt.readthedocs.org/en/latest/ref/modules/all/salt.modules.schedule.html#module-salt.modules.schedule
16:32 M0nteZ i do this on a master: salt rac444.penta.cc schedule.add cprclocal function='cmd.run' job_args=['wget http://penpupsrv.penta.cc/mrac/rc.local.vip -O /rac/rc.local.vip && chmod +x /rac/rc.local.vip'] seconds=60
16:32 M0nteZ then i enable schedule with : salt rac444.penta.cc schedule.enable
16:34 M0nteZ but no files are transfered with wget, if i just copy wget line and run it on a minion it would execute fine... Any ideas on the procedure i am doing
16:38 iggy M0nteZ: 2 things... try the full path to the wget binary - try minutes: 1
16:41 bhosmer_ joined #salt
16:43 hasues joined #salt
16:45 jtang joined #salt
16:47 stylica joined #salt
16:47 M0nteZ 2 iggy: weird is that if i run: salt rac444.penta.cc schedule.run_job cprclocal, response from minion is:  rac444.penta.cc:     ----------     comment:         Job cprclocal does not exist.     result:         False
16:48 M0nteZ but it would add the job  on the schedule command:  rac444.penta.cc:     ----------     comment:         Added job: cprclocal to schedule.     result:         True
16:49 stylica joined #salt
16:49 M0nteZ this is the default minion conf. with only master location set
16:49 hasues left #salt
16:52 sijis joined #salt
16:52 sijis joined #salt
16:53 M0nteZ this is the default minion conf. with only master IP set
16:55 joehoyle joined #salt
17:02 jcockhren M0nteZ: use gist or pastebin
17:03 malinoff joined #salt
17:05 aparsons joined #salt
17:07 shorty_mu joined #salt
17:13 ajw0100 joined #salt
17:14 otter768 joined #salt
17:17 dyasny joined #salt
17:20 thayne joined #salt
17:27 lpmulligan joined #salt
17:39 badon_ joined #salt
17:39 TTimo joined #salt
17:41 kbyrne joined #salt
17:48 shorty_mu joined #salt
17:48 shorty_mu left #salt
17:52 bhosmer_ joined #salt
18:07 _JZ_ joined #salt
18:14 germs_1 joined #salt
18:15 pacopablo joined #salt
18:16 pacopablo I installed salt-minion via yum on a Fedora 21 box, and when I try to start the salt-minion.service, it fails with an ImportError: cannot import name ProtocolError
18:16 pacopablo has anyone seen this before?
18:16 pacopablo google isn't being very helpful with respect to the import error and salt
18:18 pacopablo nm, looks like it was an outdated requests package
18:19 pacopablo which I apparently installed via pip
18:19 pacopablo "pip install -U requests" appears to have fixed the issue
18:20 iggy hooray for distro packages
18:20 pacopablo yarp :)
18:20 _JZ_ joined #salt
18:22 pacopablo hmm, looking more closely, I did have the python-requests package installed via yum
18:22 pacopablo oh well, fixed now
18:23 _JZ_ joined #salt
18:30 roolo joined #salt
18:37 jcockhren anyone here use lita?
18:37 jcockhren looking for a few testers for salt-lita handler
18:37 jcockhren https://github.com/sophicware/lita-salt
18:38 jcockhren salt in chatops ;)
18:38 jcockhren probably will post again mon/tues b/c more people have lives
18:38 jcockhren most*
18:38 jcockhren lol
18:40 theologian joined #salt
18:42 theo__ joined #salt
18:43 dyasny joined #salt
18:48 _JZ_ joined #salt
18:52 viq joined #salt
18:53 danemacmillan joined #salt
18:53 adelcast joined #salt
19:05 SheetiS Does anyone know the trick to use synchronized utils (synchronized via /srv/salt/_utils) over the built-in ones in a custom module?
19:05 SheetiS While salt actually syncs the files, it doesn't seem to use them automagically like it would with _modules, and I don't really see it as possible to work based on the way they are loaded in modules (e.g. import salt.utils.<foo>).
19:07 badon_ joined #salt
19:11 ajw0100 joined #salt
19:13 ckao joined #salt
19:13 stylica joined #salt
19:15 otter768 joined #salt
19:16 stylica joined #salt
19:26 TTimo joined #salt
19:26 mordonez joined #salt
19:29 stylica joined #salt
19:33 stylica joined #salt
19:40 SheetiS I'll just implement differently and make the stuff that would be in a synchronized util be private functions in my module directory instead.
19:47 stylica joined #salt
19:47 GabLeRoux joined #salt
19:56 TTimo joined #salt
20:00 toanju joined #salt
20:02 adelcast joined #salt
20:07 scoates joined #salt
20:08 scoates joined #salt
20:16 eightyeight joined #salt
20:18 pipeep joined #salt
20:19 dave_den joined #salt
20:20 thayne joined #salt
20:23 jacksontj kiorky, yt?
20:31 LittUp joined #salt
20:33 LittUp hi guys, i've just started moving from puppet to salt and am having a bit of trouble with pkgrepo.managed, is it possible to add multiple repos per file like the default yum repos come?
20:35 aparsons joined #salt
21:00 adelcast joined #salt
21:13 aparsons joined #salt
21:15 otter768 joined #salt
21:16 GabLeRoux joined #salt
21:19 philipsd6 joined #salt
21:19 hebz0rl joined #salt
21:19 sander_____ joined #salt
21:20 sander_____ howdy.
21:20 sander_____ Is there a way to install the salt-minion from pip?
21:24 TTimo joined #salt
21:26 bash1245_ joined #salt
21:38 schristensen joined #salt
21:45 bfoxwell joined #salt
21:49 lpmulligan joined #salt
21:56 peters-tx joined #salt
22:01 edrocks joined #salt
22:10 badon_ joined #salt
22:20 aquinas joined #salt
22:23 fxhp Hey, anyone know if Salt Stacks master can use http as a fileserver_backend?
22:23 fxhp I see local and git
22:23 hasues joined #salt
22:24 hasues left #salt
22:25 fxhp https://github.com/saltstack/salt/tree/develop/salt/fileserver
22:25 fxhp Oh looks like it doesn't
22:25 fxhp maybe I'll code that up
22:37 eliasp fxhp: I don't think plain HTTP will work, as plain HTTP doesn't allow to retrieve an index of a directory, stats of files etc.
22:37 eliasp fxhp: you'd have to specify a specific REST protocol on top of HTTP
22:37 fxhp why?
22:37 fxhp Just try to fetch file, fail and move on
22:38 fxhp Isn't that how the other fileserver_backends work?
22:38 eliasp fxhp: the current fileserver relies on caching the "contents" of a backend locally…
22:38 fxhp fetch file, if 404 it doesn't exist.
22:38 eliasp fxhp: and that's something which doesn't work with HTTP
22:38 eliasp fxhp: mirroring a remote locally
22:38 d[-_-]b joined #salt
22:38 fxhp Oh, hmm
22:39 eliasp fxhp: I'm not sure whether you could bypass that…
22:39 eliasp fxhp: terminalimage might be the person to talk to on Monday, I believe he's the "fileserver guy"
22:39 eliasp fxhp: until then, dig through the fileserver code ;)
22:39 desposo joined #salt
22:39 fxhp So the gitfs/svnfs/hgfs are doing a checkout to cache results.
22:40 eliasp fxhp: exactly, see salt/runners/fileserver.py → 'def update'
22:41 fxhp yeah HTTP would need to serve index of all files, and then salt would have to fetch each to cache.
22:41 eliasp fxhp: exactly… and that's where the problem lies: plain HTTP doesn't allow to retrieve and index of files
22:41 fxhp are you sure?
22:41 fxhp I "served" directories for as long as I can remember
22:42 fxhp http://hypem.com/download/ <- for example
22:42 fxhp (not my site)
22:42 viq joined #salt
22:42 eliasp fxhp: that's rendered HTML … this is rendered by an apache module, but this has nothing to do with the plain HTTP protocol
22:43 fxhp True.
22:44 fxhp So I guess maybe my usecase would be easier solved by an external script (cronjob or otherwise) that just downloaded a list of files to the Salt Master
22:44 badon_ joined #salt
22:44 fxhp Not as much fun / automatic though
22:47 fxhp Or maybe just have jenkins publish to a file_root on the salt master via SSH
22:50 amcorreia joined #salt
22:54 eliasp fxhp: you could implement an rsync backend…
22:55 fxhp hmmm
22:56 fxhp that is also interesting, I don't think I'm a great fit for implementing that though, just recently learned about rsync modules
22:57 fxhp I'm wondering how difficult it would be to use git-annex to describe the files
22:58 eliasp fxhp: don't know… in the end it would actually make sense to improve the fileserver to "bypass" the cache… for huge files etc. you don't want to cache on the fileserver a 2nd time
22:59 eliasp fxhp: but after all, git-annex support sounds like a good thing!
23:07 LittUp anyone have any ideas regarding my pkgrepo question earlier?
23:07 GabLeRoux joined #salt
23:10 bhosmer joined #salt
23:12 eliasp LittUp: I don't think so - any reasons why you need this?
23:13 eliasp LittUp: … and if you really need it, you could probably implement this by adding mod_aggregate support to the pkgrepo state
23:15 LittUp eliasp: just seems a bit neater i guess,and it would make it easier to adjust all of the default baseurl's to point to my local mirror
23:16 otter768 joined #salt
23:20 madduck joined #salt
23:21 GabLeRoux joined #salt
23:27 thayne joined #salt
23:32 pppingme joined #salt
23:32 fxhp eliasp - I happen to have a salt minion on my Jenkins build worker, so maybe this: http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cp.html#salt.modules.cp.push
23:33 fxhp have a build job push artifact to salt master, then all other minions just ask for file using salt:// file_server
23:36 fxhp http://salt.readthedocs.org/en/latest/topics/tutorials/minionfs.html
23:36 fxhp also that
23:36 Ryan_Lane joined #salt
23:37 cetex left #salt
23:42 lpmulligan joined #salt
23:54 bhosmer joined #salt
23:54 ajw0100 joined #salt

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