Rob Hirschfeld (rob_hirschf...@dell.com) wrote: > All, > > The notes have been moved to > https://github.com/crowbar/crowbar/wiki/Sprint-2013-05-24 for collaborative > editing.
Thanks! I fixed the broken image and some other minor formatting issues. > The updated DB schema w/ a reference example is here: > https://github.com/cloudedge/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model.png Thanks again! The reference example is very useful. I think the arrows to the Test Deployment are going in the wrong direction though? Or maybe they should be bi-directional. > I'd encourage a discussion on the list (please limit to one card per thread!). > > NEW CONCEPT NOTE! In review of these notes with Victor, he made a > very interesting suggestion to have deployments ABOVE barclamps. > This would mean that users would have a logical deployment group > (e.g.: test, dev, prod) that includes all the barclamps they are > using. Interesting idea, I'll have to think more about it but my first instinct is to be worried about the reduced granularity that this would result in. For example if you modify the parameters of a deployment (e.g. just to tweak something in keystone) then presumably it is going to trigger chef runs on a *lot* more nodes than it needs to? > Since ROLES are the really container, you'd choose the roles that you wanted > to include in a deployment and Crowbar would use the dependency graph to > include all the needed barclamps to implement that role. > > For example, if you choose the Nova Compute role then it would add the Nova > Controller, Keystone, SQL, Message Bus, Network...etc roles. > > Hmmm... that would also mean that the node available in a deployment would be > added to the Crowbar Role. > > I'm really excited about this suggestion. I think it makes coding/using > Crowbar simpler and natural. I'm not convinced yet (but willing to be persuaded). From a UX perspective it seems less intuitive to me because there's more "magic" happening. I would expect that the UI should present the user with all the components they are going to deploy, and request assignment of roles to nodes, rather just present and request assignment for a single role which would then result in a sort of "oh by the way, if you want nova-compute then you'll also need these other ones - where do you want to put them?" experience from the UI. I'm also not sure how having deployments above barclamps would tie in with the OpenStack grouping barclamp? There still needs to be some way to templatize the workflow into "give me a complete OpenStack cloud, and along the way ask me to assign stuff to nodes in the right order", so I'd be interested in how this would work with higher-level deployments. Another way of viewing the move of deployments to be above barclamps rather than below is to consider it as allowing multiple barclamps per deployment. But maybe you could achieve something similar by allowing deployments to contain (multiple) other deployments, e.g. via a type of barclamp that exists purely as a container for other deployments (template-based or otherwise). _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
