Batali Cookbook Dep Solver


#1

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:

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:

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


#2

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 michael@hw-ops.com 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


#3

This is essentially what the policy file will do.

Sent from my iPhone

On Mar 17, 2015, at 9:50 PM, Torben Knerr mail@tknerr.de 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 michael@hw-ops.com 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


#4

#rekt

On Wed, Mar 18, 2015 at 6:52 PM, Adam Jacob adam@chef.io wrote:

This is essentially what the policy file will do.

Sent from my iPhone

On Mar 17, 2015, at 9:50 PM, Torben Knerr mail@tknerr.de 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 michael@hw-ops.com 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


#5

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 adam@chef.io wrote:

This is essentially what the policy file will do.

Sent from my iPhone

On Mar 17, 2015, at 9:50 PM, Torben Knerr mail@tknerr.de 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 michael@hw-ops.com
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.

  1. Performs least-impact updates by default, so an update doesn’t pull
    in

unexpected changes.

  1. 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


#6

Per node resolution

Sent from my iPhone

On Mar 17, 2015, at 11:30 PM, Michael Weinberg michael@hw-ops.com wrote:

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 adam@chef.io wrote:
This is essentially what the policy file will do.

Sent from my iPhone

On Mar 17, 2015, at 9:50 PM, Torben Knerr mail@tknerr.de 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 michael@hw-ops.com 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