-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why use instead of plain chef solo? #31
Comments
So, I realize this might seem a little trolly, so I want to provide some more context. I want to decide if I should just start using chef-solo + omnibus installer, since that seems easier in general. |
A somewhat opinionated workflow emerged at Pivotal over the years and using chef-solo directly typically results in boilerplate & indirection with this. Soloist addresses this; we can often simply add a Soloistrc to an existing project to describe its entire workstation configuration. I'll let @mkocher chime in on his plans for it when he's back from vacation. As for chef-omnibus, @cunnie and I are exploring using an omnibus install of soloist for Sprout to avoid relying on OSX's system Ruby: https://github.com/hiremaga/omnibus-soloist Here's an installer that worked on my machine - https://github.com/hiremaga/omnibus-soloist/releases |
@hiremaga yeah, I had looked into your omnibus-soloist. Looks cool. I think On Sun, Sep 15, 2013 at 3:52 PM, Abhi Hiremagalur
|
This is kindof a meta issue, but it is something I've been wondering.
I can't figure out what advantage soloist has over using plain chef-solo.
Am I missing something? Are there plans for the future?
The text was updated successfully, but these errors were encountered: