I think this helps with isolation, but I think it might make order much less predictable. This is an escalation of early ordering, not an easing of the primitives that allow you to control final ordering.
Partial run-lists are a good idea, but you would need to include the idea that previous portions of the complete list have converged before. Otherwise, you're going to see the scope of each recipe artificially increasing, and you're going to have lots
of difficulty predicting what side-effects are going to produce (for example, user ids from installed packages who order may be different based on the staged-run timing.)
What are the use-cases we are trying to solve with these features? Partial run-list application is clear. What else?
Adam
From: Peter Donald <
">
>
Date: Tuesday, January 29, 2013 2:53 AM Cc: Chef Dev < "> > Subject: [chef-dev] Re: Re: CHEF-3747 - Compile Time Packages On Tue, Jan 29, 2013 at 11:21 AM, Sean OMeara <
" target="_blank">
> wrote:
Compile time modification is a hack that should very much be discouraged. +1
If a single chef run could be multiple stages, where each stage was a runlist and each stage compiled and converged before the next stage, this would make my life a lot easier. For bonus points you could make it possible to run stages individually and
suddenly application deploys would be much easier in chef.
Cheers, Peter Donald |
Archive powered by MHonArc 2.6.16.