[openstack-dev] [Solum] Gated Source Code Flow (was: Weekly Team Meeting)

Clayton Coleman ccoleman at redhat.com
Wed Nov 13 21:09:45 UTC 2013



----- Original Message -----
> Clayton,
> 
> On Nov 13, 2013, at 11:41 AM, Clayton Coleman <ccoleman at redhat.com>
>  wrote:
> 
> > ----- Original Message -----
> >> Hello,
> >> 
> >> Solum meets Tuesdays at 1600 UTC in #openstack-meeting-alt (formerly in
> >> #solum)
> >> 
> >> 
> >> Note: Due to the Nov 3rd change in Daylight Savings Time, this now happens
> >> at
> >> 08:00 US/Pacific (starts in about 45 minutes from now)
> >> 
> >> 
> >> Agenda: https://wiki.openstack.org/wiki/Meetings/Solum
> > 
> > In the meeting yesterday there was a mention of a "gated" source code flow
> > (where a push might go to an external system, and the gate system
> > github/gerritt/etc would control when the commit goes back to the primary
> > repository).  I've added that flow to
> > https://wiki.openstack.org/wiki/File:Solum_r01_flow.jpeg as well as a
> > mention of the DNS abstraction (a deployed assembly may or may not have an
> > assigned DNS identity).
> 
> Are the two "source change notification abstraction" flows really different?
> Could we express this with two lines converging on "Notify Solum API …" in a
> single flow with two similar entrances.

I think you hit on something fundamental - I reswizzled the diagram to show the "gate" flow moving into the normal "source push" flow after tests pass. https://wiki.openstack.org/w/images/7/72/Solum_r01_flow.jpeg

> 
> One key difference that I noticed between those two proposed flows are that
> the "gate" type uses the Solum API to test code, and the "push" one does
> not. Perhaps both should run unit tests in the same way with an option to
> bypass steps for those who don't want them?

Yeah - this also highlights that an input to the "build" flow might be the desired outcome - possibly "no deploy", "deploy", "deploy as temporary assembly X", or "deploy as temporary assembly X without tests". There may be consumers who wish to make Solum the end result of a flow, but if the tools and abstractions Solum offers for build and deploy are compelling, we should expect to want to let external systems utilize Solum as much as possible.  Another point of discussion is whether "test" is part of both "build" and "deploy", or just part of "deploy".  If it's part of both, perhaps "deploy" and "build" need to have similar ways of letting someone run their tests at the right opportunities.




More information about the OpenStack-dev mailing list