Open Stack

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.boylan at gmail.com>:

> On Wed, Feb 12, 2014 at 7:25 PM, Noorul Islam K M <noorul at noorul.com>
> wrote:
> > "devdatta kulkarni" <devdatta.kulkarni at 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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/22ddd0d3/attachment.html>