Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-08-03

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

All times shown according to UTC.

Time Nick Message
00:01 ndrei joined #salt
00:19 TyrfingMjolnir joined #salt
00:51 m1crofarmer joined #salt
00:56 ramishra joined #salt
01:07 swa_work joined #salt
01:23 nick__ joined #salt
01:38 jhauser_ joined #salt
01:57 ramishra joined #salt
02:02 Alan_S joined #salt
02:03 rihannon joined #salt
02:13 Vye_ dancat: http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html
02:14 delinquentme joined #salt
02:14 delinquentme is there some upper limit with how many minions a single master can handle??
02:35 dancat Vye: thanks!
02:39 delinquentme with regards to: master_type: failover
02:40 delinquentme I thought minions are partitioned exclusively via the master ... so is this a case of the master fining up minions ... and then that master being laggy / dead ... and the minion needing to find an alt master?
02:43 bhosmer joined #salt
02:47 Alan_S joined #salt
02:47 napper joined #salt
02:47 ajw0100 joined #salt
02:48 Outlander joined #salt
02:57 schristensen joined #salt
02:58 ramishra joined #salt
03:14 dccc joined #salt
03:16 dccc joined #salt
03:42 schristensen joined #salt
03:57 pmcg joined #salt
03:58 ramishra joined #salt
04:03 napper joined #salt
04:05 delinquentme left #salt
04:11 sectionme joined #salt
04:26 redondos joined #salt
04:33 beneggett joined #salt
04:36 manfred nickg: ping
04:37 manfred nickg: check out check_cmd in 2014.7, you can do a sleep 60 && <command> to check if your thing has succeeded to run, then you will have the stuff in the state match up for your batch mode
04:37 manfred I am going to try and make it so that those commands run through a for loop, and if they succeed before the timeout is hit, they will say the state succeeded, otherwise failed
04:38 Bryanstein joined #salt
04:41 napper joined #salt
04:42 jalbretsen joined #salt
04:56 ramishra joined #salt
05:16 m1crofarmer joined #salt
05:22 fllr joined #salt
05:24 bdf joined #salt
05:26 napper joined #salt
05:28 fllr joined #salt
05:45 d3vz3r0_ joined #salt
06:03 ramishra joined #salt
06:09 thayne joined #salt
06:11 fllr joined #salt
06:14 Vye dancat: yw
06:16 napper joined #salt
06:17 rihannon joined #salt
06:38 johngrasty So...I can't get the mysql functions to work. It is returning that they are not available. I have installed the dependencies as well.
06:38 johngrasty Any good ways to debug this?
06:41 chamunks joined #salt
07:05 Guest66190 joined #salt
07:17 chiui joined #salt
07:20 fllr joined #salt
07:40 ramishra joined #salt
07:49 ramteid joined #salt
07:50 fllr joined #salt
08:08 bhosmer joined #salt
08:20 fllr joined #salt
08:32 zz_chamunks joined #salt
08:40 viq huh, from 2014.1.7 to 2014.1.10, that's some jump
08:41 ramishra joined #salt
08:43 TyrfingMjolnir joined #salt
08:50 TyrfingMjolnir joined #salt
08:55 TyrfingMjolnir joined #salt
08:57 athe joined #salt
09:07 dccc joined #salt
09:07 taterbase joined #salt
09:09 rihannon joined #salt
09:10 ajw0100 joined #salt
09:13 ollins joined #salt
09:13 TyrfingMjolnir joined #salt
09:14 ramishra joined #salt
09:14 DaveQB joined #salt
09:20 fllr joined #salt
09:24 ndrei joined #salt
09:25 tyson_ joined #salt
09:41 babilen viq: It's all the underground releases that we mere mortals miss out on
09:42 intellix joined #salt
09:42 babilen "This release contained a regression which caused inaccurate Salt version detection, and thus was never packaged for general release. Please use version 2014.1.10 instead." -- I wonder why it was "released" at all.
09:43 intellix joined #salt
09:43 babilen It also seems that my understanding of a "release" and that of saltstack is different
09:46 babilen Hmm, v2014.1.8 is the latest tag in the archive
09:47 babilen No, there are newer tags on GH. I wonder what I'm missing :-/
09:52 babilen I had to explicitly run "git fetch --tags" -- I wonder why (as git should fetch all that are reachable from tracked branch HEADs)
09:52 CeBe joined #salt
09:56 babilen Looks as if somebody forgot to push something: "git branch --remote --contains v2014.1.8" vs "git branch --remote --contains v2014.1.9" and "git branch --remote --contains v2014.1.10"
10:01 babilen "git branch --remote --contains 0a44a479" vs "git branch --remote --contains aa9c366" and "git branch --remote --contains ab167959"
10:01 babilen basepi: ^^ what is this snafu?
10:03 babilen "a50fe19 - Add 2014.1.9 release notes" (note a50fe19 vs aa9c366) can be found in the logs but nothing for .10
10:06 jambala joined #salt
10:08 * jambala says Hi everybody
10:09 homelinen joined #salt
10:10 jambala Anyone willing to answer a question about the order that environments are being processed?
10:10 babilen Just ask a question if you have one. If *that* is your question then the answer is: Yes
10:10 babilen That was easy :)
10:11 jambala @babilen just a moment, am on the telephone
10:12 babilen jambala: It's *you* who wanted to ask a question at this time ;)
10:14 jambala ok, sorry for the delay
10:15 TyrfingMjolnir joined #salt
10:15 jambala basically, if been trying to figure out the way salt processes the environment
10:15 ramishra joined #salt
10:16 jambala from my testing, I could not find any deterministic ordering when using more than a single environment
10:16 jambala there a no requisites involved (the states just write files with a timestamp)
10:17 jambala so, how does salt figure out what environment comes first?
10:18 jambala it's not lexically, so much is clear
10:18 APLU joined #salt
10:18 jambala also, the order in the top file seems not to determine the order of processing
10:19 babilen How do you use more than one environment?
10:20 babilen (are you sure that's supported?)
10:20 jambala setting it up in the master config, then using these in the top.sls
10:20 babilen I mean I could look into the code, but it is probably just a dictionary (or variation thereof) and therefore by nature unordered
10:21 jambala example: base: - /srv/salt
10:21 Guest66190 joined #salt
10:21 jambala prod: - /srv/salt
10:21 babilen Plase use a pastebin such as http://paste.debian.net or http://refheap.com
10:21 jambala k, just a sec
10:22 babilen Yeah, but only one would be "active" or "used" at any given time. I know how to configure multiple environments, but I wonder how you managed to run into a situation in which the order matters
10:22 babilen (i.e. in which multiple environment are being actively used)
10:23 babilen But then I haven't used environments much
10:24 jambala Here comes the master config snippet:  http://paste.debian.net/113385
10:24 babilen It's all the same :)
10:25 jambala Now, the top file: http://paste.debian.net/113386
10:26 jambala All of the three environments are getting picked up
10:26 babilen Okay, why do you declare three environments if they are exactly the same? And what do you mean by "all three environments are getting picked up" ?
10:27 babilen I have the feeling as if you are the victim of some misunderstanding - It would help if you could tell me what you are trying to achieve and why you configured it the way it is configured now
10:28 babilen What you have there uses *exactly* the same states for each environment and there is, therefore, no difference between them.
10:28 viq jambala: and I believe the idea is to _not_ assign all machines to all environments
10:28 viq But to one specific one.
10:28 jambala It's just for testing, trying to figure out how salt does stuff
10:29 babilen So, what are you trying to achieve?
10:29 babilen First and foremost you should use different paths for each environment (so that they *can* be different). Something like "- /srv/salt/base" for base and "- /srv/salt/dev" for dev.
10:30 babilen That setup is being detailed on http://docs.saltstack.com/en/latest/ref/states/top.html btw
10:30 jambala @babilen Yes, I'm aware of that
10:30 jambala As I said, it's just for testing the order processing
10:30 jambala Let me explain ...
10:30 babilen (this isn't twatter and you don't need the @, but it is customary to use "NICK:" or "NICK," on IRC)
10:30 babilen There is no order
10:31 babilen But please, explain
10:31 jambala Say you do have to bare metal machines to set up
10:31 jambala two - I meant
10:32 jambala so you would have a base environment that sets up users/groups/ssh etc
10:32 viq I think I see first misunderstanding
10:32 viq jambala: that's not what environments are for
10:32 jambala please explain viq
10:33 babilen Hmm, maybe we should let jambala finish first and then take it from there?
10:33 viq Environments are there to let you use different sets/versions of states
10:33 babilen I'd like to see the whole picture ..
10:33 jambala so, then let me carry on
10:33 viq yeah, sorry
10:33 babilen It sounds as if, what jambala, is looking for is orchestrate, but I'm not sure yet
10:34 jambala As I said, the base environment sets up the basic stuff
10:34 babilen s/,/
10:34 jambala after that, every machine would have a slightly different setup
10:35 jambala let's assume machine A will run a webserver, while machine B host an MX
10:36 ingwaem joined #salt
10:36 jambala there could also be a machine C that replicates what machine B does but with different credentials (SSL certs and the like)
10:37 * babilen nods
10:37 ingwaem greetings everyone…has anyone successfully setup salt-virt? I’m trying to get it setup on a mac mini but having issues…seems the tutorial on saltdocs isn’t complee
10:37 ingwaem complete*
10:37 jambala so i figured, it would be usefull to have different environments for the machines
10:38 babilen ingwaem: *Always* provide details of those elusive "issues" ran into (e.g. on a pastebin such as http://paste.debian.net or http://refheap.com ) and I am sure that you would also accept answers from people who haven't used salt-virt before ;)
10:38 ingwaem babilen: oh I would accept any answer from anyone who knows :) even if they haven’t used it, perhaps someone is aware of a guide that works…let me get you some specifics
10:38 babilen jambala: No, as viq tried to explain already: You misunderstood what environments are and confuse them with what targeting of minions is being used for.
10:38 DaveQB joined #salt
10:40 babilen jambala: Environments are used to implement quality control measures or testing environments in which you target different versions/sets of states to different machines.
10:40 ingwaem I installed virt onto a brand new ubuntu salt master…even downloaded the states from saltstates, and ran the saltvirt state, which had a dependency for libvert…both installed successfully…now when running the command as stated on the tutorial this is what I get:
10:40 ingwaem salt-run virt.hyper_info
10:40 ingwaem No minions matched the target. No command was sent, no jid was assigned.
10:40 ingwaem so if I use the salt command and specifically target the minion on the master that has virt, salt 'sdlchv001' virt.hyper_info
10:40 ingwaem sdlchv001:
10:40 ingwaem "virt.hyper_info" is not available.
10:40 babilen jambala: In that, for example, boxes in the "dev" environment are virtual machines that run locally on developer boxes and that can be broken at will.
10:41 babilen jambala: What you are looking for is a way to target different states at your minions and you can use all the mechanisms detailed in http://docs.saltstack.com/en/latest/topics/targeting/ for that
10:42 babilen All your minions will, however, be in the same environment (name "base" (i.e. "production"))
10:42 babilen *namely
10:42 bhosmer joined #salt
10:43 ingwaem babilen is correct, to target a specific state on a specific minion simply use: salt ‘minionname’ state.sls yourstatenamehere
10:44 jambala babilen: i.e. I would have to use a single pillar which holds all my config for the different machines, as opposed to having the same but narrower pillar in an environment?
10:44 babilen ingwaem: That is correct, yes
10:45 babilen jambala: You would use different files in your pillar and target those specifically to your minions, but you would only have one pillar for your environment, yes
10:45 ingwaem jambala: when to use pillars and grains depends on the data you’re storing…if the data is static, use grains…if the data is sensitive and perhaps dynamic use pillars.
10:46 jambala babilen: ok, if that's how it is supposed to be, then I'll rethink my approach
10:47 eliasp babilen: an environment is mostly meant as a tool to get your code into a stable state… so your SLS code would start in a 'dev' environment, when it is ready to be tested, it is merged into the 'test' environment, goes from there into a 'staging' environment and finally ends up in "production" (in saltstack terms: base/master) … so in the end what you have running is more or less just the "base" environment, all
10:47 eliasp other environments just exist for the sole purpose of having a stable "master/base" environment
10:47 babilen jambala: You would typically use some logic *in* you pillar to present different data to different minions or just target completely different pillars to minions altogether
10:47 eliasp oups… was meant for jambala
10:47 eliasp … TAB completion ;(
10:47 babilen eliasp: Yes, please tell jambala
10:48 eliasp so environments are just a "development workflow"
10:48 jambala eliasp, I got it
10:48 viq jambala: if you're familiar with git, environments are like branches
10:49 babilen jambala: Say you have two minions, A and B. You could them use something like "base: \n "A": \n - ssh.a \n "B": \n - ssh.b" in your pillar top.sls or target the same ssh.sls file to both and present different data based on the minion id (or other data)
10:50 jambala thanks guys, I grasp the concept
10:50 ingwaem I don’t use environments that much at the moment…currently only focusing on a dev environment, but I like the syndic approach so will probably have masters in each environment then a master of master with environments defined to each of the masters
10:50 ingwaem :)
10:50 babilen jambala: I would recommend to read http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html and http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
10:51 jambala environments just struck me for being a handy way to really seperate configuration (templating seems a bit akward - all the ifs/elses)
10:52 jambala babilen: I have spent quite some time reading the docs and am familiar with how pillars work
10:53 jambala babilen: it just did not feel right to mix and match configuration for different clients in a single file
10:54 jambala babilen: that's why I was looking at environments to seperate the configuration data physically
10:54 babilen jambala: Whenever I *really* need to target different values at my minions (which rarely happens as you really want them all to be identical) I write my pillars in Python and use https://www.refheap.com/88844
10:54 eliasp jambala: if it's about deploying config files to different clients, you can make the differentation in your SLS and use different templates based on the targetted client
10:55 jambala babilen: I'll have a look at your link, sounds like an alternative
10:55 babilen jambala: You can easily introduce additional layers in your pillar organisation. Something like pillar_root/$CUSTOMER/users.sls so that you would target boxes of customer $CUSTOMER (say "foo") with - foo.users and users of customer "bar" with bar.users
10:56 babilen The organisation of your pillars really depends on your setup and what makes sense there ...
10:56 eliasp the name/path of a pillar SLS doesn't have to match the internal pillar structure, so the structure inside foo.users and bar.users could be just the same
10:56 babilen (same for your states)
10:56 babilen Yeah, that is an important aspect
10:56 eliasp the name/path is just used for assigning it in your Pillar top.sls
10:57 babilen You can easily save the foo:bar:baz pillar values in something/entirely/different.sls
10:57 jambala babilen: how so?
10:57 eliasp the internal structure is, what's used in your Jinja templates etc. then…
10:58 viq I'm waiting for Helium as it will be able to merge pillars
10:58 eliasp viq: isn't 2014.1 already able to do that?
10:58 viq No
10:58 babilen jambala: http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html#more-complex-data you could save that pillar in foo/bar/baz/users.sls and target it with '*' \n - foo.bar.baz.users and the data the minions would see would be identical
10:59 babilen viq: It will!?
10:59 babilen \o/
10:59 viq babilen: yes, I even looked at the code to make sure, and it is in 2014.7 branch
10:59 jambala thanks guys, very helpfull bunch over here :D
10:59 babilen Is it "stupid" merging (i.e. {}.update(some_other_dict)) or something more intelligent/controllable?
11:00 viq babilen: give me a few moments, I'll try to find it
11:01 babilen jambala: So, say you want to configure/setup users on various machines and you are using https://github.com/saltstack-formulas/users-formula to do so. The pillar that is supported by that formula looks like https://github.com/saltstack-formulas/users-formula/blob/master/pillar.example
11:02 viq babilen: good starting point for info about this: https://github.com/saltstack/salt/issues/3991#issuecomment-35486558
11:03 babilen jambala: You, naturally, don't want the same set of users on every box, but you might manage machines for two customers, say corporation_megadon and foundation_dowell. You would then have *two* different pillar files, say, - corporation_megadon.users and - foundation_dowell.users that you target to different machines.
11:04 jambala babilen: ok, I think I'll drop the environment approach
11:04 jambala babilen: as to your second question from above >>Yeah, but only one [environment] would be "active" or "used" at any given time<<
11:04 jambala babilen: that's not true from what my testings show
11:04 babilen If all machines of the corporation have an ID of corp-* and the foundation of found-* you would use "'corp-*' - corporation_megadon.user" and "'found-*' - foundation_dowell.users" respectively
11:05 babilen jambala: Well, you used the same file_root for all your environments
11:05 babilen (i.e. there is no difference)
11:05 jambala why would the file roots dictate the environment
11:05 babilen viq: I'm crying ..
11:06 jambala isn't it just the other way round?
11:06 babilen viq: I am waiting for that to be closed every since I started using salt.
11:06 viq babilen: SOON
11:07 jambala the way I see it, is that the minion matching is responsible for what kind of environment is picked up
11:08 babilen jambala: You set "base: - /srv/salt" and "deva: /srv/salt" so states in /srv/salt would be used by both environments and the environments would therefore be indentical
11:08 jambala babilen: yes, I know but that's not the point
11:08 babilen It is the point
11:09 jambala babilen: the point is, even if I had physically different paths all the matching environments would still run
11:09 babilen Yes, but minions shouldn't be in more than one environment
11:09 jambala babilen: see, that's a premise I didn't know of
11:11 babilen jambala: I mean they can, but you should always target different states to them. If your environments don't differ you would end up targeting the same twice.
11:11 babilen If you set different file_roots then your "- db" state would come from different files.
11:12 jambala yep and that's what I wanted in the first place
11:12 babilen i.e. file_roots/qa/db.sls and file_roots/dev/db.sls
11:13 babilen But for that to work you would have configure it to use file_roots: /srv/salt/dev for the "dev" environment and /srv/salt/prod for the "base" environment
11:13 babilen It would also *still* not be the right approach to *target* different states, formulas or settings to different minions.
11:14 jambala I thought I could use enviroments as some kind of inherently transparent namespace
11:14 babilen That would, as detailed above, be done by means of organising the state space in a way that makes sense and then using the methods in http://docs.saltstack.com/en/latest/topics/targeting/ for, well, targeting
11:15 jambala yes, I do see the error in my thought process, now
11:15 aquinas joined #salt
11:16 ramishra joined #salt
11:16 jambala environments are meant to seperate different states of development workflow rather than seperating configuration
11:17 jambala right?
11:19 * jambala being afk
11:19 eliasp jambala: right!
11:22 * jambala re
11:23 jambala thanks again, guys
11:25 TyrfingMjolnir joined #salt
11:33 homelinen joined #salt
11:37 diegows joined #salt
11:43 mapu joined #salt
11:45 TyrfingMjolnir joined #salt
12:07 ggoZ joined #salt
12:16 ramishra joined #salt
12:23 sectionme joined #salt
12:27 Guest66190 joined #salt
12:29 Marvin joined #salt
12:33 Guest41685 hello, tell me pleasу how to install the module in glosterfs solt-master, detail.
12:34 Guest41685 glusterfs*
12:35 Guest41685 привет подскажите плиз как установить модуль гластерфс в сальт мастер? а то я ставить ставлю вроде скачал файл из гит хаба, сделал рестарт, сделал синхронизацию, но в листе модулей на миньонах этот модуль не появляется
12:48 TyrfingMjolnir joined #salt
12:49 sectionme joined #salt
12:53 intellix joined #salt
12:53 ramishra joined #salt
12:54 scoates joined #salt
12:56 scarcry joined #salt
13:00 babilen Guest41685: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.glusterfs.html + http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.glusterfs.html
13:02 ingwaem joined #salt
13:03 chiui joined #salt
13:04 ingwaem greetings ya’ll…having some issues getting salt-virt to work…after installing the salt-virt state from saltstates git along with dependencies, I figured I should be good to go. Also ensured pillar data for the virt.nic is in place, and I get salt-run virt.hyper_info No minions matched the target. No command was sent, no jid was assigned.
13:04 scoates_ joined #salt
13:05 ingwaem did a debug of salt-run and confirm that the virt stuff is in there...[TRACE   ] Added virt.force_off to runner
13:05 ingwaem and [TRACE   ] Added virt.hyper_info to runner
13:16 ramishra_ joined #salt
13:19 thayne joined #salt
13:32 bhosmer joined #salt
13:43 monokrome joined #salt
13:54 ramishra joined #salt
14:18 fllr joined #salt
14:23 arthabaska joined #salt
14:31 thayne joined #salt
15:12 ramishra joined #salt
15:12 lopez hello... i have a question on external pillars, i've read the docs and think i mostly understand how they work and how to write them. but how is the data from external pillars accessed from within the states?
15:14 lopez i.e., into which object is the data from the ext_pillar function merged in?
15:15 mechanicalduck joined #salt
15:18 jambala babilen: hi, remember my question regarding the order that environments are processed?
15:21 dccc joined #salt
15:21 babilen sure
15:22 [jambala] joined #salt
15:22 [jambala] bailen: i've dug around the source and it seems that environments are kept in an unordered list which makes predicting the order in which they are processed impossible
15:23 babilen I sort of expected a dictionary, but fair enough
15:23 babilen Oh, and most IRC clients support tab-completion of nicknames. Try bab<tab>
15:24 [jambala] babilen: so, you guys had it all right, environments cannot be used like I wish I could
15:25 [jambala] babilen: on "babi<tab>" my client gives me: babilen,
15:25 [jambala] babilen: is that the same as xxx:
15:26 babilen That's perfectly fine. You can probably configure it to use ':' rather than ',' if you prefer that.
15:26 babilen (and preferable to typing it yourself or typos in nicknames)
15:26 [jambala] thanks again for your patience, earlier
15:27 babilen No problem, I hope I could clear some things up and that you have a better idea on how to accomplish whatever it is you want to accomplish :)
15:28 fllr joined #salt
15:28 [jambala] babilen, you certainly could
15:32 [jambala] babilen: ok I'm out, have a nice day
16:17 napper joined #salt
16:17 rekibnikufesin joined #salt
16:25 smcquay joined #salt
16:34 dancat ? I am running into an issue with pip3 in my salt state where I install pip3 (python-pip3) and I specify the bin_env is pip3 but the state will only proceed if pip is installed even though pip3 is ultimately used. Any thoughts?
16:35 dancat I didn't make it clear but I am installing packages with pip3 after I install pip3
16:35 dancat If I install pip (pip2) and pip3 then I can use pip3 to install packages but if pip2 is not installed then pip3 will not work
16:37 * eliasp mumbles something about "fucking language/domain-specific package managers" … the hell of distribution packagers + sysadmins
16:39 thayne joined #salt
16:45 Eugene If only there were a single standard for package management. Oh wait, that's RPM.
16:45 Eugene If only everybody could stick to it....
16:50 eliasp nah, RPM is a hellhole as well… http://xkcd.com/927/
16:51 Eugene Exactly my point
16:51 eliasp it's just that all these domain-specific package managers act completely on their own, re-invent the wheel again, make all the mistakes again and act completely out of control of the system's package manager… all they should do: provide proper metadata which can be re-used for re-packaging by distributions
16:52 Eugene Yup, sure should. And each one will provide that metadata in their own format
16:52 eliasp well, I'd be fine with that, if the metadata would be at least consistent and properly done ;)
16:52 eliasp anyways… gotta run
16:52 eliasp bye
17:08 smcquay joined #salt
17:10 dancat in a salt state, why would pip2 be required if pip3 is the executable doing the work?
17:12 rgarcia_ joined #salt
17:22 MaZ- joined #salt
17:26 jessec joined #salt
17:30 krak3n`` joined #salt
17:50 ckao joined #salt
17:52 kober joined #salt
17:53 kober have you guys used the salt provisioner for vagrant?   It seems locked up, it said this: Calling state.highstate... (this may take a while)    but hasn't moved for awhile
17:53 kober Wondering if there is a way to get better output
17:54 MrTango joined #salt
18:03 kober I see a bunch of these in the minion logs: 2014-08-03 18:03:16,978 [salt.utils       ][ERROR   ] This master address: 'salt' was previously resolvable but now fails to resolve! The previously resolved ip addr will continue to be used
18:04 kober But it shouldn't be trying to get to a master, it has file_client: local
18:05 kober Loooks like everything worked but weird to have errors in the logs
18:06 dancat kober: I have an arg in mine to do verbose logging: salt.verbose = true
18:07 dancat or you can skip doing the provisioner in the vagrant startup and do it via the command line on the vagrant ssh terminal with salt-call
18:08 dancat assuming you are doing this as a masterless minion make sure your salt-call commands end with --local
18:08 kober dancat: Yeah, thats what I was doing but figured I should see if I could get the provisioner to work
18:09 kober So it all finished and worked, my only problem is that it seems to be looking for a master even though its masterless
18:09 kober .verbose is nice, lets me see what its doing
18:10 TyrfingMjolnir joined #salt
18:11 dancat do you have an other vagrant arg for: salt.minion_config = "salt/minion"
18:11 kober Yeah, that worked, because before I forgot to set file_client it would never finish
18:12 dancat and that file needs to have one line: file_client: local
18:12 kober because it was forcing to connect to master
18:12 kober But nBut even now with file_client set it still has those errors int he logs
18:12 dancat kober: weird
18:13 dancat that's about as much help as I can be :)
18:13 kober Yeah, that was definitely helpful, and the errors aren't stopping it from working
18:13 kober they are just weird
18:18 kober So the next thing, is how do I figure out what "failed"? In the summary 2 succeeded and 1 failed
18:18 TyrfingMjolnir joined #salt
18:24 mspah_ joined #salt
18:27 TyrfingMjolnir joined #salt
18:57 bhosmer joined #salt
19:05 Luke joined #salt
19:07 otter768 joined #salt
19:10 beneggett joined #salt
19:15 peters-tx joined #salt
19:16 dave_den joined #salt
19:23 roolo joined #salt
19:37 rgarcia_ joined #salt
19:46 ndrei joined #salt
19:51 flebel joined #salt
19:51 aberdine joined #salt
20:01 ggoZ joined #salt
20:04 Whissi joined #salt
20:17 martoss joined #salt
20:19 sectionme joined #salt
20:20 jhauser joined #salt
20:29 bhosmer joined #salt
20:59 thayne joined #salt
21:01 viq joined #salt
21:05 andrej joined #salt
21:28 anotherZero joined #salt
21:30 cornelinux joined #salt
21:33 jessec joined #salt
21:33 snuffeluffegus joined #salt
21:41 ndrei joined #salt
21:41 anotherZero joined #salt
21:58 martoss joined #salt
22:02 dccc joined #salt
22:03 brenix joined #salt
22:18 bhosmer joined #salt
22:30 Outlander joined #salt
22:39 majoh joined #salt
22:39 jgelens joined #salt
22:46 arthabaska joined #salt
22:48 Luke joined #salt
23:05 vejdmn joined #salt
23:26 mosen joined #salt
23:40 aw110f joined #salt

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