We have an extensive Salt ecosystem on SmartOS (on Triton) - running salt 2015.8.8 (Beryllium). This has proven to be very stable, virtually zero issues.
We package Salt directly into our custom zone image. This allows fast and hassle-free provisioning as the Salt agent is available at provisioning. Also, at provisioning time a user-script is injected along with metadata, where we set a key called "salt-master=<master IP>". The script then configures the agent and enables it. This works great with Triton, not sure if the user-script/metadata injection is supported on plain SmartOS.. On Thu, Sep 8, 2016 at 8:29 AM, Paul Sture <[email protected]> wrote: > Bearing in mind that I've only dabbled with SaltStack so far and > haven't got anything like a working SaltStack system... > > The default timeout in the salt 'master' file is 5 seconds. I've > had success by increasing that. > > Thanks for your installation instructions. I couldn't get the latest > version of SaltStack installed into native zones going via the non-git > route; they were stuck at 2015.8.5 (Beryllium). > > Having said that, I don't really want git as a prerequisite - it's > relatively huge by virtue of the dependencies it has. > > > On 7 Sep 2016, at 21:05, Filip Chabik wrote: > > Hi guys, >> >> happy to see some other SaltStack + SmartOS users out there. Recently >> salt became a bit more unstable for me and I was hoping to dig a bit >> deeper and check whether the issue is on my side, my salt-master side >> or in the compatibility of salt-minion and SmartOS zone. Here's the >> deal: >> >> 1. I'm using 15.4.1 LTS on all of my zones. >> 2. Not long ago I decided to "bump up" my SaltStack minions to version >> 2016.3.1. >> a) In order to achieve both points mentioned above, I had to use >> some "creativity" when it comes to SaltStack installation. >> b) I have a deploy script that I run after every >> provisioning/reprovisioning of the zone which is also handling Salt >> installation, like this: >> >> # Installing Salt dependencies: >> pkgin -y in zeromq py27-m2crypto py27-crypto py27-msgpack >> py27-yaml py27-jinja2 py27-zmq py27-requests py27-pip py27-tornado >> py27-six >> >> # This one ought to be installed via pip for some reason I >> can't recall now: >> pip install futures >> >> # The de facto installation: >> curl -L https://bootstrap.saltstack.com -o install_salt.sh >> sudo sh install_salt.sh -A ${master_ip} -i >> "${1:-${minion_name}}" -P git v2016.3.1 >> >> 3. This is generally working fine -- while I'm running silly stuff >> like test.version, test.ping or cmd.run <any_given_cmd> all is good. >> But whenever I hit some more demanding stuff, like state.highstate >> that's going through couple of formulas, I very often get information >> in red saying: "didn't get response from the minion" (or something >> along these lines). >> >> My question is -- are you guys also experiencing such behavior? I have >> some formulas that are supposed to run bash script in order to get >> some stuff done on the zone, but they rarely succeed when triggered >> through Salt. Sometimes they are succeeding, but I still get the same >> "didn't get response from the minion" on the master. >> >> Guess I will need to dig a bit deeper into debugging this, but I was >> hoping that maybe some of you already experienced such behavior and >> have some tips & tricks to share (like for example: "dude, don't >> upgrade to anything above 2015.8.x on LTS zones..."). >> >> All the best >> > > ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
