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