Open Stack

> On Feb 12, 2014, at 5:45 PM, "Angus Salkeld" <angus.salkeld at RACKSPACE.COM> wrote:
> 
> 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".

That's my preference so far.

> 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

All good reasons. The last one is worth further exploration too.

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

I think with some noop techniques it his can be just as streamlined as the alternative approach. I would list an additional con:

- Installation complexity and resource requirements may be bigger using this approach.

It might be nice to validate and quantify this trade off to make sure it is not a showstopper.

> 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?

The parts that perform image builds can be jobs that Zuul initiates. I struggle to imagine that noop jobs (#1) would be difficult, and that could be our first default to keep things simple to begin with.

Adding in reviews to the workflow (#4) makes complete sense, but will definitely be addressed in later milestones. If we start with Zuul to begin with, we have a good working example of how to set this up when we get to that point.

Are there alternate viewpoints to consider?

Thanks,

Adrian

> -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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev