Open Stack

Paul,

On Feb 12, 2014, at 3:44 PM, Paul Czarkowski <paul.czarkowski at RACKSPACE.COM>
 wrote:

> 
> 
> On 2/12/14 5:16 PM, "Roshan Agrawal" <roshan.agrawal at RACKSPACE.COM> wrote:
> 
>> 
>>> -----Original Message-----
>>> From: devdatta kulkarni [mailto:devdatta.kulkarni at rackspace.com]
>>> Sent: Wednesday, February 12, 2014 3:26 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum
>>> 
>>> Hi,
>>> 
>>> I have been looking at Zuul for last few days and had a question about
>>> its
>>> intended role within Solum.
>>> 
>>> From what I understand, Zuul is a code gating system.
>>> 
>>> I have been wondering if code gating is something we are considering as
>>> a
>>> feature to be provided in Solum? If yes, then Zuul is a perfect fit.
>>> But if not, then we should discuss what benefits do we gain by using
>>> Zuul as
>>> an integral part of Solum.
>>> 
>>> It feels to me that right now we are treating Zuul as a conduit for
>>> triggering
>>> job(s) that would do the following:
>>> - clone/download source
>>> - run tests
>>> - create a deployment unit (DU) if tests pass
>>> - upload DU to glance
>>> - trigger the DU deployment workflow
>>> 
>>> In the language-pack working group we have talked about being able to
>>> do CI
>>> on the submitted code and building the DUs only after tests pass.
>>> Now, there is a distinction between doing CI on merged code vs.
>>> doing it before code is permanently merged to master/stable branches.
>>> The latter is what a 'code gating' system does, and Zuul is a perfect
>>> fit for this.
>>> For the former though, using a code gating system is not be needed.
>>> We can achieve the former with an API endpoint, a queue, and a mechanism
>>> to trigger job(s) that perform above mentioned steps.
>>> 
>>> I guess it comes down to Solum's vision. If the vision includes
>>> supporting,
>>> among other things, code gating to ensure that Solum-managed code is
>>> never broken, then Zuul is a perfect fit.
>>> Of course, in that situation we would want to ensure that the gating
>>> functionality is pluggable so that operators can have a choice of
>>> whether to
>>> use Zuul or something else.
>>> But if the vision is to be that part of an overall application lifecycle
>>> management flow which deals with creation and scaling of
>>> DUs/plans/assemblies but not necessarily be a code gate, then we should
>>> re-
>>> evaluate Zuul's role as an integral part of Solum.
>> 
>> The question is: is Zuul the right tool for the code deployment workflow
>> you outlined above? The code deployment workflow is the higher order
>> need. 
>> 
>> The code gating functionality is also useful and potentially something we
>> would want to implement in Solum at some point, but the decision criteria
>> on what tool we use to implement the code deployment workflow depends on
>> how good is Zuul in helping us with the deployment workflow.
>> 
>>> Thoughts?
>>> 
>>> Thanks,
>>> Devdatta
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> The current proposed workflow for Solum (m1) is shorthanded to be something
> like this
> 
> 1. User writes code
> 2. User pushes to master branch in github
> 3. a github hook fires against the solum API.
> 4. Solum coordinates the testing/building and deployment of the app
> 
> None of this seems overly suitable for zuul to me ( not without a
> significant
> amount of work that will be needed to customize zuul to work for us ), and
> can be easily ( for certain values of easy ) achieved with solum
> forking a thread to do the build ( m1 implementation ? ) or solum
> sending messages to a set of worker nodes watching a queue ( marconi? Post
> m1, pluggable so operator could use their existing jenkins, etc ).
> 
> If an enterprise or provider wanted to implement code gating it would slip
> in before option 1,  and would be relatively simple for an operator to
> plug in their existing code gating/review tooling (github
> PRs,CodeCollaborator,Crucible+Bamboo) or set up Gerrit/Zuul system:
> 
> 1. User writes code
> 2. User runs `git review`
> 3. Gerrit calls zuul to run automated tests
> 4. Core reviewers +2 the code
> 5. Gerrit merges code to master branch in github
> 6. a github hook fires against the solum API
> 7. Solum coordinates the testing/building and deployment of the app

This point of view assumes they already have a CI solution. I speak with a lot of folks out there just looking at cloud for the first time, and if you ask them are they using CI, they look at you with a blank stare, and then ask something like "C-what?". We should be prepared to help Application Developers as an entire class, not only the ones that have adopted agile, devops, and know something about CI already. 

Cheers,

Adrian

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