Open Stack

For cinder, we don't want to gate on drivers, and will be unhappy if that
gets turned on, so the story hasn't changed, Anita.

I think Jim was pointing out the technical possibility, which is a fine and
valid thing to point out. Cinder core are likely to continue not to want
it, for the foreseeable future.

On 24 February 2015 at 10:30, Anita Kuno <anteaya at anteaya.info> wrote:

> On 02/23/2015 07:00 PM, James E. Blair wrote:
> > Clark Boylan <cboylan at sapwetik.org> writes:
> >
> >>>    The other thing is that we don't have the zuul code to vote with
> >>>    a different account deployed/merged yet. So initially you could run
> >>>    your
> >>>    job but it wouldn't vote against, say, cinder.»
> >> The stack that adds the necessary zuul stuff ends with
> >> https://review.openstack.org/#/c/121528/
> >
> > I don't believe that we have any current plans to use that code in
> > infra.  I don't believe that it makes sense for us to create multiple
> > accounts in Gerrit for our single system.  It's quite a bit of overhead,
> > and I don't believe it is necessary.
> >
> > To be clear, I think any policy that says that drivers must have
> > "third-party CI" is an oversight.  I believe that it's fine to require
> > them to have "CI", but if the CI can be provided by infra, it should be.
> > I believe this misunderstanding comes from the fact that most
> > out-of-tree drivers require specialized hardware, or non-free software,
> > that can not be run in our system.
> >
> > As mentioned elsewhere, we're generally quite happy to have any open
> > source component tested in the upstream infrastructure.  Since this
> > qualifies, I think the quickest and simplest way to proceed is to create
> > a job that runs on the driver repo, and then create a non-voting version
> > to run on the cinder repo.
> >
> > Additionally, if it proves stable, the Cinder developers could certainly
> > choose to gate on this job as well.
> I'd like to make sure that if Infra is saying that CI jobs on drivers
> can gate that this is a substantial difference from what I have been
> saying for a year, specifically that they can't and won't.
>
> Every CI system/job author/operator that I have interacted with for the
> past year has been trying to figure out how to be in the gate. Since
> that implies a relationship in which development on the service can't
> proceed without a driver's say so (by passing the test in the gate) this
> is exactly the relationship I have been trying to ensure doesn't happen.
> By stating that driver jobs can gate on the service, this opens the
> flood gates of every CI operator increasing pressure to be in the gate
> as well (the pressure never stopped, it just took different forms).
>
> I disagree with the relationship where a service's development can only
> proceed at the speed of a driver (or driver's because where there is
> one, there are plenty more).
>
> Thanks,
> Anita.
>
>
> > That's entirely up to them, but
> > there's no policy or technical reason it can not.
> >
> > -Jim
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/663f7926/attachment.html>