After kicking around what is needed between Ward, Wayne and myself, we came up with the minimal definition of a "job" for Crowbar.
1: Transition request for a node gets put to the framework 2: Node transition function iterates over all active and pending deployments on it, pulling in any attribs, attrib mappings, and roles it needs from the deployments. 3: Node transition function hands the attribs, attrib mappings, and roles on a per-deployment basis to the Jig superclass, which then farms them out to the individual jigs. 4: Each individual jig verifies that the requested attribs and attrib mappings from the deployments to not conflict. If they do, the transition will fail, and we will bubble that up as appropriate. 5: Once we have verified that there are no conflicts, each jig pushes the updated attribs to the appropriate location (for the chef jig, this will be the node role), and runs the roles in the appropriate order. 6: If any of the role runs fail, then the transition fails as well, and we will handle the error appropriately by launching missiles. 7: Run any data returned through the inbound data path and update node and deployment specific attribs as appropriate. 8: Profit. This will suffice for a simple job -- more complicated ones involving synchronized changes across nodes would be handled by building a dependency tree of jobs and walking it. Feedback welcome! _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
