Open Stack

Dev,

Thanks for raising this discussion. This is an important decision point for us.

On Feb 12, 2014, at 1:25 PM, devdatta kulkarni <devdatta.kulkarni at rackspace.com>
 wrote:

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

Although this feature is not currently scoped for our earliest milestones, it is part of our long term vision under the umbrella of "CI" and developer automation, and we should think about how to get there.

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

I see code gating as a best practice for CI. As we begin to offer a CI experience as a default for Solum, we will want to employ a set of best practices to help those who are just starting out, and do not yet have any automation of this sort. Gating is well understood by OpenStack developers, but it's not well understood by all developers. It's actually pretty tricky to set up a complete CI system that does enter+exit gating, integrates with a review system, and leverages a build job runner like Jenkins. Because Solum is targeting the persona of "Application Developers" we want an experience that will feel natural to them.

I do think there are areas where the current openstack-ci system may be streamlined for general purpose use. Gerrit has various user interface quirks, for example. We should be willing to contribute to the various projects to improve them so they are more pleasant to use.

I'm reluctant to endorse an approach that involves re-creating functionality that Zuul already offers. I'd rather just leverage it. If Zuul has more features and capabilities than we need, then we should explore the possibility of turning off those features for now, and activating them when we are ready for them. If there are any tools that's are *better* fit with our long term vision compared to Zuul, then we should be willing to evaluate those.

I think that if people just want generic ALM, they can stand up Jenkins (or some equivalent), and have a set of build scripts that burp out a container image and a plan file at the end, and feed that into Solum. If they are Github lovers, they can configure the post commit webhook to trigger Solum, and have Solum pick up and build the container image, and send it through the CD process. Any variety of CI systems from a long list of awesome software vendors can fit here.

If they want something more comprehensive, including a full set of open source best practices by default, such as entrance and exit gating, hosted code review and collaboration, It would be really nice to have a full Zuul+Nodepool+Jenkins+Gerrit setup with some integration points where they could potentially customize it.

> Thoughts?

In summary, I'd prefer that we consider using Zuul from the beginning, and turn of any parts we don't need for our early releases. I'm willing to consider alternatives if they can be shown to be superior.

Thanks,

Adrian

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