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 <ccole...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to