Open Stack

Hi Adrian,
    I'm very interested in Solum, particularly as it relates to
TripleO : as you know the TripleO story is to treat OpenStack as just
another application to install via Heat/Nova etc - and we've got a
major story around pulling from git -> CI + CD pipeline -> automated
deployment to production.

So - where we can say 'hey, this should be part of Solum', we can hive
stuff out of the TripleO program into Solum - but only if we've got
compatible stories.

Right now, our design for CD is basically Gerrit + Zuul - exactly the
same as gating checks for OpenStack itself. When I look at
https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/GitIntegration#Flow_Boundaries
I'm having a little trouble mapping that into your design.

I'm wondering if you can expand on how that hangs together?

Thanks!
Rob

On 31 October 2013 14:01, Adrian Otto <adrian.otto at rackspace.com> wrote:
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud