Rob Hirschfeld (rob_hirschf...@dell.com) wrote: > Victor and I were kicking around the DB models a little more. The result was > a further refinement/simplification for discussion. > > > 1) Deployment is the top level thing. Basically, all the roles hang off > the deployment (through the snapshot pointer). When a role has a > prerequisite, that prerequisite is always resolved from within the > deployment. The discussion image shows the role prereq chain in blue.
Just checking you saw my feedback yesterday? I'm not yet convinced how well this will work, but I'm very willing to be persuaded via answers to my questions :) Also, the arrows are still wrong. > 2) Each role is linked to a one (and only one) jig. That means > it is very clear which jig owns the operation of any role and the > inbound data values related to that role. The consequence of that > design choice is that we may have "duplicate" roles that are > implemented by different jigs. For example, the SQL barclamp could > have roles for the Puppet and Chef jigs. While that seems > redundant, it is much clearer and reduces a lot of ambiguity. Sounds reasonable, although it's not immediately obvious to me why it's clearer / less ambiguous. > It would be OK for a role tied to the Chef jig to have a Puppet jig > role as a prereq Why? That sounds weird to me. > however, we expect that most roles will be chained within a single jig type. When would it make sense for a role to be tied to multiple jig types? > 3) The jig is responsible to updating the state of the node-role after > any activity. Having roles tied to jigs makes that ownership very clear. > > Schema: > https://github.com/crowbar/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model.png > Example: > https://github.com/crowbar/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model_discussion.png Without cardinality markings for each association, the schema is of limited use. For example, how many Chef jigs will there be? One globally, or one per deployment, or one per barclamp? > Remember: the node-role relationship is proposed as the core atomic unit in > CB2 core. It's the action handle that's passed to a jig and also the place > where state is updated. Yep, strongly in favour of this. > Overall, I feel like we're moving towards a model that is more > explicit and direct than before. I don't have any reason to disagree with that yet, but I feel like a large part of the reasoning behind that sentiment has not been widely shared yet, until which time I can't really agree either ;-) Perhaps we can cover this during my visit? > Our design objective is that Crowbar operations are more transparent > and easier to track. Amen! :-) _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
