I know that a multiple versions of the same cookbook can exist on a single chef server, but can different cookbooks depend on different versions of the same cookbook within an environment?
Suppose we have two “top level” cookbooks, “foo” and “bar” that share a dependency on a “common” cookbook, but at different versions: perhaps, “foo” depends on “common” at version “=1.2.3”, and “bar” depends on “common” at “~>2.0.0”
As long as “foo” and “bar” are not deployed on the same node, would all the nodes with the “foo” cookbook get the older version of the “common” cookbook, and would all the nodes with the “bar” cookbook get the latest version of “common” that was greater than 2.0.0?
I am not asking if this is a good thing to do. I just want to know if different versions of the same cookbook could be deployed within an environment as long as they are on different nodes and the version constraints in the metadata have been correctly specified.
I know that a multiple versions of the same cookbook can exist on a single
chef server, but can different cookbooks depend on different versions of the
same cookbook within an environment?
Suppose we have two “top level” cookbooks, “foo” and “bar” that share a
dependency on a “common” cookbook, but at different versions: perhaps, “foo”
depends on “common” at version “=1.2.3”, and “bar” depends on “common” at
“~>2.0.0”
As long as “foo” and “bar” are not deployed on the same node, would all the
nodes with the “foo” cookbook get the older version of the “common”
cookbook, and would all the nodes with the “bar” cookbook get the latest
version of “common” that was greater than 2.0.0?
I am not asking if this is a good thing to do. I just want to know if
different versions of the same cookbook could be deployed within an
environment as long as they are on different nodes and the version
constraints in the metadata have been correctly specified.
Yes, you can do this, if you do the pinning in the metadata for the
'foo' and 'bar' cookbooks (and not at the environment level).
personally I even prefer to lock dependencies in metadata.rb, exactly for
that reason. The other bonus point is that you can use environments for
environments again, and the only cookbooks you need to specify in the
environments are the "top level" cookbooks (I call them exactly like that).
See the discussion here:
@danielsdeleo: my latest response is still pending, will answer to the list
to bring the discussion back here
Cheers,
Torben
On Thu, Jun 12, 2014 at 10:07 PM, Julian C. Dunn jdunn@aquezada.com wrote:
I know that a multiple versions of the same cookbook can exist on a
single
chef server, but can different cookbooks depend on different versions of
the
same cookbook within an environment?
Suppose we have two “top level” cookbooks, “foo” and “bar” that share a
dependency on a “common” cookbook, but at different versions: perhaps,
“foo”
depends on “common” at version “=1.2.3”, and “bar” depends on “common”
at
“~>2.0.0”
As long as “foo” and “bar” are not deployed on the same node, would all
the
nodes with the “foo” cookbook get the older version of the “common”
cookbook, and would all the nodes with the “bar” cookbook get the latest
version of “common” that was greater than 2.0.0?
I am not asking if this is a good thing to do. I just want to know if
different versions of the same cookbook could be deployed within an
environment as long as they are on different nodes and the version
constraints in the metadata have been correctly specified.
Yes, you can do this, if you do the pinning in the metadata for the
'foo' and 'bar' cookbooks (and not at the environment level).
Torben, I think I agree with you on your views of direct and indirect version locking.
When a cookbook specifies a version constraint on another cookbook, it is locking itself to an interface.
How the other cookbook chooses to implement that interface, I.e., what other cookbooks it locks to, is part of that cookbook’s implementation, and should not be directly visible to the original cookbook.
personally I even prefer to lock dependencies in metadata.rb, exactly for that reason. The other bonus point is that you can use environments for environments again, and the only cookbooks you need to specify in the environments are the "top level" cookbooks (I call them exactly like that).
See the discussion here:
@danielsdeleo: my latest response is still pending, will answer to the list to bring the discussion back here
I know that a multiple versions of the same cookbook can exist on a single
chef server, but can different cookbooks depend on different versions of the
same cookbook within an environment?
Suppose we have two “top level” cookbooks, “foo” and “bar” that share a
dependency on a “common” cookbook, but at different versions: perhaps, “foo”
depends on “common” at version “=1.2.3”, and “bar” depends on “common” at
“~>2.0.0”
As long as “foo” and “bar” are not deployed on the same node, would all the
nodes with the “foo” cookbook get the older version of the “common”
cookbook, and would all the nodes with the “bar” cookbook get the latest
version of “common” that was greater than 2.0.0?
I am not asking if this is a good thing to do. I just want to know if
different versions of the same cookbook could be deployed within an
environment as long as they are on different nodes and the version
constraints in the metadata have been correctly specified.
Yes, you can do this, if you do the pinning in the metadata for the
'foo' and 'bar' cookbooks (and not at the environment level).