I don't like that in this patch we deal with allowed recipes and
restricted recipes in different parts of the code. That's not
necessarily the patches fault, but I think requires that if we went
down this road we did some refactoring.
A more easily correctable issue is that the logs regarding allowed and
restricted recipes both call them restricted recipes, making the
interaction between these features unclear.
How would this functionality work with a larger policy? Would this
extend well into setting allowed and restricted cookbooks in a role?
It seems that the fix would be not including those cookbooks, and
> - A "straw man" fix to non-compatible recipe inclusion in the case of
> multi platform cookbook metadata dependency, e.g. apt & yum
rather including them based on node['platform'].
This patch removes a run list item from the nodes run list, but what
if we want to restrict a dependent recipe that isn't in the run list?
Given a run list of "recipe[check_sl]" where the check_sl cookbook
depends on the install_sl cookbook, if we run "sudo chef-client -r
recipe[install_sl]" we still run the install_sl::default recipe
because it was not in the run list but rather was in the expanded run
list. This is pretty confusing because it doesn't do what you just
asked it to do, which was prevent that cookbook from running.
Shouldn't this fail from the start?
The dependency selector has already run on the server and given us a
set of cookbook versions that match the provided dependencies, but
what are the consequences of restricting a cookbook now? I think we're
likely to have recipes fail and it is going to be unclear why, a
situation that is prevented by the chef-server preventing a set of
cookbook versions that don't resolve the dependencies. It seems that
we would want to pass the run list by the server for a thumbs up
before going too far down a road that could lead to peril.
Archive powered by MHonArc 2.6.16.