Batali Cookbook Dep Solver

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

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] GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the per-node top-level cookbooks in chef-solo based infrastructures
[1] GitHub - chef-boneyard/chef-provisioning: A library for creating machines and infrastructures idempotently in Chef.

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:
Sensu | Page not found

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:
GitHub - spox/batali: Light weight cookbook resolver

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

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] GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the per-node top-level cookbooks in chef-solo based infrastructures
[1] GitHub - chef-boneyard/chef-provisioning: A library for creating machines and infrastructures idempotently in Chef.

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:
Sensu | Page not found

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:
GitHub - spox/batali: Light weight cookbook resolver

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

#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] GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the per-node top-level cookbooks in chef-solo based infrastructures
[1] GitHub - chef-boneyard/chef-provisioning: A library for creating machines and infrastructures idempotently in Chef.

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:
Sensu | Page not found

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:
GitHub - spox/batali: Light weight cookbook resolver

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

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] GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the per-node top-level cookbooks in chef-solo based infrastructures
[1] GitHub - chef-boneyard/chef-provisioning: A library for creating machines and infrastructures idempotently in Chef.

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:
Sensu | Page not found

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:
GitHub - spox/batali: Light weight cookbook resolver

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

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] GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the per-node top-level cookbooks in chef-solo based infrastructures
[1] GitHub - chef-boneyard/chef-provisioning: A library for creating machines and infrastructures idempotently in Chef.

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:
Sensu | Page not found

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:
GitHub - spox/batali: Light weight cookbook resolver

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