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 <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins <[email protected]>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
