All, We're working on core CB2 functions as per the design discussion from last week. Our objective is to code incrementally to validate the design. I believe this approach gives the community concrete examples for discussion and makes it possible to update the design based on learning and new viewpoints.
Currently, I've stripped out a lot of legacy code and rebuilt the very basics of the model we discussed. See DIA file https://github.com/crowbar/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model.dia In the next weeks, we are taking the first steps to define the Jig model API and test it using the Script jig. Here are some initial thoughts: * The Script jig is built into the Crowbar barclamp. * New nodes will be added to the system via the API (POST v2/nodes) not from the jigs * The jig will provide methods that handle Crowbar node C.U.D. via node_create, node_update and node_delete. * When new jigs are added, we expect them to get a call to node_create for all nodes already in the system [we are NOT covering this use case for the Script jig] * Crowbar will create a "run" handle when it transfers control of node-roles to the Jig for operation * The Jig will expose a run method that takes the run handle from Crowbar * When the Jig takes over the run, it will change the run status and also update the node-role states to TRANSISTIONING * The node-role's in a run will also have the run handle * A node-role only be managed by one jig at a time (so a run handle will be per jig) There will be other items, but this is a good start. Rob ______________________________ Rob Hirschfeld Distinguished Cloud Solution Architect Dell | Cloud Edge, Data Center Solutions blog robhirschfeld.com, twitter @zehicle Please note, I am based in the CENTRAL (-6) time zone
_______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
