On Wed, Jan 30, 2013 at 3:27 AM, Adam Jacob
<
" target="_blank">
> wrote:
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.)
That is unlikely to be an issue with the way we build our infrastructure. Typically we break our convergence into 3 separate "stages".
* The first stage is basically setting up the OS level guff. Usually fairly consistent across hosts.
* The second stage tends to be application server bits. i.e. Install the app server, install the web server, install the database server, install the message broker etc.
* The third stage tends to be creating an instance of the application server installing resources into the application server. i.e. Define the destinations in the message broker, create the database in db server, install the application/resource config into the app server, add the site to the web server etc.
There is no cross stage ordering requirements. (Other than the first stage has to occur before the second). There is almost no cross stage notifications and no cross stage ordering constraints*. So at least in all our use cases I think the introduction of stages would simplify rather than increase the complexity of understanding a chef run.
* We often use the "notifying_action" LWRP pattern [1] to separate out a stage and on a few occasions have had to define a resource again within an LWRP so as to trigger an action (typically to restart a service).
What are the use-cases we are trying to solve with these features? Partial run-list application is clear. What
A new timing mechanism for notifications. I want to be able to say that all the notifications with a particular tag will be resolved at a particular point in the chef converge phase. If several config files are updated, the service should only be retstarted once but you should be able to identify the point during the converge by which it must be restarted
We have also talked about the ability to export resources from a LWRP so that they could be notified even if it is using the "notifying_action" LWRP pattern. Currently we have to occasionally redefine resources which just sucks. However I am not even sure how this would work as it would not be added to the resource collection until after the LWRP ran.
Partial run list application would probably be sufficient (if done right) when combined with the enhancement to notifications.