Open Stack

Excuse top post (web mail :()

Can't we change our proposed workflow to match what Gerrit/Zuul are
doing? So endorse the gating workflow as "the official solum workflow".

Pros:
- we just use the current Gerrit/Zuul as-is.
- great gating system for little effort
- lots of people already helping maintain it.
- maybe infra can use solum at some point

Cons:
- slightly more complex workflow (we could have an option to
   autoapprove?)

I am not sure if the flexibility of the plan matches the reality of
gerrit/zuul.
1 just run an assembly
   (review and test are a noop, straight to merge/and run)
2 build an image and run an assembly
3 bulld an image, test then run an assembly
4 review, bulld an image, test then run an assembly

So can we short cut the workflow of our current Gerrit/Zuul to do
that?

-Angus

________________________________________
From: Paul Czarkowski [paul.czarkowski at RACKSPACE.COM]
Sent: Thursday, February 13, 2014 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum

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


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