Clayton, Thanks for adding the diagram illustrating the flow. I expect that "respond to client" may not be a synchronous flow, rather that if creation of a repo takes a while that the API may return a 202 Accepted, and the client can poll a status attribute to determine completion and learn the actual location of the repo created. So in that case "respond to client" also might mean "update async status". This will be particularly important in cases where an external SCM system is used (perhaps Github). I agree that this will be a helpful reference to guide our upcoming interactive design sessions. I have created the first call for participation, which will also be separately announced: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings Adrian On Oct 30, 2013, at 2:45 PM, Clayton Coleman <ccoleman at redhat.com> wrote: > In the IRC meeting yesterday [1] we discussed splitting the individual topics for the git deploy blueprint [2] into rough sub areas. To help frame the abstractions we've been discussing I roughed out a flow based on two user inputs, REST API create and a git push and then tried to draw boxes around the related bits. The abstractions roughly correspond to the potential areas that can be the focus of break out discussions (and if they don't a good discussion of why is always helpful). > > Squiggly boxes are potential plugin points and/or strong responsibility boundaries. Feedback desirable. > > [1] http://irclogs.solum.io/2013/solum.2013-10-29-16.01.txt > [2] https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/GitIntegration#Flow_Boundaries > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev