Thanks for all the help. It clarified things eventhough I came up with an alternate solution. I ended up going a hybrid/different way which in the end I think provides better encapsulation than the 2 suggestions provided: Default.rb include_recipe ‘app::upgrade’ include_recipe ‘app::validate’ upgrade.rb :stop :db_backup :configure :update :start validate.rb :validate rollback.rb :stop :db_rollback :server_rollback :start :validate The one missing bit of the puzzle is that I use the following code in the :validate action to call the rollback if necessary if doRollback then recipe_eval do run_context.include_recipe("app::rollback") end end I find this makes my code orthogonal and testable and also keeps the recipes clean of any messy ruby blocks. I also added a flag to the :validate action so that I can disable rollback call. This avoids ending up in an infinit loop since I run validate at the end of rollback. The reason for this is that validate also logs validation results which are good to have cheers, Florian From: Dan Razzell [mailto:
Others have commented that it may be best to keep the workflow within the provider. foo_validated = false Cheers, Greg, Thanks for the quick response. The main thing is that I want to be able to call :rollback only if :validation fails or in a couple of other places where fatal errors can occur and just stopping is not good enough. Cheers, Florian On 10/09/13 09:32, Florian Hehlen wrote:
Let the provider handle the sequencing. So, in your example, I'd define methods in the provider for each of the steps you currently have as actions, and then in the actual actions, call them in the right order: |
Archive powered by MHonArc 2.6.16.