[chef] Re: Re: Re: Batali Cookbook Dep Solver

[Michael Weinberg < >]

Adam, can you clarify if your response was directed to Torben or to me? I believe you meant that per-node resolution is essentially what policyfile will provide. 

If you meant that the whole infrastructure features of Batali are the same as policyfile, I'm seriously misunderstanding the policyfile description. 

Thanks!

--

Michael F. Weinberg | Director of Operations

http://heavywaterops.com | @heavywaterops

On Tue, Mar 17, 2015 at 10:52 PM, Adam Jacob < " target="_blank"> > wrote:

This is essentially what the policy file will do.

Sent from my iPhone

> On Mar 17, 2015, at 9:50 PM, Torben Knerr < "> > wrote:
>
> Hi Michael,
>
> interesting stuff.
>
> Glad to see that you are taking resolution of infrastructures into
> account, that was missing from both librarian and berkshelf. Still,
> I'm wondering whether it's lacking the notion of a node, i.e.:
>
> * infrastructure being a set of nodes with independent dependency graphs.
> * within each graph the "users" cookbook must resolve to a unique
> version, but across the graphs it could exist in different versions in
> the same infrastructure
> * ideally this was represented on the filesystem level as well, i.e.
> "cookbooks/node-abc/users-1.7.0" along with
> "cookbooks/node-xyz/users-1.6.0" for example
>
> I am currently achieving that using berkshelf + the
> vagrant-topevel-cookbooks [0] plugin, which obviously works only if
> you use vagrant for describing your infrastructures. However, I could
> imagine that a per-node representation of the dependency graph could
> be useful for chef-provisioning [1] as well.
>
> Cheers,
> Torben
>
>
> [0] https://github.com/tknerr/vagrant-toplevel-cookbooks
> [1] https://github.com/chef/chef-provisioning
>
>
>> On Wed, Mar 18, 2015 at 1:11 AM, Michael Weinberg < "> > wrote:
>> Hi All,
>>
>> We're really excited to share a recent Heavy Water Labs project, Batali, a
>> lightweight cookbook dependency solver that "does one thing well."
>>
>> We've got a nice write up about it here:
>> http://hw-ops.com/blog/2015/03/17/batali/
>>
>> The TL;DR on our rationale for Batali:
>>
>> 1. Just solves dependencies, no workflow required or supplied, and no repo
>> structure dictated.
>>
>> 2. Performs least-impact updates by default, so an update doesn't pull in
>> unexpected changes.
>>
>> 3. Solves for your entire infrastructure, including incompatible dependency
>> trees for independent nodes/run lists.
>>
>> The project is hosted here:
>> https://github.com/hw-labs/batali
>>
>> Batali is currently in a stable alpha state, and we're actively using it for
>> internal projects.
>>
>> Enjoy!
>> --
>> Michael F. Weinberg | Director of Operations
>> http://heavywaterops.com | @heavywaterops