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. Thoughts? Thanks, Devdatta _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev