Hi, I have some concerns about using Zuul in Solum
I agree gating is a great feature but it is not useful for every project and as Adrian said, not understood by everyone. I think many Solum users, and PaaS users in general, are single-project/single-build/simple git worklow and do not care about gating. I see 2 drawbacks with Zuul : - Tenant Isolation : How do we allow access on zuul (and jenkins) for a specific tenant in isolation to the others tenants using Solum. - Build customization : One of the biggest advantage of Jenkins is its ecosystem and the many build customization it offers. Using zuul will prohibit this. About Gerrit, I think it is also a little too much. Many users have their own reviewing system, Pull requests with github, bitbucket or stash, their own instance of gerrit, or even a custom git workflow. Gerrit would be a great feature for future versions of Solum. but only as an optionnal one, we should not force people into it. Julien 2014-02-13 5:47 GMT+01:00 Clark Boylan <clark.boy...@gmail.com>: > On Wed, Feb 12, 2014 at 7:25 PM, Noorul Islam K M <noo...@noorul.com> > wrote: > > "devdatta kulkarni" <devdatta.kulka...@rackspace.com> writes: > > > >> 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? > >> > > > > Is Zuul tightly couple with launchpad? I see that most of the > > information that it displays is coming from launchpad. > > > > If it is, is it a good idea to force launchpad on users? > > > > Regards, > > Noorul > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > I can't think of any places that Zuul requires launchpad (or displays > launchpad info for that matter). It is a bit coupled to Gerrit on one > end and Gearman on the other, but not in an extreme way (the use of > Gearman makes a bunch of sense imo, but having additional triggers > instead of just Gerrit sounds great to me). > > Clark > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev