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/

Reply via email to